Consideraciones
Se deben tener en cuenta las siguientes consideraciones para garantizar la integridad de la confirmación protegida de Android. Si estas consideraciones no se pueden abordar satisfactoriamente, la confirmación protegida no se puede implementar en el dispositivo.
Consideraciones del kernel de Linux
La confirmación protegida está diseñada para funcionar de forma segura incluso si el kernel del dispositivo está comprometido. Mientras el cuadro de diálogo de Confirmación protegida está activo, el kernel no puede interferir con la integridad del contenido de la pantalla, la integridad de la entrada del usuario y la atomicidad entre la entrada y salida del usuario. Desde el punto de vista arquitectónico, se debe evitar que el kernel aumente la decisión del usuario y falsifique los eventos del usuario en primer lugar. El kernel no se considera confiable para este caso de uso, ya que podría estar bajo el control de un atacante o reemplazado por algo completamente diferente.
Consideraciones de firmware
La confirmación protegida se puede implementar en un dispositivo solo si todos los componentes involucrados tienen firmware confiable. La confirmación protegida está diseñada para garantizar que el usuario tenga la oportunidad de leer un mensaje mostrado en la interfaz de usuario confiable para tomar una decisión informada sobre si continuar o no con una transacción. El controlador del panel de visualización es especialmente importante ya que podría impedir que el usuario pueda ver la interfaz de usuario confiable.
Consideraciones de entrada
Elija un método de entrada seguro para garantizar que los eventos de entrada generados por este método de entrada elegido no se transmitan al cuadro de diálogo Confirmación protegida a menos que el usuario genere el evento mientras ese cuadro de diálogo está activo.
Hardware físico
Cualquier componente que pueda ser controlado por el kernel de Android, como el sistema en chip (SoC) o el circuito integrado de administración de energía (PMIC), no debe poder controlar un cable conectado a un botón de confirmación físico.
Consideraciones sobre el controlador táctil
La confirmación protegida puede utilizar botones de software en pantalla como entrada. Cada vez que el TEE acciona el controlador táctil, se deben tomar medidas para desinfectar el estado del controlador táctil.
Comportamiento esperado
Interrupciones
Si el sistema interrumpe la sesión de confirmación debido a una llamada telefónica entrante o un evento de energía, el HAL debe informar ResponseCode::Aborted . Las aplicaciones reciben la devolución de llamada onCanceled() y saben que el usuario no eligió una acción. Las alarmas no necesitan cancelar la sesión, pero sí deben notificar al usuario. No se permiten superposiciones de notificaciones de ningún tipo mientras el cuadro de diálogo esté activo.
Período de gracia de entrada
Después de que se inicia la confirmación protegida, la entrada debe permanecer inactiva durante un mínimo de 1 segundo antes de que responda a la interacción del usuario. Este período de gracia garantiza que el usuario tenga la oportunidad de reaccionar ante un cuadro de diálogo de confirmación inesperado. La aplicación confiable debe aplicar este período de gracia.
Rotacion de pantalla
Retrato es el único modo obligatorio y no se admite la rotación de pantalla. La rotación de pantalla permite la posibilidad de abuso en un sistema comprometido, como la colocación engañosa de botones o la manipulación del texto del cuerpo.
Fallos en la representación del texto del cuerpo
Hay un límite estricto de 6144 (0x1800) bytes para el texto del cuerpo, incluidos datos adicionales no mostrados e información del encabezado CBOR. Además, hay un límite suave que se debe hacer cumplir. Si el mensaje mostrado no cabe completamente en el espacio disponible en la pantalla, asegúrese de que la Confirmación protegida se cancele y la transacción se cancele. Si MessageSize excede el tamaño máximo permitido, su implementación debe devolver UIErrorMessageTooLong en el promptUserConfirmation .
La mejor práctica es formatear el texto del cuerpo después de recibir la llamada API. El texto del cuerpo debe mostrarse completo al usuario.
Pantallas secundarias
Las pantallas secundarias son compatibles bajo ciertas condiciones. Se debe mantener la integridad de la salida y la entrada del usuario, y no se puede mostrar información engañosa por otros medios. De lo contrario, es posible que el cuadro de diálogo solo se muestre en la pantalla principal y todas las demás pantallas deben estar desactivadas o en blanco. Las soluciones de transmisión y uso compartido de pantalla no pueden mostrar el diálogo ni generar confirmaciones.