Siguiendo en la línea de los anteriores posts (Fundamentos sobre certificados digitales, primera y segunda parte), continuamos hablando de firma y certificación digital. En este caso, y a mi ver, siguiendo un orden lógico para la explicación, en la entrada de hoy nos centraremos en la cadena de confianza.
Como ya se comentó en entradas anteriores de este hilo, de cara a emplear o validar un certificado o firma digital, uno de los puntos más importantes es la confiabilidad del mismo, ya que, como se comentó, cualquiera puede generar una clave asimétrica e incluir los campos que desee en el certificado. De nuevo en base a este hecho surge la necesidad de la existencia de Autoridades de Certificación (CA), quienes se encargan de emitir certificados confiables y reconocidos. Pero, ¿como sabemos que el certificado que tenemos entre las manos ha sido emitido por una de estas entidades?
Aunque se comentará en próximas entradas el formato X.509 como estándar de generación de certificados digitales, es importante destacar que, como es natural, dicho formato contiene campos para introducir los datos del emisor (issuer). Es obvio que estos campos nos pueden parecer útiles para este fin; pero del mismo modo que el resto de campos del certificado pueden ser fijados al gusto de quien lo genere, por lo que en absoluto suponen una garantía de procedencia y autenticidad del certificado digital.
Para cubrir estas necesidades surge el modelo de cadena de confianza. Este modelo establece una relación entre certificados que permite asegurar, sin duda alguna, que dicho certificado ha sido emitido por una Autoridad de Certificación. Veamos en primer lugar como se implementa este modelo.
Como algunos habrán adelantado, la solución más obvia será firmar el certificado emitido con un certificado que “represente” a la CA. De este modo, si el certificado que firma es confiable, tenemos total certeza de que el certificado ha sido emitido por una CA, y por tanto quien lo emplea debería ser quien dice ser (siempre y cuando no se vulnere su clave privada, en la próxima entrada veremos de qué mecanismos se vale la CA para revocar y validar certificados, así como cómo dispone esta información al alcance de los usuarios finales de los mismos). Todo esto parece que suena bien, sin embargo, nos sigue dejando en el mismo punto del que partimos, ¿cómo sé que el certificado que firma el anterior es válido?
En el modelo de cadena de confianza jerárquico, las Autoridades de Certificación disponen de un certificado conocido como Certificado Raíz (Root CA), y como su nombre indica es el certificado que validará todos y cada uno de los certificados emitidos por la CA; sin embargo, este certificado no es el que firmará los certificados de suscriptor (o certificados finales), sino se empleará únicamente para firmar los denominados Certificados Subordinados (Sub-CA), y estos últimos firmarán los certificados de suscriptor (o finales). Se muestra un diagrama ejemplo del modelo jerárquico para ilustrar el funcionamiento de la cadena de confianza de certificados:
Es importante destacar que, en general, las Autoridades de Certificación emiten los certificados intermedios orientados a generar certificados de suscriptor en base a distintas tipologías, usos o unidades de negocio (por ejemplo certificados de persona física, persona jurídica, SSL, firma de código, etc.).
Sin embargo, el principal motivo de tomar esta decisión es proteger al máximo Certificado Raíz de la jerarquía. En base a los conceptos explicados en entradas anteriores, si un tercero consiguiera la clave privada de un Certificado Raíz, se comprometerían todos y cada uno de los certificados emitidos con la misma (es más sería capaz de emitir certificados en nombre de la CA). Visto de este modo, cobra sentido que los certificados finales no estén firmados con esta clave; además que en base a éste modelo jerárquico, un certificado de suscriptor firmado por el raíz no sería de suscriptor sino subordinado, con todo lo que conllevaría dar esa clave a un usuario. Este hecho propicia que se considere normalmente la clave privada del certificado raíz como la información de mayor valor y más crítica de la CA. Debido a ello, es habitual que la clave privada del certificado raíz se encuentre offline, en un dispositivo de seguridad cifrado y con medidas de alta seguridad (que también se comentarán en próximas entradas).
De cara a la validación del certificado firmado tanto por el certificado raíz como su subordinado, la CA mantiene online todas las claves públicas de su jerarquía; aunque habitualmente se suelen adjuntar al certificado de suscriptor (como se muestra en el ejemplo posterior). De modo que para validar un certificado de un suscriptor, se deberá comprobar la firma para toda la cadena de confianza de la CA emisora, quedando así clara la procedencia del mismo.
Por último, y siguiendo con la línea de ejemplos planteada en entradas anteriores, se muestra la información de la cadena de confianza del certificado SSL de www.bankia.es, que en este caso ha sido generado por VeriSign, Inc. (autoridad de certificación propiedad de Symantec).
Como se puede observar en la imagen, se describe la jerarquía de certificados de VeriSign que ha generado este certificado se suscriptor. Lo detallamos a continuación:
- Certificado Raíz: VeriSign Class 3 Public Primary Certification Authority
- Certificado Subordinado: VeriSign Class 3 Extended Validation SSL SGC CA
- Certificado de Suscriptor: www.bankia.es
El proceso de validación lo suelen realizar de forma automática los navegadores web, de modo que aunque el certificado no estuviera auto firmado (self signed), si detectara una incoherencia en la cadena de certificación consideraría el certificado no confiable y avisaría al usuario como se detalló en la entrada Fundamentos sobre Certificados Digitales (II).
A modo de curiosidad, dejo unos cuantos enlaces que os ayudarán a ver un ejemplo práctico de jerarquía de certificados, concretamente la de Verisign (Symantec):
- Listado de Certificados Raíz de Verisign: http://www.verisign.com/repository/root.html
- Descarga de certificados Raíz de Verisign: https://www.symantec.com/page.jsp?id=roots
- Listado de Certificados Subordinados de Verisign: http://www.verisign.com/support/verisign-intermediate-ca/index.html
- Jerarquía de Certificados de Verisign: http://www.verisign.com/repository/hierarchy/hierarchy.pdf
Dejo también una entrada referente al escándalo de TURKTRUST, en el que por error se firmaron dos certificados de suscriptor directamente con el certificado raíz, lo que tuvo consecuencias desastrosas: http://www.securitybydefault.com/2013/01/algunas-reflexiones-sobre-el-ultimo-ca.html
Gracias de nuevo por leernos y como siempre quedo a la espera de vuestros comentarios.
Muy correcta la explicación. Esperando futuras entregas, ya que este tema nos interesa en nuestro site.
Revisando el caso TurkTrust, parece algo sospechoso y, como dicen, convendría cambiar el modelo de certificaciones por otro más estricto. Al final, el usuario se siente seguro con el TLS pero eso muchas veces quiere decir poco.
Muchas gracias por tu valoración Alejandro.
Respecto al caso de Turktrust, desde luego que se trata de una negligencia, aunque a mi ver el modelo no es el principal problema, sino el uso que se haga de él. Si se implantan y mantienen las medidas de control y seguridad adecuadas el modelo jerárquico ofrece una robustez más que suficiente. En cualquier caso, un modelo alternativo para la cadena de confianza que pudiera aportar mayor independencia (y con independencia quiero decir que errores puntuales sobre generación o compromiso de certificados afectara en menor grado al conjunto de certificados emitidos en la cadena de confianza).