BLOG

Claves en Software: el eslabón más débil del ecosistema PKI.

by | Mar 16, 2018 | Identificación y Firma Digital, Más leídos

[wtr-time]

¿Por qué tenemos que proteger nuestros certificados con claves privadas?

Si un atacante obtiene acceso a una clave privada, puede actuar como el titular y hacer todo lo que dicho titular pueda, es decir:
Pueden firmar en tu nombre, o acceder tu a información privada y cifrada. Además de las posibles pérdidas materiales, cuando la confianza en tu imagen se pierde, es muy dificil, y en muchos casos imposible, recuperarla. Este efecto es en muchos casos del tipo dominó, donde la percepción de seguridad desaparece generando consecuencias devastadoras no sólo para una organización sino para todo el ecosistema de confianza.

El eslabón más débil

En un enfoque pragmático, el eslabón más débil de un entorno PKI es normalmente el tratamiento inseguro de las claves en los módulos criptográficos por software.

Las claves privadas de los certificados digitales pueden ir almacenadas en tarjetas chips, tokens, hsms y también estar almacenadas en archivos de software (denominados también módulos de software). El formato que normalmente se emplea para estos módulos de software se trata de un archivo donde va almacenado el certificado digital, su correspondiente clave privada y opcionalmente los certificados digitales de las CAs que forman parte de la PKI. Ese archivo está a su vez cifrado con una password (o PIN). Esta password de cifrado es la que en definitiva permite dar acceso a los datos y clave privada, y como cualquier otra password de acceso, se puede atacar por fuerza bruta. Obviamente el éxito ó fracaso de ese tipo de ataque va en función de la técnica y calidad de la herramienta del atacante y la robustez del módulo de software.

Lamentablemente, los piratas informáticos conocen la existencia de dichas passwords y su atención pasa de robar un dato a robar las passwords (o PINs) que dan acceso a los datos y claves privadas. Estos ataques muchas veces ocurrirán sin que lo sepas y son mucho más simples de realizar en módulos de software que en módulos de hardware.

Un ejemplo concreto: PKCS#12 es un módulo de software con un estándar para almacenar certificados y claves privadas, y se puede crackear por fuerza bruta, tal como muchos módulos de software. Sabía que, dependiendo de diferentes factores, la seguridad de un módulo de software puede romperse en cuestión de minutos, o incluso segundos. Si le interesa hacer una prueba por Usted mismo, puede buscar en la web y descargarse un programa gratuito para acceder por fuerza a un modulo de software de este tipo, obtener la password y hacer una firma digital. Si Usted es programador, o conoce alguno, y quiere ver código fuente de ejemplo para romper la seguridad de un módulo de software atacándolo por fuerza bruta, puede descargar un código fuente de ejemplo aquí.

¿De donde surge la falta de seguridad del software?

El software fue el primer medio de almacenamiento de los certificados y sus claves privadas, y desde el inicio de la expansión de la tecnología PKI se evidenciaba que, a pesar de la fortaleza de la criptografía asimétrica,  el punto vulnerable era su mecanismo de almacenamiento utilizando tecnologías inseguras. Las vulnerabilidades de los módulos de almacenamiento a mediados de los años 90 dieron lugar al comienzo de los estándares internacionales como FIPS para establecer como proteger claves.

Los problemas a gran escala del uso de módulos de software eran reales a pesar que los involucrados intentaban evitar de su conocimiento público, y fueron evidentes en casos como el que New York Times reportaba en el año 2000: “… los científicos recientemente demostraron un programa simple que puede extraer las claves secretas bloqueadas en un servidor web utilizado para procesar transacciones de tarjetas de crédito …”.

Ubicar las claves almacenadas en disco o en memoria en aquel momento, y en muchos casos aún hoy, resultaba muy simple para los criptólogos. La naturaleza randómica de las claves criptográficas las hace facilmente ubicables en un medio de almacenamiento. ¿Puede Usted ver un patrón de este tipo en el conjunto de datos de la siguiente imagen?

Claves en Software: el eslabón más débil del ecosistema PKI.

Los criptólogos de la empresa inglesa NCIPHER encontraban esto tan sencillo que lo llamaban un “lunch hack”, porque podían ejecutar una búsqueda para identificar las claves en su descanso para el almuerzo.

Sin la consideración de herramientas adicionales especializadas en esta tarea de hacking, se había demostrado que los equipos que protegían las claves en software estaban en riesgo y que las claves se podían encontrar. Es así que las consultoras y publicaciones especializadas de aquella época empezaron a hacerse eco de la importancia del uso de módulos de hardware para asegurar las claves privadas, tal como lo expresaba Gartner en 2002:

La seguridad por Software es una seguridad ‘soft’: por lo que el hardware es un requisito. Las empresas y los proveedores deben crear la infraestructura de hardware para una gestión eficaz a largo plazo de claves y certificados dentro de la empresa”.

Entre otros gigantes de la industria, Apple, Microsoft, Google, o la comunidad de Software libre han cometido errores en la programación del uso de criptografía en su software, y no están libres de fallos que expongan información de sus usuarios.  

En sus recientes reportes de seguridad de software anuales para 2015 y 2016, Veracode, una reconocida compañía de CA Technologies líder en seguridad de software a lo largo del ciclo de vida de su desarrollo, indica que los problemas criptográficos son la segunda vulnerabilidad más importante encontrada en las aplicaciones.

Claves en Software: el eslabón más débil del ecosistema PKI.

Cuando el software criptográfico falla, cuáles son las causas de estos fallos? ¿Algoritmos? ¿Bibliotecas de criptografía? ¿Las aplicaciones utilizan incorrectamente esas bibliotecas? ¿O es algo completamente diferente? ¿Están fallando debido a las debilidades en los algoritmos criptográficos subyacentes?. Veamos algunas razones y ejemplos que hacen inseguro a un módulo de criptografía por  software:

Almacenamiento vulnerable

Alacenar o tratar contenedores criptográficos en medios de almacenamiento como discos duros en PCs o servidores los hace vulnerables a copias y extracción por terceros, quienes por diferentes técnicas pueden luego utilizar dichos contenedores. Entre dichas técnicas encontramos los ataques por fuerza bruta que mencionabamos al inicio de este artículo.

Operaciones desprotegidas en memoria que exponen las claves en claro

Al momento de ejecución de las tareas, las passwords, PINs y claves privadas de los módulos de software son utilizadas en claro en la memoria RAM del computador, un ambiente potencialmente inseguro y objeto de ataques de diferentes tipos. Según la consultora ABI Research, la ventaja de las soluciones basadas en hardware es que se evitan muchos de los inconvenientes típicos de las soluciones basadas en software, como su vulnerabilidad a los ataques dirigidos a la clave de cifrado almacenada en la memoria.

Mal uso de librerías criptográficas y fallos en la programación

Los investigadores del MIT analizaron errores criptográficos informados en la base de datos de vulnerabilidades y exposiciones comunes en un período de 5 años. Encontraron que el 83% se debe al mal uso de las librerías de cifrado por parte de los desarrolladores de aplicaciones.

Defectos de diseño

No siempre las construcciones criptográficas tienen un buen diseño. Considerando que deben contemplarse todos los casos de vulnerabilidades posibles, existen múltiples posibilidades para introducir serios defectos de diseño en el uso de algoritmos criptográficos.

Bugs en librerias criptográficas

Para progamador un módulo criptográfico de software se necesita una librería criptográfica, y si ésta tiene bugs, nuestro módulo está en riesgo. Un popular ejemplo es el bug Heartbleed. Este bug (CVE-2014–0160) fue introducido como una implementación incorrecta en el muy difundido OpenSSL (y con esto nos referimos al 66% de internet). Cuál fue el tipo de filtración que puede producir? Sin ninguna información privilegiada, y sin dejar rastro, fue posible obtener las claves secretas utilizadas para certificados digitales X.509, nombres de usuario y passwords, emails y comunicaciones críticas de organizaciones.

Sistemas operativos y aplicaciones con error o ‘puertas traseras’

Todo equipo tiene su sistema operativo y aplicaciones. Los mismos tienen errores, y éstos pueden afectar directamente la seguridad de los contenedores de software. Por ejemplo, un error de Apple en 2014 conocido como Goto (CVE-2014-1266), donde se omitían todas las comprobaciones de certificados digitales para conexiones SSL/TLS en dispositivos iOS y Mac, aceptaba cualquier certificado digital no válido, lo que hacía que la conexión insegura y susceptible a ataques Man in the Middle.

Configuraciones erróneas o inseguras

Similares al desarrollo de aplicaciones, los errores en configuraciones o las configuraciones débiles en seguridad pueden afectar el módulo de software. El ataque DROWN de romper las conexiones TLS a través de SSLv2 es un buen ejemplo de esto. Es posible que esté utilizando una conexión TLS bastante segura para comunicarse con un servidor web, pero si el servidor web todavía admite (que no debería) el viejo SSLv2, un atacante puede explotarlo para romper la seguridad provista por TLS y obtener sus claves y otra información sensible. SSLv2 hace tiempo que se considera roto, y ninguno de los clientes lo usa para conexiones seguras. Pero investigadores descubrieron que de 36 millones de servidores HTTPS que probaron, 6 millones (aproximadamente el 17%) todavía son compatibles con SSLv2.

Conclusiones

El error crítico cometido por muchas empresas y personas es pensar que sus certificados con clave privada están seguros en un módulo de software. Dejar un certificado y su clave privada en un módulo de software en servidores o computadores personales, es muchas veces como instalar un sofisticado candado en la puerta de entrada pero luego dejar la llave debajo de la alfombra.

Si tuvieramos que resumir, en mi opinión la diferencia principal entre protección vía software y vía hardware puede simplificarse de la siguiente forma: mientras en la criptografía basada en software las claves criptográficas residen y son utilizadas en una memoria (en gran medida desprotegida) del servidor o computador con sistemas operativos y aplicaciones potencialmente riesgosas; en la criptografía basada en hardware las claves son almacenadas y utilizadas en forma segura dentro de un módulo de seguridad de hardware, en un ambiente controlado y especializado para tales fines, con una memoria protegida y físicamente inviolables a prueba de manipulaciones.

“… a diferencia del software, la criptografía basada en hardware garantiza la confidencialidad, integridad y autenticidad de las claves criptográficas y, además, proporciona seguridad con respecto a la integridad y autenticidad del algoritmo criptográfico, lo que refuerza el nivel general de seguridad“. KPMG, 2002.

La mayoría de los marcos de políticas y prácticas para la gestión de claves de firmas especializadas reconocidas tienen en común algunas recomendaciones: Las claves deberían existir como texto en claro sin formato sólo dentro de un módulo de seguridad inviolable; De lo contrario, mientras no son activadas para su uso, podrían estar almacenadas en software pero cifradas previamente con un mecanismo basado en hardware y divididas en fragmentos, administradas usando control de acceso multifactor con conocimiento dividido; Reconocen la importancia de las validaciones de seguridad independientes y las pruebas de conformidad, por ejemplo FIPS, Common Criteria y certificaciones específicas de la industria a la que sirven (p.e. QSCD); y destacan la importancia de la resistencia a ataques y la escalabilidad.

En concreto, con sus sistemas y datos protegidos por módulos de hardware del tipo HSM, sus claves se pueden controlar de forma centralizada y podrá gestionar de forma segura todo el ciclo de vida de las mismas incluyendo su creación, gestión, acceso, uso y destrucción en un perímetro de alta seguridad protegido.

 

Lazar et. al., Why does cryptographic software fail? A case study and open problems, APSys, 2014, https://people.csail.mit.edu/nickolai/papers/lazar-cryptobugs.pdf