Consideraciones
Se deben abordar las siguientes consideraciones para garantizar la integridad de la Confirmación de protección de Android. Si no se pueden abordar de manera satisfactoria estas consideraciones, no se puede implementar la Confirmación protegida en el dispositivo.
Consideraciones sobre el 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 diálogo de confirmación protegida está activo, el kernel no puede interferir en la integridad del contenido de la pantalla, la integridad de la entrada del usuario ni la atomicidad entre la entrada y la salida del usuario. En términos de arquitectura, 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 reemplazarse por algo completamente diferente.
Consideraciones sobre el firmware
La confirmación protegida se puede implementar en un dispositivo solo si todos los componentes involucrados tienen un firmware de confianza. La Confirmación de protección está diseñada para garantizar que el usuario tenga la oportunidad de leer un mensaje que se muestra en la IU de confianza para tomar una decisión informada sobre si continuar o no con una transacción. El controlador del panel de la pantalla es especialmente importante, ya que podría impedir que el usuario vea la IU de confianza.
Consideraciones sobre las entradas
Elige un método de entrada seguro para garantizar que los eventos de entrada que genera este método de entrada elegido no se transmitan al diálogo de confirmación protegida, a menos que el usuario genere el evento mientras ese 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 activar un cable conectado a un botón de confirmación físico.
Consideraciones sobre el controlador táctil
La Confirmación protegida puede usar botones de software en pantalla como entrada. Cada vez que el TEE controla el controlador táctil, se deben tomar medidas para limpiar 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 apps reciben la devolución de llamada de onCanceled() y saben que el usuario no eligió una acción. Las alarmas no necesitan abortar la sesión, pero sí deben notificar al usuario. No se permiten superposiciones de notificaciones de ningún tipo mientras el diálogo está activo.
Ingresa el período de gracia
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 a un diálogo de confirmación inesperado. La app de confianza debe aplicar este período de gracia.
Rotación de pantalla
El modo vertical es el único modo obligatorio, y no se admite la rotación de la pantalla. La rotación de la pantalla permite el abuso potencial en un sistema comprometido, como la ubicación engañosa de botones o la manipulación del texto del cuerpo.
Fallas en la renderización del texto del cuerpo
Hay un límite fijo de 6144 (0x1800) bytes para el texto del cuerpo, incluidos los datos adicionales que no se muestran y la información del encabezado CBOR.
Además, hay un límite flexible que se debe aplicar. Si el mensaje renderizado no se ajusta por completo al espacio de pantalla disponible, asegúrate de que se cancele la confirmación protegida y la transacción.
Si MessageSize supera el tamaño máximo permitido, tu implementación debe mostrar UIErrorMessageTooLong en promptUserConfirmation.
La práctica recomendada es dar formato al texto del cuerpo después de recibir la llamada a la API. El texto del cuerpo se debe mostrar al usuario completo.
Pantallas secundarias
Las pantallas secundarias se admiten en determinadas condiciones. Se debe mantener la integridad de la salida y la entrada del usuario, y no se puede mostrar información engañosa a través de otros medios. De lo contrario, el diálogo solo se puede mostrar 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.