Incidente de Comodo, reflexiones sobre el uso de Entidades de Certificación
Esta semana hemos tenido otro incidente de seguridad vinculado al prestador de servicios de certificación COMODO preocupante y que apunta hacia una posible futura tendencia que podrá seguir explotándose por parte del crimenware.
La noticia técnica de lo ocurrido está muy detallada en las dos noticias Una-al-día de los días 24 y 25 de este mes.
Mi reflexión se orienta más hacia la perspectiva de la "gestión de la seguridad" y la necesidad de proteger todos los eslabones de la cadena. Para ello, con carácter previo, creo conveniente explicar la lógica de la protección en la que se basan las Infraestructuras de clave pública (PKI). Tal como se expresa en Wikipedia, una infraestructura de clave publica (o, en inglés, PKI, Public Key Infrastructure) es una combinación de hardware y software, políticas y procedimientos de seguridad que permiten la ejecución con garantías de operaciones criptográficas como el cifrado, la firma digital o el no repudio de transacciones electrónicas.
Por tanto, la robustez y seguridad del uso de estas tecnologías no se basan tan solo en la potencia o fiabilidad del hardware o software utilizado sino en la buena gestión operativa de los procedimientos de seguridad usados por el propio personal de la PKI más los procesos internos establecidos por las prácticas de certificación (CPS). En este caso, los procesos son tanto o más importantes que la tecnología. La siguiente figura ilustra las piezas de una PKI y su funcionamiento como mecanismo de generación de confianza. De hecho, parece que el problema de seguridad del incidente con la PKI Comodo se debe a una violación de las propias prácticas de certificación tal como explican en el blog Securitymusings.com. Comodo ha reconocido que el usuario y contraseña de una Entidad de registro había sido comprometido pero en sus propias prácticas de certificación se indica que el acceso se realiza mediante métodos de autenticación fuerte. Es decir, en casa de herrero cuchillo de palo. De nuevo otro ejemplo más de que el factor humano es habitualmente el punto de fallo más habitual. La tecnología es fiable pero cuando es mal utilizada por personas es cuando vienen los problemas.
Toda PKI siempre tiene las siguientes piezas operativas dando servicio:
Pensando en la propia seguridad del funcionamiento de una PKI hay varios "talones de Aquiles" que deben ser muy bien protegidos y controlados para garantizar la fiabilidad del proceso que serían los siguientes puntos:
- Certificado Raiz, dado que es el elemento que otorga confianza al resto de certificados al ser usado para firmar certificados generados con dicha entidad de confianza, es el corazón del sistema de confianza que se monta con una PKI.
- Autoridades de registro porque son los ojos y los verificadores reales de toda la información que posteriormente va a firmar la Autoridad de certificación. Habitualmente es el punto de control donde se coteja la información que acredita o autentica al Organismo o persona respecto de los datos que figurarán en el certificado digital que firmará la autoridad raíz. Por tanto, si esta pieza falla, se pueden generar certificados digitales que siendo validos, no se correspondan con datos veraces.
- Las CRL o Autoridades de Validación porque son el punto de chequeo en tiempo real de la validez o no de la información que se presenta en un certificado digital. Se supone que una de las importantes ventajas de las tecnologías PKI es que permiten en tiempo real las comprobaciones de veracidad de la información.
Sin embargo, el despliegue de estas tecnologías en la vida real ha ido mal acostumbrándonos a diferentes incidencias que son cotidianas y que ponen en riesgo la fiabilidad de las soluciones basadas en el uso de estas tecnologías PKI. Estos fallos de implantación serían los siguientes:
- Entidades de certificación "Juan Palomo" que ya fue objeto de un post en la entrada "Prestadores de servicios de certificación "Juan Palomo". El funcionamiento de las Entidades de certificación está avalado por la Ley 59/2003 de Firma Electrónica que establece desde el punto de vista legal quienes pueden ser "entidades de prestación de este tipo de servicios" y determinan ciertas condiciones a este tipo de Organismos que van a "generar confianza" para garantizar su fiabilidad. No se prohibe a nadie que lo sea pero "SI" se regula que deben como mínimo tener para poder dar estos servicios. Sin embargo, ha sido frecuente la instalación y uso de certificados "raíz" en sitios Web (para ahorrarse unos euros) que no están avaladas por nadie y que no aparecen dentro del conjunto de "Entidades Raiz" que por defecto vienen en los navegadores preinstalados. Algunos de estos casos también los documenté en su momento en los post "La e-Administración dando mal ejemplo aunque por suerte casi todos los casos ya se han ido solucionando (pero en su momento se podía acreditar que no era así como aparece en las capturas de pantalla del momento). La lista de prestadores autorizados figura en el Ministerio de Industria, Comercio y Consumo. Para los que en este momento se vean sorprendidos por esta afirmación, pueden acudir a la Web del Ministrrio y comprobar cómo la Ley 59/2003, de 19 de diciembre, de firma electrónica establece en su artículo 30, y disposición transitoria segunda, que los prestadores de servicios de certificación deberán comunicar al Ministerio de Industria, Turismo y Comercio, sus datos de identificación, los datos que permitan establecer comunicación con el prestador, los datos de atención al público, las características de los servicios que vayan a prestar, las certificaciones obtenidas para sus servicios y las certificaciones de los dispositivos que utilicen. Esta lista puede ser consultada en esta dirección.
- No verificación de la validez del certificado. Este es quizás el error más común y principalmente debido al modelo de negocio montado por la FNMT que en su momento, cuando todos los navegadores no hacían las comprobaciones pertinentes respecto a la validez del certificado pasaba completamente desapercibido pero que actualmente es origen de error en el acceso en casi todos los navegadores, obligando al usuario a generar una excepción. La esencia del buen funcionamiento de una PKI se basa en esa comprobación en tiempo real de la corrección del certificado. De hecho, estos mecanismos inicialmente se basaban en listas de certificados revocados que había que descargar y actualmente se implementan mediante el protocolo OCSP de verificación en tiempo real. Sin embargo, no todos los prestadores permiten el acceso a sus servidores OCSP (La FNMT no por ejemplo) y creo que cargarse eso es cargarse la mitad de los beneficios que aporta este mecanismo de seguridad y pone en riesgo la fiabilidad de estos sistemas.
El incidente de Comodo ha supuesto el compromiso de una entidad de registro que ha permitido generar certificados falsos. Si las comprobaciones de la validez se hicieran por defecto y en tiempo real, el problema se limitaría a detectar el incidente y revocar los certificados. Ya serían los navegadores los encargados de no ser engañados por esos certificados falsos una vez son éstos anulados. Sin embargo, las configuraciones por defecto de las versiones antiguas de los navegadores (los nuevos Firefox 4 e Internet Explorer 9, cuentan con OCSP activo por defecto).
De todo esto hay dos lecciones que debieran aprenderse:
- Las autoridades de registro tienen una responsabilidad altísima en el buen funcionamiento de la PKI y por tanto, debe tratarse como un punto crítico de la infraestructura. Su personal debe estar adecuadamente entrenado y debieran desplegarse las mínimas necesarias para dar un buen servicio dado que el compromiso de una de estas autoridades puede poner en peligro toda la infraestructura (Si llegado el caso no puede saberse cuales son certificados originales y cuales falsificados). Sin embargo, por lo que he podido vivir personalmente, no parece dársele la importancia que tienen por parte de las Prácticas de Certificación de muchos prestadores, cosa que no ocurre con el DNI-e que obliga a que las autoridades de registro estén en comisarías.
- Los mecanismos de validación en tiempo real deben estar accesibles y configurados por defecto para que sean utilizados. Es la manera de reducir la "ventana de exposición" una vez que hay problemas con los certificados y por tanto, cuanto más se trabaje en tiempo real menos serán los posibles agujeros a explotar. Pensar que estas entidades son también empleadas para verificar que los certificados no están caducados y que su no uso hace que tanto certificados revocados como caducados puedan seguir siendo usados (aunque originalmente no son ya legítimos).
Lo que ya es más preocupante es lo que apunta Chema Alonso en su post OCSP, el update de Windows Raúl y el ataque de Roberto Carlos pero eso supone un vector de ataque diferente que ya trataré otro día.
