Considerações
As considerações a seguir precisam ser abordadas para garantir a integridade da Confirmação protegida pelo Android. Se essas considerações não puderem ser resolvidas de forma satisfatória, a confirmação protegida não poderá ser implementada no dispositivo.
Considerações sobre o kernel do Linux
A confirmação protegida foi projetada para operar com segurança, mesmo que o kernel do dispositivo seja comprometido. Enquanto a caixa de diálogo de confirmação protegida estiver ativa, o kernel não poderá interferir na integridade do conteúdo da tela, na integridade da entrada do usuário e na atomicidade entre a entrada e a saída do usuário. Arquitetonicamente, o kernel precisa ser impedido de aumentar a decisão do usuário e de falsificar eventos do usuário. O kernel não é considerado confiável para esse caso de uso, porque pode estar sob o controle de um invasor ou substituído por algo completamente diferente.
Considerações sobre firmware
A confirmação protegida só pode ser implementada em um dispositivo se todos os componentes envolvidos tiverem firmware confiável. A confirmação protegida foi projetada para garantir que o usuário tenha a chance de ler uma mensagem exibida na interface confiável para tomar uma decisão informada sobre se deve ou não prosseguir com uma transação. O driver do painel de exibição é especialmente importante, porque pode impedir que o usuário acesse a IU confiável.
Considerações sobre entrada
Escolha um método de entrada seguro para garantir que os eventos de entrada gerados por esse método de entrada não sejam transmitidos para a caixa de diálogo de confirmação protegida, a menos que o usuário gere o evento enquanto essa caixa de diálogo estiver ativa.
Hardware físico
Qualquer componente que possa ser controlado pelo kernel do Android, como o sistema em chip (SoC) ou o circuito integrado de gerenciamento de energia (PMIC), não pode ser capaz de conduzir um fio conectado a um botão de confirmação físico.
Considerações sobre o controle touchscreen
A confirmação protegida pode usar botões de software na tela como entrada. Sempre que o controlador por toque é controlado pelo TEE, é necessário tomar medidas para limpar o estado dele.
Comportamento esperado
Interrupções
Se o sistema interromper a sessão de confirmação devido a uma chamada
de entrada ou um evento de energia, o HAL precisará informar
ResponseCode::Aborted. Os apps recebem o callback
onCanceled() e sabem que o usuário não escolheu uma ação. Os alarmes não precisam interromper
a sessão, mas precisam notificar o usuário. Sobreposições de notificação de qualquer tipo
não são permitidas enquanto a caixa de diálogo está ativa.
Período de carência de entrada
Depois que a confirmação protegida é iniciada, a entrada precisa permanecer inativa por pelo menos um segundo antes de responder à interação do usuário. Esse período de carência garante que o usuário tenha a chance de reagir a uma caixa de diálogo de confirmação inesperada. Esse período de carência precisa ser aplicado pelo app confiável.
Rotação da tela
O modo retrato é o único obrigatório, e a rotação da tela não é compatível. A rotação da tela permite o potencial de abuso em um sistema comprometido, como a colocação de botões enganosos ou a manipulação do texto do corpo.
Falhas na renderização do corpo do texto
Há um limite
rígido de 6144 (0x1800) bytes para o texto do corpo, incluindo dados
extras não exibidos e informações do cabeçalho CBOR.
Além disso, há um limite flexível que precisa ser aplicado. Se a
mensagem renderizada não couber completamente no espaço de tela disponível,
verifique se a confirmação protegida é interrompida e a transação é cancelada.
Se MessageSize exceder o tamanho máximo permitido, a
implementação precisará retornar UIErrorMessageTooLong em
promptUserConfirmation.
A prática recomendada é formatar o texto do corpo depois de receber a chamada de API. O texto do corpo precisa ser mostrado ao usuário por completo.
Telas secundárias
As telas secundárias têm suporte sob determinadas condições. A integridade da saída e da entrada do usuário precisa ser mantida, e nenhuma informação enganosa pode ser exibida por outros meios. Caso contrário, a caixa de diálogo só será mostrada na tela principal, e todas as outras telas precisam estar desativadas ou em branco. As soluções de streaming e compartilhamento de tela não podem mostrar a caixa de diálogo nem gerar confirmações.