Introducción a la Criptografía en Aplicaciones Móviles

Con el paso del tiempo el terminal móvil coge más y más importancia y contiene información más relevante para nuestra privacidad (documentos privados, imágenes, configuraciones de tarjetas de crédito, etc.). En este pequeño artículo comparto la información que he recopilado sobre Criptografía en plataformas Android de una de las prácticas realizadas en el Máster en Reversing, Análisis de Malware y Bug Hunting.

Identificación de Algoritmos de Criptografía inseguros u obsoletos (OWASP-MSTG-CRYPTO-4)

Al evaluar una aplicación móvil, se debe asegurar de no utilizar algoritmos y protocolos criptográficos que tengan importantes debilidades conocidas o que sean de otro modo insuficientes para los requisitos de seguridad modernos. Los algoritmos que se consideraban seguros en el pasado pueden volverse inseguros con el tiempo; por lo tanto, es importante comprobar periódicamente las mejores prácticas actuales y ajustar las configuraciones en consecuencia.

Verificar que los algoritmos criptográficos estén actualizados y en línea con las normas de la industria. Entre los algoritmos vulnerables se encuentran los códigos de bloque anticuados (como DES y 3DES), los códigos de flujo (como RC4), las funciones hash (como MD5 y SHA1) y los generadores de números aleatorios rotos (como Dual_EC_DRBG y SHA1PRNG). Nótese que incluso los algoritmos que están certificados (por ejemplo, por el NIST) pueden volverse inseguros con el tiempo. Una certificación no reemplaza la verificación periódica de la solidez de un algoritmo. Los algoritmos con debilidades conocidas deben ser reemplazados por alternativas más seguras.

Es importante revisar el código fuente de la aplicación para asegurarse que no utiliza dichos algoritmos en ninguna de las APIs criptográficas (diferentes para cada plataforma móvil) que utilice. Las buenas prácticas que deben asegurarse son:

• Que tanto los algoritmos utilizados como la longitud de las claves aporten protección y robustez a largo plazo y sigan los estándares de la industria.
• Utilizar parámetros bien definidos:

1. 1. Salt de al menos la longitud del output de la función Hash.
   2. IVs que sean aleatorios y únicos.
   3. Gestión de las claves realizada de forma correcta.

Android Keystore

A la hora de llevar a cabo desarrollo seguro sobre Android, merece la pena dedicar tiempo a conocer y familiarizarse con la guía de recomendaciones para Criptografía en el desarrollo Android que se puede encontrar en la Bibliografía del artículo.

Android permite utilizar lo que se denomina “Sistema de almacén de claves de Android” o “Sistema Android Keystore”. Este sistema permite almacenar las claves criptográficas en un contenedor para que resulte más difícil extraerlas del dispositivo.

El sistema Android Keystore protege el material de claves contra usos no autorizados. Para ello:

1. El material de claves nunca ingresa al proceso de la propia APP. Si un atacante compromete dicho proceso, puede usar las claves de la APP pero no podrá extraer el material de claves para usarlo por ej. fuera del dispositivo Android.
2. Además, pueden vincularse a un StrongBox Keymaster o módulo de seguridad Hardware que contiene:

• • Su propia CPU.
  • Almacenamiento seguro.
  • Un generador de números aleatorios reales (TRNGs vistos en la Lección 2)
  • Mecanismos de resistencia contra alteraciones de paquetes e instalaciones de prueba no autorizadas de APPs

Esto permite que alguien que compromete el dispositivo a nivel software pueda utilizar las claves mediante una APP pero no extraerlas del StrongBox Keymaster.

Otra funcionalidad interesante de Android Keystore es que a nivel de desarrollo se puede limitar en qué contexto o con qué objetivo se utilizan las distintas claves criptográficas lo cual permite evitar usos ilícitos de las mismas.

Buenas prácticas en desarrollo Android

Además, Android proporciona una biblioteca de seguridad, mediante la cual se pueden implementar las prácticas recomendadas de seguridad en relación con la lectura y escritura de datos en reposo y la creación y verificación de claves.

La biblioteca utiliza el patrón de compilador a fin de proporcionar configuraciones predeterminadas seguras para los siguientes niveles de seguridad:

Seguridad sólida que equilibra una excelente encriptación y un buen rendimiento. Este nivel de seguridad es apropiado para aplicaciones para consumidores, como apps bancarias y de chat, y para apps empresariales que realizan comprobaciones de revocación de certificados.
Seguridad máxima. Este nivel de seguridad es adecuado para las apps que requieren un almacén de claves con copia de seguridad en hardware y la presencia del usuario para proporcionar acceso a las claves.

Autenticación biométrica

Finalmente quiero aprovechar un recurso de OWASP (MSTG-AUTH-8) para hablar sobre la autenticación biométrica en dispositivos Android:

Para ser consideradas compatibles con Android, las implementaciones de dispositivos deben cumplir con los requisitos presentados en el Documento de definición de compatibilidad de Android (CDD) . El CDD de Android 10 evalúa la seguridad de una implementación biométrica utilizando seguridad arquitectónica y suplantación de identidad:

• Seguridad arquitectónica: cuán resistente es una canalización biométrica frente al compromiso del kernel o la plataforma. Una canalización se considera segura si los compromisos del kernel y la plataforma no confieren la capacidad de leer datos biométricos sin procesar o inyectar datos sintéticos en la canalización para influir en la decisión de autenticación.
• Spoofability : Spoofability se mide por la Tasa de aceptación de spoof (SAR) del biométrico. SAR es una métrica introducida en Android 9 para medir qué tan resistente es un biométrico contra un atacante dedicado. Al medir datos biométricos, debe seguir los protocolos que se describen a continuación.

Android usa tres tipos de métricas para medir la solidez de una implementación biométrica.

• Tasa de aceptación de suplantación (SAR): define la métrica de La probabilidad de que un modelo biométrico acepte una muestra buena conocida previamente registrada. Por ejemplo, con el desbloqueo por voz, esto mediría las posibilidades de desbloquear el teléfono de un usuario usando una muestra grabada de ellos diciendo: «Ok, Google». Llamamos a estos ataques ataques de parodia.
• Tasa de aceptación de impostores (IAR) : define la métrica de la probabilidad de que un modelo biométrico acepte una entrada que pretende imitar una buena muestra conocida. Por ejemplo, en el mecanismo de voz confiable (desbloqueo de voz) de Smart Lock , esto mediría la frecuencia con la que alguien que intenta imitar la voz de un usuario (con un tono y acento similar) puede desbloquear su dispositivo. A estos ataques los llamamos Ataques de impostores.
• Tasa de aceptación falsa (FAR) : define las métricas de la frecuencia con la que un modelo acepta por error una entrada incorrecta elegida al azar. Si bien esta es una medida útil, no proporciona suficiente información para evaluar qué tan bien el modelo resiste los ataques dirigidos.

Bibliografía

• Guía OWASP para testing de seguridad en móviles: https://mobile-security.gitbook.io/mobile-security-testing-guide/general-mobile-app-testing-guide/0x04g-testing-cryptography
• Android Keystore: https://developer.android.com/training/articles/keystore
• Biblioteca de seguridad Android: https://developer.android.com/topic/security/data
• Guía de robustez ante autenticación biométrica en Android: https://source.android.com/security/biometric/measure#strong-weak-unlocks
• Guía OWASP Android Local Authentication: https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05f-Testing-Local-Authentication.md

Artículo de https://www.linkedin.com/pulse/introducción-la-criptografía-en-aplicaciones-móviles-sergio/

¿Quieres obtener el mismo conocimiento que Sergio Ruiz?