Consideraciones
Se deben abordar 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 sobre el kernel de Linux
La confirmación protegida está diseñada para operar de forma segura incluso si el kernel del dispositivo está comprometido. Mientras el cuadro de diálogo 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 la salida del usuario. Arquitectónicamente, se debe evitar que el núcleo aumente la decisión del usuario y suplante 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 ser 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 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 visualización es especialmente importante, ya que podría impedir que el usuario pueda ver la IU de confianza.
Consideraciones de entrada
Elija un método de entrada seguro para asegurarse de 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 usar botones de software en pantalla como entrada. Siempre que el controlador táctil esté siendo accionado por el TEE, 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 a un evento de energía, la HAL debe informar ResponseCode::Aborted . Las aplicaciones obtienen 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 notificación 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 de confianza debe hacer cumplir 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 la 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.
Errores de representación del texto del cuerpo
Hay un límite estricto de 6144 (0x1800) bytes para el cuerpo del texto, 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 hacer cumplir. Si el mensaje presentado no cabe completamente en el espacio de pantalla disponible, asegúrese de que la Confirmación protegida se cancela y la transacción se cancela. Si MessageSize supera el tamaño máximo permitido, su implementación debe devolver UIErrorMessageTooLong en promptUserConfirmation .
La mejor práctica es dar formato al texto del cuerpo después de recibir la llamada a la API. El cuerpo del texto debe mostrarse al usuario en su totalidad.
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 cuadro de diálogo ni generar confirmaciones.