La idea es asociar identidad a las claves publicas, evitando problemas de suplantación de identidad mediante Man in the Middle o Spoofing. Esto no es aplicable a los Criptosistemas Simétricos, por la obvia razón de que tienen una sola clave que debe ser secreta.

Certificados

Son mensajes que contiene al menos:

  • Información de identidad (ej: nombre)
  • Clave pública asociada
  • Fecha de emisión
  • Intervalo de validez
  • Tipo de uso de la clave:
    • Firma de mensajes
    • Cifrado de emails
    • Firma de certificados
    • Cifrados de sitios web

Estos certificados deben ser firmados digitalmente por una autoridad competente.

La idea es que al solicitar el certificado de una entidad, este pueda ser provisto por esa o cualquier otra entidad, y que se pueda verificar la identidad del certificado (a quien le pertenece, mediante su email, IP o hostname, etc.), obtener la clave pública de B para confirmar que realmente se esta comunicando con B (pues solo este tendrá la clave privada correspondiente), verificar la validez del certificado, comprobando el tipo de uso permitido y la fecha de vigencia, y verificar la integridad del certificado, validando la firma digital de la autoridad que lo certifica. Para poder validar la firma digital, requerimos de una clave pública, por lo que las autoridades certificantes tienen a su vez un certificado, formando una cadena hasta que se llega a un Root CA, que son aquellas autoridades que firman su propio certificado, y sus PK vienen por defecto instalados en las computadoras, browsers, runtimes (como JVM), etc.

X.509

Es un estándar de certificados digitales, incluyendo:

  • Versión
  • Número de serie
  • Identificador de algoritmo de firma
  • Nombre del emisor (CA)
  • Intervalo de validez
  • Nombre del sujeto (CN - Common Name)
  • Clave pública del sujeto
  • Firma: Firma del hash de todo lo anterior
1.Certificate:
2.Data:
3.    Version: 3 (0x2)
4.    Serial Number: 1 (0x1)
5.    Signature Algorithm: md5WithRSAEncryption
6.    Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
7.        OU=Certification Services Division,
8.        CN=Thawte Server CA/Email=server-certs@thawte.com
9.    Validity
10.        Not Before: Aug 1 00:00:00 1996 GMT
11.        Not After : Dec 31 23:59:59 2020 GMT
12.    Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
13.        OU=Certification Services Division,
14.        CN=Thawte Server CA/Email=server-certs@thawte.com
15.    Subject Public Key Info:
16.        Public Key Algorithm: rsaEncryption
17.        RSA Public Key: (1024 bit)
18.            Modulus (1024 bit):
19.                00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c:
20.                68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da:
21.                85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06:
22.                6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2:
23.                6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b:
24.                29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90:
25.                6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f:
26.                5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:
27.                3a:c2:b5:66:22:12:d6:87:0d
28.        Exponent: 65537 (0x10001)
29.        X509v3 extensions:
30.            X509v3 Basic Constraints: critical
31.                CA:TRUE
32.    Signature Algorithm: md5WithRSAEncryption
33.        07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9:
34.        a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48:
35.        3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88:
36.        4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9:
37.        8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5:
38.        e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9:
39.        b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:
40.        70:47

Proceso de Verificación

  1. Obtener la clave pública del emisor
    • En la cadena de certificados o del sistema si es raíz.
    • Si es necesario, verificar recursivamente el certificado del emisor
  2. Verificar integridad del certificado, utilizando el algoritmo especificado y la clave pública del emisor
  3. Verificar intervalo de validez
    • Debe estar vigente
    • La autoridad certificante debe estar vigente al comienzo del periodo de vigencia
  4. Verificar identidad del certificado: Comparar el CN con el que espera la aplicación, esto depende del uso del certificado.
  5. Verificar el uso del certificado: Validar que el certificado esté autorizado para el uso que se le quiere dar.

Revocación de Claves

Hay casos donde es necesario invalidar una clave antes de su expiración, como cuando la clave fue averiguada por un atacante, o en casos de un cambio anticipado, como el cambio del dueño de una clave. Esto presenta problemas, pues no se debe poder revocar claves que no deben ser revocadas, para evitar que se revoquen claves sin autorización, y también se debe propagar la información para evitar futuras comunicaciones con dicha clave.

Listas de Revocación

Son listas de certificados recovados, similar a las listas de números de tarjeta de crédito robadas. Contienen un listado actual, que contiene certificados vigentes y revocados, y un listado histórico, con los certificados expirados y revocados. En el caso de X.509, solo el emisor de un certificado puede revocarlo, agregándolo al CRL (Certificate Revocation List) de la autoridad certificante global. La lista se puede obtener para validar offline o puede ser validada online.

Online Certificate Status Protocol

Permite certificar que una firma esta activa, mediante un servicio online con API estandarizada administrados por las CAs. El resultado esta firmado digitalmente, y es un certificado de corta duración (1 hora a 7 días). Este tipo de certificado puede estar incluido en la cadena de certificados, conocido como OCSP Stappling, evitando que el cliente tenga que consultar una fuente externa. Es recomendado para sitios de alto trafico.