Certificate Pinning en aplicaciones móviles y de escritorio

El TLS estándar confía en cualquier certificado firmado por cualquiera de las aproximadamente 150 CA raíz preinstaladas en el sistema operativo. Si una CA raíz se ve comprometida o es obligada a colaborar, un atacante puede obtener un certificado para cualquier dominio e interceptar el tráfico TLS. El certificate pinning restringe la confianza a un certificado o una clave pública específicos, independientemente de qué CA los haya firmado. Una aplicación con pinning rechaza las conexiones a sus servidores a menos que el servidor presente exactamente el certificado o la clave esperados. Esta protección es especialmente valiosa para las aplicaciones móviles, cuyos usuarios no pueden inspeccionar el tráfico de red y cuyas soluciones MDM corporativas pueden instalar raíces de CA empresariales.

Existen tres niveles de granularidad para el pinning: (1) Pin del certificado completo: debe coincidir exactamente el certificado codificado en DER. Es el método más frágil, ya que cualquier renovación del certificado lo interrumpe. (2) Pin de clave pública: solo se comparan los bytes de SubjectPublicKeyInfo (SPKI). Sobrevive a la renovación del certificado si se conserva el mismo par de claves. (3) Hash de SPKI: se almacena SHA-256(SPKI) en lugar de la clave sin procesar. Este es el enfoque de HTTP Public Key Pinning (HPKP) y de Android Network Security Config. Se prefiere el pinning de clave pública / SPKI: sobrevive a la rotación de la CA y a la renovación del certificado, y sigue detectando ataques MITM con un par de claves diferente.

Android (API 24 o posterior) proporciona un mecanismo declarativo de pinning mediante el archivo XML Network Security Config. El archivo res/xml/network_security_config.xml especifica los pins por dominio: pin-set con digest="SHA-256" y el hash de SPKI codificado en base64. La aplicación referencia este archivo en AndroidManifest.xml mediante android:networkSecurityConfig. Android aplica los pins a todas las conexiones HTTP realizadas mediante HttpsURLConnection y OkHttp estándar, cuando se utiliza el administrador de confianza de la plataforma. El pin-set requiere al menos un pin de respaldo (una clave diferente o un pin de CA) para evitar el bloqueo si la clave principal se ve comprometida. La expiración del pin, mediante el atributo expiration, obliga a actualizar las aplicaciones antes de que los pins queden obsoletos.

Las aplicaciones de iOS implementan el pinning en los delegados de NSURLSession. El método delegado URLSession(_:didReceive:completionHandler:) recibe el objeto de confianza del servidor. La aplicación llama a SecTrustEvaluateWithError para validar la cadena, extrae el certificado hoja mediante SecTrustGetCertificateAtIndex(trust, 0), exporta sus bytes de SPKI, calcula su hash con SHA-256 y lo compara con el pin almacenado. TrustKit, una biblioteca de código abierto, encapsula este patrón mediante un pinning basado en configuración y admite varios pins, coincidencia de subdominios y un modo de solo informes. App Transport Security (ATS) de Apple es independiente del pinning: ATS impone versiones TLS mínimas, pero no fija claves.

HTTP Public Key Pinning (HPKP, RFC 7469) intentó añadir pinning a los navegadores web mediante encabezados de respuesta HTTP: Public-Key-Pins: pin-sha256="base64=="; max-age=5184000; includeSubDomains. El navegador recordaba el pin durante el periodo indicado por max-age y rechazaba las conexiones a claves que no coincidieran. Chrome declaró obsoleto HPKP en 2017 y lo eliminó en 2019 debido a fallos catastróficos: una sola configuración incorrecta o la pérdida de una clave podía bloquear permanentemente a los usuarios fuera de un sitio web sin ninguna vía de recuperación. HPKP está, en la práctica, muerto para los navegadores web; el pinning a nivel de aplicación en aplicaciones móviles sigue siendo viable porque las actualizaciones de la aplicación pueden incluir pins nuevos.

OkHttp, ampliamente utilizado en Android, admite pinning mediante CertificatePinner: CertificatePinner.Builder().add("api.example.com", "sha256/AAAA...==", "sha256/BBBB...==").build(). El segundo pin es el de respaldo. OkHttp verifica que al menos un pin coincida con cualquier certificado de la cadena del servidor: hoja, intermedio o raíz. Esto permite fijar un pin a una CA intermedia, que sobrevive a la rotación del certificado hoja, o a la CA raíz, que sobrevive a la rotación de la CA intermedia. OkHttp lanza una SSLPeerUnverifiedException con un mensaje útil que enumera los hashes de SPKI reales del servidor, lo que facilita extraer pins durante el desarrollo.

El pinning eleva el nivel de dificultad para interceptar tráfico, pero no es imposible de vulnerar. Técnicas habituales para eludirlo en dispositivos móviles: (1) Hooks de Frida: inyectar JavaScript en el proceso de la aplicación para interceptar el método de verificación del pin y hacer que devuelva true incondicionalmente. (2) Herramientas SSLUnpinning: scripts automatizados de Frida/Objection dirigidos a bibliotecas de pinning habituales (TrustKit, OkHttp, SecTrust nativo). (3) ROM personalizada: obtener acceso root al dispositivo y modificar la pila TLS. (4) Reempaquetado: descompilar el APK, modificar la configuración de pinning y volver a empaquetarlo con un certificado nuevo. (5) Parcheo de memoria: modificar el bytecode de verificación durante la ejecución. Mitigaciones: detección de root/jailbreak, ofuscación del código y comprobaciones de integridad (SafetyNet/App Attest).

El mayor riesgo operativo del certificate pinning es el auto bloqueo: si se pierde la clave de producción o el certificado caduca y el respaldo no está disponible, los usuarios quedan bloqueados hasta que se publique una actualización de la aplicación, lo que puede tardar de días a semanas. Prácticas recomendadas: (1) Fije siempre al menos dos claves: la clave actual y una clave de respaldo generada previamente y almacenada sin conexión (en un HSM o en un entorno aislado). (2) Establezca una fecha de expiración del pin y publique actualizaciones de la aplicación antes de esa fecha. (3) Supervise los fallos de pin mediante el modo de solo informes antes de aplicar el pinning. (4) Mantenga un proceso de actualización urgente de la aplicación, con revisión acelerada, para incidentes de rotación de pins. (5) Fije el pin en el nivel de la CA intermedia, no en el certificado hoja, para permitir la rotación del certificado hoja sin actualizar la aplicación.

Las aplicaciones de escritorio escritas con Electron, Qt o código nativo pueden implementar pinning mediante las API de su pila TLS. Las aplicaciones de Electron utilizan el evento app.on("certificate-error") y session.setCertificateVerifyProc() para implementar una verificación personalizada. El código de red de Qt utiliza QSslSocket con una devolución de llamada de verificación personalizada. Las aplicaciones de .NET utilizan ServicePointManager.ServerCertificateValidationCallback. Las aplicaciones nativas de Windows utilizan WinHTTP con inspección manual de certificados. Las aplicaciones de escritorio afrontan retos adicionales: la interceptación TLS a nivel del sistema operativo mediante proxies corporativos es habitual y los usuarios pueden esperar que la funcionalidad de proxy funcione, lo que exige decidir si el pinning se aplica únicamente a endpoints específicos.

El certificate pinning complica las pruebas automatizadas y los procesos de CI/CD. Las pruebas de integración que realizan llamadas HTTPS reales a servidores de staging deben utilizar certificados de prueba cuyos hashes de SPKI estén fijados en una configuración de prueba. Enfoques posibles: (1) Variantes de compilación: la compilación de depuración/staging incluye los pins del servidor de staging; la compilación de lanzamiento fija los de producción. (2) Sobrescrituras de Network Security Config: Android permite una configuración de pins exclusiva para depuración. (3) Servidor simulado: interceptar en la capa del cliente HTTP antes de TLS, evitando por completo el pinning. (4) CA autofirmada para CI: emitir certificados de prueba desde una CA de CI cuya raíz solo sea de confianza en las compilaciones de prueba. Nunca publique en producción una compilación con el pinning desactivado.

Los pins de certificados suelen ser hashes de claves públicas RSA o EC. Cuando comience la migración poscuántica, los servidores pasarán a utilizar ML-DSA (CRYSTALS-Dilithium) o claves híbridas. Los hashes de SPKI fijados cambiarán porque cambiarán el tipo y la codificación de la clave. Las aplicaciones que fijen certificados hoja o claves públicas necesitarán actualizaciones coordinadas: (1) Publique una nueva versión de la aplicación con el hash de SPKI poscuántico como pin de respaldo antes de migrar el servidor. (2) Complete la migración del servidor. (3) Publique una actualización que elimine el pin clásico antiguo. El periodo de transición requiere una coordinación cuidadosa. Las aplicaciones que fijen CA intermedias o raíz se verán menos afectadas: solo cambia la clave de la CA, y no necesariamente en el mismo calendario que los certificados hoja.

¿Por qué se prefiere fijar el hash de SubjectPublicKeyInfo (SPKI) en lugar del certificado completo?

Certificate pinning restringe la confianza de TLS a un certificado o una clave pública específicos, lo que protege frente al compromiso de una CA y los ataques MITM. Se prefiere fijar el hash de SPKI (SHA-256 de SubjectPublicKeyInfo) en lugar del certificado completo porque ofrece mayor resiliencia ante las renovaciones. Android utiliza Network Security Config en formato XML; iOS utiliza un delegado de URLSession con las API de SecTrust; OkHttp admite CertificatePinner. Incluya siempre un pin de respaldo para evitar bloquearse a sí mismo. HPKP (la cabecera HTTP del navegador) está obsoleto. El pinning puede eludirse mediante hooks de Frida y modificaciones de la ROM. La migración a claves poscuánticas requiere actualizaciones coordinadas de la aplicación para actualizar los hashes de SPKI.