Considerações
As considerações a seguir devem ser abordadas para garantir a integridade da Confirmação Protegida do Android. Se estas considerações não puderem ser abordadas de forma satisfatória, a Confirmação Protegida não poderá ser implementada no dispositivo.
Considerações sobre o kernel 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 ser substituído por algo completamente diferente.
Considerações de firmware
A Confirmação Protegida só poderá 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 UI confiável para tomar uma decisão informada sobre prosseguir ou não com uma transação. O driver do painel de exibição é especialmente importante porque pode impedir que o usuário visualize a UI 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 o 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, medidas deverão ser tomadas para higienizar 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 recebida ou evento de energia, o HAL deverá reportar 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.
Período de carência de entrada
Após o início da Confirmação Protegida, a entrada precisa permanecer inativa por no mínimo 1 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. Este 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 corporal.
Falhas na renderização do corpo do texto
Há um limite rígido de 6.144 (0x1.800) bytes para o corpo do texto, 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 seja cancelada. Se MessageSize exceder o tamanho máximo permitido, sua implementação deverá retornar UIErrorMessageTooLong em promptUserConfirmation .
A prática recomendada é formatar o corpo do texto após receber a chamada da API. O corpo do texto deve ser mostrado ao usuário por extenso.
Monitores secundários
Os 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 poderá ser exibida apenas na tela principal e todas as outras telas deverão estar 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.