Líder en confianza digital para la era de la inteligencia artificial y la computación cuántica.   Descubra cómo Keyfactor lo Keyfactor posible.

Conozca la diferencia entre una firma digital y un certificado digital

Certificados SSL/TLS

La criptografía de clave pública, también conocida como cifrado asimétrico, se basa en cálculos que son casi imposibles de romper con los ordenadores más rápidos de la actualidad. Sin embargo, todavía existe un problema al utilizar el cifrado con claves privadas y públicas. Se asume que las claves públicas son abiertas, lo que significa que todo el mundo tiene acceso a ellas. Nada impide que un actor malintencionado reclame una clave pública que no le pertenece. Esto crea un problema de integridad que puede resolverse utilizando la Infraestructura de Clave Pública (PKI).

Con la PKI, los usuarios pueden intercambiar información de forma segura y privada en una red insegura como Internet. Para lograrlo, la PKI utiliza dos tecnologías de nombre similar: firmas digitales y certificados digitales; ambos son componentes esenciales en el modelo de confianza de la autoridad de certificación.

Ejemplo de Firma Digital

Veamos un escenario de ejemplo para ayudar a comprender el flujo de proceso general al cifrar un mensaje utilizando firmas digitales y certificados digitales.

Permítanme presentar de nuevo a nuestros actores habituales, Alice y Bob.

  • La creación de una firma digital comienza cuando Alice utiliza su clave privada para cifrar un mensaje.
  • El resultado, también conocido como valor hash, se adjunta al mensaje y se envía a Bob.
  • Cuando Bob recibe el mensaje, primero lo descifra con la clave pública que Alice ha proporcionado, demostrando que proviene de Alice.
  • Luego, Bob pasa el mensaje por la misma función hash unidireccional y lo compara con el valor hash adjunto.
  • Si los valores hash son los mismos, el mensaje no ha sido alterado.
  • Bob necesita demostrar la autenticidad de su clave pública a Alice. Debe obtener un certificado digital registrando su clave pública e información sobre sí mismo ante una autoridad de certificación. A Bob se le emite un certificado que contiene su clave pública y la información que proporcionó. La CA utiliza entonces su clave privada para firmar digitalmente el certificado de Bob y adjunta la clave pública de la CA al nuevo certificado de Bob.
  • Bob muestra a Alice su nuevo certificado digital. Ella puede probar que la clave pública de Bob es válida descifrando y validando la firma utilizando la clave pública de la autoridad de certificación.
  • Luego, Alice pasa el certificado de Bob por la misma función hash unidireccional utilizada cuando se creó el certificado. La clave pública de Bob es auténtica si el valor hash coincide con el proporcionado en el certificado.
  • Si los valores hash no coinciden, entonces algo en el certificado de Bob ha sido modificado desde que la CA lo firmó por última vez. Por lo tanto, Alice no puede confiar en la información del certificado, incluida la clave pública de Bob.

 

Bob ahora sabe si puede confiar en que Alice ha firmado digitalmente el mensaje y ha verificado si este ha sido modificado.

Ejemplo de Certificados Digitales

Los certificados PKI X.509 distribuyen de forma segura las claves públicas para garantizar que estas pertenezcan a propietarios legítimos y no sean falsificadas por actores malintencionados. Los certificados X.509 son creados y firmados por una autoridad de certificación de confianza.

Alice y Bob están de vuelta, y esta vez Alice quiere confirmar la autenticidad del certificado firmado de Bob.

  • Bob necesita demostrar la autenticidad de su clave pública a Alice. Debe obtener un certificado digital registrando su clave pública e información sobre sí mismo ante una autoridad de certificación. A Bob se le emite un certificado que contiene su clave pública y la información que proporcionó. La CA utiliza entonces su clave privada para firmar digitalmente el certificado de Bob y adjunta la clave pública de la CA al nuevo certificado de Bob.
  • Bob le muestra a Alice su nuevo certificado digital. Ella puede probar que la clave pública de Bob es válida descifrando y validando la firma mediante la clave pública de la autoridad de certificación.
  • Luego, Alice introduce el certificado de Bob en la misma función hash unidireccional utilizada cuando se creó el certificado. La clave pública de Bob es auténtica si el valor hash coincide con el proporcionado en el certificado.
  • Si los valores hash no coinciden, entonces algo en el certificado de Bob ha sido modificado desde que la CA lo firmó por última vez. Por lo tanto, Alice no puede confiar en la información del certificado, incluida la clave pública de Bob.

Tipos de Autoridades

La autoridad de registro (RA) es un servidor que espera a que los clientes envíen sus Solicitudes de Firma de Certificado (CSR). Normalmente, la creación de un certificado de clave pública se inicia cuando el sujeto emite una solicitud a la RA. El sujeto genera un par de claves, que luego se envía junto con una solicitud de certificado a la RA.

Cuando las solicitudes son recibidas, validadas y firmadas, la autoridad de certificación puede crear un certificado a partir del par de claves enviado. La RA valida y firma la CSR, que luego se envía a una autoridad de certificación.

Si el par de claves generado por el sujeto es inválido o la solicitud no contiene la información necesaria para crear un certificado válido, la solicitud no se reenvía a una autoridad de certificación. Esto reduce la carga sobre las autoridades de certificación.

Las autoridades de certificación son entidades de confianza para una o más organizaciones, con la responsabilidad de crear y firmar certificados de clave pública. Opcionalmente, una autoridad de certificación puede emitir las claves del sujeto o recibirlas del sujeto a través de una Autoridad de Registro.

Las autoridades de certificación se consideran de confianza porque poseen un certificado de CA firmado por otra CA de confianza; también pueden ser responsables de las revocaciones de certificados.

La CA gestiona esta tarea manteniendo una estructura de datos denominada lista de revocación de certificados (CRL). Una CRL contiene identificadores para todos los certificados revocados emitidos por la misma CA. La autenticidad de la propia CRL se demuestra firmándola digitalmente de forma similar a un certificado de clave pública.

Una autoridad de validación puede verificar un certificado descargando la CRL de una CA, verificando la firma y luego comprobando si el certificado está en la CRL. Si se encuentra en la CRL, el certificado es inválido. De lo contrario, se considera un certificado válido.

Otra forma de gestionar la revocación de certificados es utilizando el Protocolo de Estado de Certificado en Línea (OCSP). El protocolo resuelve el problema de que una CRL crece con cada certificado revocado. Cada vez que un certificado necesita ser verificado, el cliente debe descargar la CRL completa. OCSP, en cambio, permite a un cliente consultar si un certificado es válido en lugar de descargar una CRL. El informe establece que cada respuesta a un cliente debe estar firmada para que el cliente pueda verificar su autenticidad.

Tipos de Certificados X.509

X.509 es un protocolo ampliamente aceptado que regula el formato de un certificado digital. Se han definido tres versiones del estándar X.509:

  • La versión 1 de X.509 se publicó por primera vez como parte del estándar de Servicios de Directorio X.500 de la UIT en 1988.
  • La versión 2 de X.509 añadió dos nuevos campos al formato en 1993.
  • La versión 3 de X.509 define el formato para las extensiones de certificado utilizadas para almacenar información adicional sobre el titular del certificado y para regular el uso de los certificados.

Los certificados X.509 suelen adjuntar una firma digital con una clave pública, un período de validez, un emisor, un sujeto y un conjunto de extensiones. Las extensiones describen características adicionales del certificado, como atributos extra o restricciones en su uso.

Los certificados X.509 deben cumplir los siguientes tres requisitos:

1. Existe una ruta de verificación desde el certificado del servidor hasta un certificado raíz de confianza;

2. Los atributos del certificado en la ruta de verificación cumplen criterios específicos para dicha verificación;

3. El certificado no figura en el contenido de ninguna CRL actual ni en la respuesta de una solicitud OCSP.

 

La PKI X.509 consta de cuatro componentes diferentes: 

  1. Un servidor de entidad final que solicita un certificado digital firmado
  2. Una autoridad de certificación raíz que puede emitir y verificar certificados digitales
  3. Una autoridad de registro que actúa como intermediario, y
  4. El usuario final que desea verificar el certificado de clave pública de un servidor.

 

Los certificados raíz, a menudo denominados raíz de confianza, son el origen de las cadenas de confianza en la PKI basada en certificados X.509. Una CA raíz puede emitir y firmar certificados de confianza, de forma externa, y asignarles funciones y propósitos específicos. Sin embargo, dado que es imposible confirmar la integridad de un certificado autofirmado, se requiere una jerarquía de certificados auditable.

Los certificados raíz X.509 se pueden clasificar en tres tipos diferentes:

  1. Certificados autoemitidos – Estos son certificados de CA en los que el emisor y el sujeto tienen los mismos valores.
  2. Certificados autofirmados – Estos son un tipo diferente de certificado de CA autoemitido donde los objetos de emisor y sujeto tienen los mismos valores. La diferencia entre un certificado autofirmado y uno autoemitido es que el certificado autofirmado se firma utilizando la clave privada correspondiente. Este tipo de certificado puede ser utilizado por la autoridad de certificación para publicitar sus claves públicas.
  3. Certificados cruzados – Este es un certificado de CA con la propiedad de que el emisor y el sujeto son autoridades de certificación diferentes. Se utilizan para confirmar y verificar la existencia de la CA del sujeto.

 

Los certificados de entidad final son certificados de clave pública emitidos por una autoridad de certificación. Estos certificados tienen la propiedad de que su clave privada correspondiente no puede utilizarse para firmar otros certificados de clave pública.

Los certificados de clave pública de entidad final se utilizan para verificar que sus claves públicas correspondientes no han sido falsificadas. Aunque todos los certificados emitidos por una autoridad de certificación son inherentemente de confianza, la CA raíz no emite certificados de entidad final directamente. Por estas razones, la CA raíz crea una capa protectora de certificados subordinados.

Los certificados subordinados residen en línea, entre los certificados raíz y los de entidad final, y se encadenan a los certificados raíz. Esto permite a los usuarios públicos validar los certificados de entidad final, incluso mientras el certificado raíz permanece fuera de línea en un Módulo de Seguridad de Hardware.

Mientras se vinculen a una CA raíz de confianza, es posible verificar toda la cadena de confianza, desde la raíz hasta el certificado de entidad final. Puede haber más de una capa de CA subordinadas. Los certificados que se encuentran entre los certificados subordinados y los certificados de entidad final a menudo se denominan certificados intermedios.

Los certificados intermedios sirven como los enlaces maestros de las cadenas de confianza. Solo pueden realizar tareas autorizadas por la CA raíz. En jerarquías públicas, una CA intermedia está autorizada a emitir únicamente certificados SSL, mientras que otra emite solo certificados S/MIME.

Otro escenario común es autorizar a diferentes CA intermedias para emitir certificados para cada departamento o ubicación en una organización. Además, podría tener una para certificar claves ECC y otra diferente para claves RSA.

La PKI también necesita un directorio para emitir, almacenar, revocar y gestionar certificados digitales X.509.

Gestión de certificados digitales

Si busca más información sobre la gestión de certificados digitales y las mejores prácticas de PKI, consulte estos recursos adicionales: