Considerações
As considerações a seguir devem ser abordadas para garantir a integridade da Android Protected Confirmation. Se essas considerações não puderem ser abordadas satisfatoriamente, a Confirmação Protegida não poderá ser implementada no dispositivo.
Considerações do kernel do Linux
A Confirmação Protegida foi projetada para operar com segurança mesmo se o kernel do dispositivo estiver comprometido. Enquanto a caixa de diálogo Confirmação Protegida estiver ativa, o kernel não pode 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 deve ser impedido de aumentar a decisão do usuário e de falsificar eventos do usuário em primeiro lugar. O kernel não é considerado confiável para este caso de uso, pois pode estar sob o controle de um invasor ou substituído por algo completamente diferente.
Considerações de firmware
A Confirmação Protegida pode ser implementada em um dispositivo somente se todos os componentes envolvidos tiverem um firmware confiável. A Confirmação Protegida foi projetada para garantir que o usuário tenha a chance de ler uma mensagem exibida na Trusted UI para tomar uma decisão informada sobre prosseguir ou não com uma transação. O driver do painel de exibição é especialmente importante, pois isso pode impedir que o usuário visualize a IU confiável.
Considerações de entrada
Escolha um método de entrada seguro para garantir que os eventos de entrada gerados por esse método de entrada escolhido não sejam transmitidos para a caixa de diálogo 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 no chip (SoC) ou circuito integrado de gerenciamento de energia (PMIC), não deve ser capaz de acionar um fio conectado a um botão de confirmação físico.
Considerações sobre o controlador de toque
A Confirmação Protegida pode usar botões de software na tela como entrada. Sempre que o controlador de toque estiver sendo acionado pelo TEE, devem ser tomadas medidas para sanear o estado do controlador de toque.
Comportamento esperado
Interrupções
Se o sistema interromper a sessão de confirmação devido a uma chamada telefônica ou evento de energia, o HAL deverá relatar ResponseCode::Aborted . Os aplicativos recebem o retorno de chamada onCanceled() e sabem que o usuário não escolheu uma ação. Os alarmes não precisam abortar 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 estiver ativa.
Inserir período de carência
Após o início da Confirmação Protegida, a entrada precisa permanecer inativa por no mínimo 1 segundo antes de se tornar responsiva à 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 deve ser aplicado pelo aplicativo confiável.
Rotação da tela
Retrato é o único modo 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 posicionamento enganoso de botões ou manipulação de 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 de cabeçalho CBOR. Além disso, há um limite flexível que deve ser aplicado. Se a mensagem renderizada não couber completamente no espaço de tela disponível, certifique-se de que a Confirmação Protegida seja abortada e a transação cancelada. Se MessageSize exceder o tamanho máximo permitido, sua implementação deverá retornar UIErrorMessageTooLong em promptUserConfirmation .
A prática recomendada é formatar o texto do corpo depois de receber a chamada da API. O corpo do texto deve ser mostrado ao usuário na íntegra.
Monitores secundários
Monitores secundários são suportados sob certas condições. A integridade da saída e da entrada do usuário deve ser mantida e nenhuma informação enganosa pode ser exibida por outros meios. Caso contrário, a caixa de diálogo só pode ser exibida na tela principal e todas as outras telas devem ser desativadas ou em branco. As soluções de streaming e compartilhamento de tela não têm permissão para exibir a caixa de diálogo ou gerar confirmações.