Un inicio de sesión biométrico que un callback interceptado no puede falsear

El inicio de sesión biométrico es una de las funciones que más gustan a los usuarios de las apps bancarias: una mirada o un toque en lugar de un PIN. También es una de las funciones más fáciles de implementar de un modo que parece seguro pero no lo es.

En una auditoría de seguridad de la app Android de un banco minorista, la autenticación biométrica fue una de las áreas que reforzamos. En este artículo explicamos la debilidad habitual, cómo la cierra vincular la biometría a un CryptoObject y qué sigue sin resolver.

---

La debilidad habitual: confiar en el callback

El BiometricPrompt de Android comunica el resultado de una verificación mediante un callback. La implementación más sencilla sigue esta lógica:

1. Mostrar el diálogo biométrico.

2. Esperar a onAuthenticationSucceeded.

3. Desbloquear la sesión.

El problema está en el paso 3. En un dispositivo comprometido, una herramienta de hooking como Frida puede llamar directamente al callback de éxito. La app no tiene forma de distinguir una coincidencia biométrica real de una llamada a un método falseada.

📌 Idea clave:

Un callback dice «algo ha informado de un éxito». Una clave criptográfica que solo el sistema puede desbloquear dice «se ha producido una verificación biométrica real».

---

La solución: vincular la biometría a una clave

En lugar de confiar en el callback, la app vincula el inicio de sesión a una operación criptográfica:

1. Crear una clave en el Android Keystore que exija la autenticación del usuario antes de cada uso.

2. Envolver en un CryptoObject un Cipher o una Signature que use esa clave y pasarlo a BiometricPrompt.

3. Solo tras una coincidencia biométrica real desbloquea el sistema la clave para esa operación.

4. Usar el cifrador desbloqueado para descifrar un secreto de sesión o firmar un desafío del servidor. El inicio de sesión solo continúa si esa operación tiene éxito.

Si un atacante falsea el callback, el cifrador nunca llegó a desbloquearse. El descifrado o la firma fallan, y con ellos el inicio de sesión.

---

Decisiones de diseño que importan

1. Descifrar o firmar algo real

El CryptoObject debe proteger algo de lo que dependa realmente el inicio de sesión: un secreto de sesión o una firma que verifique el servidor. Usar el cifrador con datos de relleno e ignorar el resultado devuelve la debilidad de inmediato.

2. Decidir qué pasa cuando cambian los datos biométricos

Las claves pueden configurarse para que dejen de ser válidas cuando se registra una nueva huella o un nuevo rostro. Eso detiene a quien añade sus propios datos biométricos a un teléfono desbloqueado. También significa que la app necesita un flujo claro para reactivar la biometría mediante PIN o contraseña.

3. Mantener una alternativa

La biometría falla: dedos mojados, mascarillas, teléfonos nuevos. La alternativa con PIN o contraseña forma parte del diseño y debe estar tan bien protegida como la vía biométrica.

4. Combinarla con otros controles

Vincular la biometría a un CryptoObject cierra un hueco. La detección de root y de hooking, la validación de sesiones en el servidor y la limitación de intentos cierran otros.

---

Biometría basada solo en el callback frente a biometría vinculada a un CryptoObject

Aspecto	Solo callback	Vinculada a un CryptoObject
Qué demuestra el éxito	Una llamada a un método	Una clave que desbloquea el sistema
Callback falseado con una herramienta de hooking	El inicio de sesión se completa	El inicio de sesión falla
Esfuerzo de implementación	Bajo	Moderado
Cambio en la experiencia de usuario	—	Ninguno para el usuario

Cómo ayuda Mobian

En Mobian, la biometría vinculada a un CryptoObject fue uno de los controles de un plan de remediación de 124 tareas para la app Android de un banco minorista, junto con la protección frente a superposiciones (overlays), la detección de hooking y de emuladores y las comprobaciones contra el reempaquetado. Cada control lo verificó un paquete de pruebas de seguridad de QA independiente, no solo el desarrollador que lo construyó.

Conclusión

Un inicio de sesión biométrico que confía en un callback es tan sólido como el dispositivo en el que se ejecuta. Vincular el inicio de sesión a una clave del Keystore que el sistema desbloquea tras una coincidencia real significa que un callback falseado no le sirve de nada al atacante. La experiencia de usuario no cambia; la diferencia solo aparece cuando alguien intenta hacer trampa.

Preguntas frecuentes

¿Qué tiene de malo comprobar solo el callback de éxito biométrico?

Si una app desbloquea una sesión en cuanto se llama a onAuthenticationSucceeded, un atacante con una herramienta de hooking como Frida en un dispositivo comprometido puede llamar directamente a ese método. La app recibe un éxito sin que se haya comprobado ninguna huella ni ningún rostro.

¿Qué es un CryptoObject en la biometría de Android?

Un CryptoObject envuelve una operación criptográfica, como un Cipher o una Signature, que usa una clave del Android Keystore. Cuando esa clave se crea para exigir la autenticación del usuario, la operación solo funciona después de una verificación biométrica real por parte del sistema. Un callback falseado deja al atacante con un cifrador inservible.

¿Protege la biometría vinculada a un CryptoObject frente a cualquier ataque?

No. Cierra el hueco del callback falseado, pero debe combinarse con otros controles, como la detección de root y de hooking, las comprobaciones de sesión en el servidor y una alternativa con PIN o contraseña. Ningún control por sí solo hace segura una app.

¿Qué ocurre cuando un usuario registra una nueva huella?

Las claves pueden configurarse para que dejen de ser válidas cuando se registran nuevos datos biométricos. Así se impide que alguien que añade su propia huella a un teléfono desbloqueado la use para iniciar sesión, pero la app necesita entonces un flujo claro para volver a activar la biometría, normalmente mediante PIN o contraseña.

¿Qué categoría de OWASP cubre esto?

Principalmente M3: Insecure Authentication/Authorization del OWASP Mobile Top 10 (2024). Vincular la clave a la biometría también contribuye a las buenas prácticas de M10, Insufficient Cryptography.