La seguridad de su hardware funciona correctamente. Ese no es el problema.

Escuchamos con frecuencia una objeción similar: “Ya usamos Android StrongBox. Tenemos intercambio de claves ECDH. Nuestras claves nunca salen del hardware. ¿Por qué necesitaríamos criptografía de caja blanca además de eso?”. 

Es una pregunta válida. StrongBox, Keystore con respaldo TEE y ECDH son tecnologías realmente sólidas. Descartarlas sería intelectualmente deshonesto e inútil. Así que, en lugar de descartarlas, analicemos qué protegen realmente y dónde están sus vulnerabilidades.

La analogía de la bóveda y por qué está incompleta. 

La seguridad del hardware es excelente en una cosa: mantener las claves safe Dentro de una bóveda. StrongBox genera claves, las almacena y realiza operaciones criptográficas sin exponer jamás el material de clave en bruto. Esa es una protección real y es importante. 

Pero aquí está la pregunta que la mayoría de los arquitectos de seguridad no se hacen: ¿Está la bóveda en la ruta de las operaciones más importantes? 

Para las aplicaciones de Android que realizan conexiones estándar con servidores (mediante HttpsURLConnection, OkHttp o API similares gestionadas por el sistema operativo), la respuesta es, en general, no. La pila TLS de Android se ejecuta a través de BoringSSL y Conscrypt, dos bibliotecas de software que gestionan el intercambio de claves ECDH completamente por software, sin pasar por StrongBox ni TEE Keystore. Las claves de sesión TLS existen como bytes sin procesar en la memoria, independientemente del hardware del dispositivo. 

Esto no es un fallo en el diseño de Android, sino una realidad arquitectónica que la mayoría de las conversaciones sobre seguridad de aplicaciones pasan por alto. Tu bóveda es excelente. Para TLS, la bóveda no está en el edificio. 

Cuando el binario es la superficie de ataque 

Dejemos TLS a un lado por un momento. Consideremos una aplicación que utiliza claves basadas en hardware para sus operaciones criptográficas: debidamente configuradas, derivadas de ECDH y almacenadas de forma segura en StrongBox. Se trata de una configuración robusta. 

Ahora bien, ¿qué hace realmente un atacante con tu aplicación? No intenta extraer la clave de StrongBox, eso es difícil. Descarga tu aplicación, ejecuta un desensamblador y lee tu código. 

Lo que encuentran es la lógica del handshake: el protocolo que usa tu aplicación para comunicarse con tu servidor, el flujo de autenticación, la estructura de la API. Con ese conocimiento, no necesitan tu clave. Crean una aplicación modificada que completa un handshake de apariencia legítima desde cero. StrongBox en su El dispositivo ahora contiene una clave en la que confía su servidor. 

El ataque más sofisticado no consiste en leer los datos descifrados de un usuario, sino en comprender el protocolo lo suficientemente bien como para falsificar solicitudes API autenticadas, potencialmente a gran escala y posiblemente desde la perspectiva de usuarios arbitrarios. La seguridad del hardware no ofrece respuesta ante esto, ya que el ataque nunca afecta al hardware. 

Esta es la brecha que existe entre la criptografía de caja blanca y el endurecimiento de aplicaciones: proteger la lógica del protocolo en sí, no solo la clave. 

El problema de la fragmentación (mientras dure) 

Dejando de lado la problemática de BoringSSL, la seguridad del hardware presenta un problema de cobertura en Android. Según el estudio DroidCCT —un análisis revisado por pares sobre la seguridad de los dispositivos Android—, StrongBox solo está disponible en el 8.7 % de los dispositivos de gama alta, el 7.2 % de los de gama media y el 0.2 % de los de gama baja. La mayoría de tus usuarios no lo tienen. 

iOS es un caso aparte: Secure Enclave está presente en todos los dispositivos iOS actuales y proporciona una sólida protección basada en hardware. El argumento de la fragmentación se aplica principalmente a Android. 

Cabe reconocer que este argumento tiene vigencia limitada. La disponibilidad de hardware mejorará con el tiempo, y algunas directrices de seguridad ya recomiendan la criptografía de caja blanca como complemento temporal de TEE mientras se consolida la adopción de hardware. Los argumentos a favor de la ingeniería inversa binaria, la certificación y la independencia del proveedor son sólidos; la fragmentación es el argumento más convincente en la actualidad. Para algunas organizaciones, en particular aquellas con restricciones regulatorias o de la cadena de suministro, reducir la dependencia de la implementación de seguridad de un único proveedor de hardware constituye en sí mismo un objetivo de diseño. 

Qué significa realmente la “Atestación a nivel de aplicación” 

Otro problema que vale la pena mencionar: su servidor completó el protocolo de enlace, pero no sabe con quién se está comunicando. 

No puede distinguir entre tu aplicación legítima que se ejecuta en un dispositivo real, una versión modificada de tu aplicación que se ejecuta en un dispositivo rooteado y un cliente completamente sintético que imitó tu protocolo de enlace tras realizar ingeniería inversa del mismo. 

La API de integridad de Google Play ayuda. MEETS_STRONG_INTEGRITY, con un nonce y una vinculación requestHash adecuados, reduce sustancialmente la superficie de evasión. Sin embargo, la reproducción limpia del dispositivo proxy sigue siendo un riesgo residual, independientemente del nivel de integridad. 

La criptografía de caja blanca proporciona una atestación a nivel de aplicación: una prueba criptográfica de que la solicitud se originó en una aplicación sin modificar que ejecuta lógica de protocolo protegida, independientemente de las señales de confianza del sistema operativo o del hardware. Se trata de una segunda señal, ortogonal, que no reemplaza a Play Integrity, sino que aborda lo que Play Integrity no puede. 

La versión más sofisticada de esto —y hacia donde creemos que se dirige la industria— es la atestación continua del comportamiento: ¿este cliente activó alguna detección de manipulación desde su última solicitud? Un servidor que puede modular su respuesta en función del nivel de seguridad del cliente en tiempo de ejecución es significativamente más resistente que uno que toma una decisión binaria de confianza/no confianza al establecer la sesión. 

La imagen completa 

La seguridad del hardware es la bóveda. La criptografía de caja blanca y el endurecimiento de las aplicaciones son el transporte blindado, que protege todo lo que tiene que salir de la bóveda y participar en el mundo real. 

En la mayoría de las operaciones TLS de Android, la bóveda no está presente en la ruta. Cuando sí lo está, no protege el protocolo, el binario ni la capa de autenticación. Esto no justifica abandonar la seguridad del hardware, sino que la considera una capa más dentro de una defensa integral, no la solución definitiva. 

Estos son cuatro de los argumentos que hemos probado internamente con nuestros equipos de ingeniería, seguridad y éxito del cliente. Hay más en la historia, incluyendo cómo se aplica esto a plataformas específicas, marcos de cumplimiento (Digital.ai Key & Data Protection cuenta con la certificación FIPS 140-3 (n.º 4910) y cumple con los requisitos regulados del sector. 

Si está evaluando la protección de aplicaciones y desea analizar en detalle cómo se aplica a su entorno, estaremos encantados de conversar con usted. Solicite una demostración hoy