4. certificados digitales

Criptografía en aplicaciones Java

Certificados digitales

Certificados digitales

 ¿Qué es un certificado?
 Autoridades certificadoras.
 X.509.
Ejemplo de certificado X.509.
 Uso de certificados.
 Listas de anulación de certificados (CRLs).
 Obtención de un certificado.
 ¿Qué API de Java se usa para acceder y
gestionar certificados?

¿Qué es un certificado?

 El certificado digital es un vínculo entre una
clave pública y una identidad de usuario, que se
consigue mediante una firma digital por una
tercera parte o autoridad de certificación que
hace pública su clave pública en la que TODOS
confían.
 Por tanto, el certificado se considera como un
objeto firmado con la clave privada de la
autoridad de certificación, e incluyendo:
identidad del usuario, clave, periodo de validez,
identidad emisor, ...


 Un archivo, firmado con la clave privada de CA
(autoridad de certificación) que incluye,
la identidad,
la clave pública del dicha identidad,
atributos varios y
compendio de dicha información

DCA(identidad, clave, atributos, compendio{identidad,
clave, atributos})


 Conceptos:
Clave Pública: clave asociada a una entidad particular,
que debe ser conocida y usada por todo aquel que
necesite interactuar con garantías con esa entidad.
Firmado digitalmente: almacenado con la identidad de
una entidad (sujeto) usando la clave privada de la
entidad para garantizar la autenticidad.
Identidad: cualquier forma de identificar a una
entidad.
Clave privada: secuencia de caracteres, que debe ser
conocida únicamente por la entidad a la que pertenece
y que se utiliza para firmar los datos.
Entidad: una persona, organización, programa,
ordenador, negocio, banco, …

Autoridades certificadoras

 Una Autoridad Certificadora (CA) es una entidad
“fiable” que acepta solicitudes de certificados de
otras entidades, las valida, genera dichos
certificados y mantiene su información.
 Sólo podrán crear certificados válidos sujetos a
ciertas normas y acuerdos legales.
 Deben publicar una Certification Practice
Statement (CPS), donde se recojan sus políticas
y prácticas relativas a la seguridad y
mantenimiento de los certificados, sus
responsabilidades y obligaciones de los
suscriptores.


 La Autoridad de Certificación es un tipo
particular de Prestador de Servicios de
Certificación que legitima ante terceros que
confían en sus certificados la relación entre la
identidad de un usuario y su clave pública.


 Jerarquía de certificación:
Las CA disponen de sus propios certificados públicos,
cuyas claves privadas asociadas son empleadas por
las CA para firmar los certificados que emiten.
Un certificado de CA puede estar auto-firmado cuando
no hay ninguna CA de rango superior que lo firme.
Éste es el caso de los certificados de CA raíz, el
elemento inicial de cualquier jerarquía de certificación.


 Jerarquía de certificación:
Una jerarquía de certificación consiste en una
estructura jerárquica de autoridades certificadoras.
Se parte de una autoridad certificadora auto-firmada,
y en cada nivel, existe una o más autoridades
certificadoras que pueden firmar:
 Certificados de entidad final (titular de certificado:
servidor web, persona, aplicación de software)
 Certificados de otras CA subordinadas plenamente
identificadas y cuya Política de Certificación sea
compatible con las CAs de rango superior.


 Funciones de una autoridad:
Admisión de solicitudes de certificados.
Autenticación de los sujetos.
Generación de certificados.
Distribución de certificados.
Anulación de certificados.
Almacenes de datos.


 Normativa:
La Directiva 93/1999 ha establecido un marco común
aplicable a todos los paises de la Unión europea.
La Ley 59/2003 de Firma Electrónica es la normativa
española:
 Esta ley se crea para reforzar el marco jurídico existente
incorporando a su texto algunas novedades respecto al
Real Decreto Ley 14/1999 que contribuye a dinamizar el
mercado de la prestación de servicios de certificación.


 Normativa:
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.


 Normativa:
url: http://www.mityc.es/DGDSI/Servicios/FirmaElectronica/Prestadores/


 Ejemplos de entidades certificadoras:
En España: FNMT (Fábrica Nacional de Moneda y
Timbre), ACE (Agencia de Certificación Electrónica),
FESTE (Fundación para el Estudio de la Seguridad de
las Telecomunicaciones), VeriSign España, …
En el extranjero: VeriSign, Thawte, Entrust, …


 Datos de FNMT:

X.509

 Es un estándar ITU-T, que supone la pieza
central de la infraestructura PKI . Especifica,
entre otras cosas, un formato estándar para
certificados de claves pública.
 Tiene 3 versiones:
Versión 1: apareció en 1988 y es la más extendida.
Versión 2: apareció en 1993, introduciendo los
conceptos de identificador único para el Sujeto
(Subject) y la CA emisora (Issuer).
Versión 3: apareció en 1996 y añade el concepto de
extensiones.

X.509

 Formato de un certificado X.509:
Versión: contiene el número de la versión de X.509
del certificado. Los valores aceptables son 1, 2 y 3.
Número de serie del certificado: todo certificado
emitido por una CA debe tener un número de serie
único. Entre otras cosas, se utiliza cuando se quiere
revocar un certificado, ya que se identifica mediante
su número de serie.
Identificador del algoritmo de firmado.
Nombre del emisor: Nombre X.500 de la entidad
que firma el certificado.

X.509

Periodo de validez: un certificado sólo es válido
durante un plazo de tiempo identificado por la fecha
de inicio y la de final. El periodo se elige en función
del coste y del tiempo que puede tardar la clave
privada en estar comprometida.
Nombre del sujeto (Subject): es un nombre ÚNICO
según X.500. Corresponde al Distinguished Name de
la entidad. Por ejemplo:

CN=Duke, OU=Java Software Division, O=Sun MicroSystems Inc, C=US

Información de clave pública: contiene la propia
clave pública, sus parámetros y el identificador del
algoritmo de encriptación.

X.509

 A partir de la versión 2:
Identificador único del emisor: campo opcional
que se incluyó para posibilitar la reutilización de los
nombres de emisor (CA).
Identificador único del sujeto: campo opcional que
se incluyó para posibilitar la reutilización de los
nombres de sujeto.
 En la versión 3:
Extensiones.

X.509 v3. Extensiones

 Las extensiones de la versión 3 proporcionan
una manera de asociar atributos adicionales con
usuarios o claves públicas y de gestionar la
jerarquía certificadora.
 El campo extensiones en X.509 es una
secuencia de una o más extensiones de
certificados.
 Cada extensión de certificado se puede designar
como crítica (critical) o no crítica (non-critical).
Un sistema que use certificados DEBE rechazar
el certificado si encuentra una extensión crítica
que no reconoce. Sin embargo, una extensión
no crítica podrá ser ignorada si no se reconoce.


 Vamos a ver las extensiones recomendadas
usadas en certificados de internet. Se pueden
usar extensiones adicionales. Sin embargo, se
deben tomar precauciones a la hora de adoptar
una extensión crítica en un certificado.
 Cada extensión tiene 3 campos:
extnId: Tipo de la extensión.
extnValue: Valor.
critical: booleano indicando si la extensión es crítica
(el valor por defecto es false, no crítica).


 Sólo puede aparecer una instancia de una
extensión concreta en un certificado.
 Extensiones estándar:
Authority Key Identifier: proporciona una manera
de identificar la clave pública correspondiente a la
clave privada usada para firmar un certificado. Se usa
en aquellos emisores que tienen múltiples claves de
firmado. La identificación se puede basar tanto en el
identificador de clave (el identificador del sujeto en el
certificado del emisor) o en el nombre y número de
serie del emisor. Esta extensión debe marcarse como
NON-CRITICAL.


Subject Key Identifier: proporciona una forma de
identificar certificados que contienen una determinada
clave pública. Esta extensión debe ser marcada como
NON-CRITICAL.
Key Usage: define el propósito (cifrado,
autenticación, firma de certificados,…) de la clave
contenida en el certificado. Se debe usar cuando se
quiere restringir el uso de una clave que podría ser
usada para más de una operación. Esta extensión
debe ser marcada como CRITICAL.
Private Key Usage Period: se recomienda no usar
esta extensión. Las CAs no deberían generar
certificados con esta extensión, salvo bajo
circunstancias muy concretas..


Certificate Policies: contiene una secuencia de uno
o más términos de información de políticas de
seguridad. Indican la política de seguridad bajo la que
se ha emitido el certificado y los propósitos para los
que se debe usar.
Policy Mappings: Se usa en certificados de una CA.
Subject Alternative Name: permite asociar
identidades adicionales al sujeto del certificado. Las
opciones definidas incluyen una dirección email, un
nombre DNS, una dirección IP y un identificador
uniforme de recurso (URI), aunque existen más
opciones. También se pueden incluir múltiples
nombres y múltiples instancias de cada nombre.
Siempre que se quieran enlazar esas identidades a un
certificado se DEBE usar esta extensión.


Issuer Alternative Names: de forma semejante a la
extensión anterior (Subject Alternative Names), se
usa para asociar otras identidades al emisor del
certificado. La codificación de esta extensión es
idéntica a la anterior.
Subject Directory Attributes: no está
especialmente recomendada. Se puede usar en
entornos locales. Esta extensión debe ser NON-
CRITICAL.
Basic Constraints: sirve para identificar si el sujeto
del certificado es una CA y la profundidad de la ruta
de certificación. Debe aparecer como CRITICAL en
todos los certificados CA. NO DEBE aparecer en
certificados finales de una entidad.


Name Constraints: sólo se debe usar en un
certificado de CA. Indica un espacio de nombres en el
que todos los nombres de sujeto de los certificados
deberían estar localizados.
Policy Constraints: se puede usar en certificados
emitidos a CA. Esta extensión obliga a la validación de
la ruta de dos formas. Se puede usar para prohibir el
mapeado de políticas o para exigir que cada
certificado en una ruta contenga una identificador de
política aceptable.
Otras extensiones (Extended key usage, CRL
Distribution Points, Authority Information Access,…)

Ejemplo de certificado X.509

Certificate:
Data:
Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/Email=server-certs@thawte.com
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
…
…

Uso de certificados

 Navegadores Web: aplicación más visible.
 Esquemas de firma de código, como ficheros
Java firmados y Microsoft Authenticode.
 Diferentes estándares de correo electrónico
seguro, como PEM o S/MIME.
 Protocolos de comercio electrónico, como SET.

Lista de anulación de certificados - CRLs

 A veces, la utilidad, seguridad, y confianza de
un certificado termina antes del periodo fijado
en su creación y debe ser anulado.
 Posibles razones de anulación:
La clave privada del sujeto (Subject) se ha visto
comprometida.
La clave privada de la CA se ha visto comprometida.
Se ha producido un cambio en la afiliación del sujeto
(muerte, despido, cambio de empresa, …)
Otras…


 Las Certification Revocation Lists (CRLs) son el
mecanismo que tienen las CA para publicar y
distribuir la información sobre aquellos
certificados anulados antes del fin de su periodo
de validez.
 Posibles estados de un certificado en una CRL:
revoked: anulado de forma irreversible.
hold: anulado temporalmente.


 Las CRLs están firmadas por una CA y consisten
en una secuencia de los siguientes campos:
tbsCertList: (To Be Signed) secuencia que incluye
varios campos, tales como el emisor, la fecha de
emisión y los certificados revocados de ese emisor.
signatureAlgorithm: Identificador del algoritmo de
firma usado por el emisor de CRL para firmar la
misma.
signatureValue: Firma digital.


 El campo tbsCertList, a su vez:
version: existen dos versiones de CRLs, por lo que los
valores válidos son 1 y 2 (si incluye extensiones de CRL).
signature: identificador del algoritmo usado para firmar la
CRL. DEBE coincidir con el identificador usado por el emisor
que se ha visto antes (campo signatureAlgorithm).
issuer: nombre del emisor de la CRL en formato X.500.
thisUpdate: fecha de emisión de la CRL.
nextUpdate: fecha en la que se emitirá la próxima CRL.
Podrá ser emitida antes de esa fecha, pero nunca más tarde.
revokedCertificates: secuencia de certificados anulados.
crlExtensions: extensiones (sólo en la versión 2).


 En cada entrada de la secuencia de certificados anulados
se almacena:
userCertificate: número de serie del certificado anulado.
revocationDate: fecha de anulación.
crlEntryExtensions: extensiones a la entrada de la CRL.
 Existe una versión 2 para CRLs que incluye extensiones,
en las que se puede codificar la causa de la anulación,
por ejemplo.


 Descargar ficheros CRL:
Ejemplo: http://www.doegrids.org/CA/


 Se selecciona la opción CRL:

 Se obtiene el fichero doegrids.crl


 Ejemplo:
Autoridad certificadora de Banesto.
PSC Banesto.
http://ca.banesto.es
Descarga de lista de revocación.

Obtención de un certificado

 Formas de conseguir un certificado:
Usar herramientas para crear un certificado
autofirmado (keytool, por ejemplo).
Pedir a una CA que nos emita uno. La petición se
puede hacer directamente (vía web, email,…) o a
través de herramientas adecuadas (keytool, por
ejemplo).
 La clave privada no se proporciona NUNCA, ni
siquiera a la CA. Usaremos una herramienta
para firmar digitalmente la información usando
la clave privada y el resultado se envía a la CA.


 Para la generación de un certificado será
necesario:
Una pareja clave pública/privada. Se usará una
herramienta para su generación. La clave privada
nunca debe ser mostrada a nadie.
Información sobre la entidad que va a ser certificada.
La CA normalmente exigirá pruebas que garanticen la
autenticidad de dicha información.
 La utilidad de un certificado autofirmado es
bastante limitada.


 Las CAs sirven como garantías para los
certificados, en parte debido a sus exigencias a
la hora de generar uno.
 Dichas exigencias, responsabilidades de la CA y
obligaciones de los suscriptores están
perfectamente detalladas en sus Certification
Service Practices (CSP), que deben estar
accesibles al público.

APIs de Java para acceder y gestionar
certificados
 Las clases e interfaces para trabajar con
certificados en Java se encuentran en el
paquete java.security.cert. Algunas de las
más importantes son:
CertificateFactory: clase que se usa para generar
certificados y CRLs.
Certificate: clase abstracta que se utiliza para
gestionar certificados.
CRL: clase abstracta para gestionar listas de anulación
de certificados.
X509Certificate: clase abstracta para gestión de
certificados X.509.

APIs de Java para acceder y gestionar
certificados
CertificateFactory: clase que se usa para generar
certificados y CRLs.
X509Extension: interfaz para las extensiones de X.
509 (certificados de la versión 3 y CRLs de la version
2).
X509CRL: clase abstracta para las CRLs.
X509CLREntry: clase abstracta para gestionar las
entradas de una CRL.

 Consultar las API de Java para la profundización
en el conocimiento del paquete
java.security.cert.

Gestión de certificados

 Se puede trabajar con certificados a través de
código.
 Asociando al fichero que almacena dicho
certificado a una referencia dentro del código.
 Una vez asociados, se puede extraer toda la
información disponible utilizando los métodos
que proporcione la clase que se esté utilizando.
 Extensión de certificados: *.cer

CertificateFactory

 Esta clase define la funcionalidad asociada a
una factoría de certificados. Se puede utilizar
para generar:
Certificados.
Listas de revocación.
Rutas de certificados.
 Métodos importantes:
getInstance(“tipoElemento”).
generateCertificate(inStream).
generateCertificates(inStream).
generateCertPath(inStream).
generateCRL(inStream).
generateCRLs(inStream).


 Clases abstractas: conjunto de métodos muy
limitado.

FileInputStream fis = new FileInputStream(filename);
BufferedInputStream bis = new BufferedInputStream(fis);

CertificateFactory cf = CertificateFactory.getInstance("X.509");

while (bis.available() > 0) {
Certificate cert = cf.generateCertificate(bis);
System.out.println(cert.toString());
}


X509Certificate:
Esta clase representa a un certificado X.509.
El conjunto de métodos disponible es mucho más
amplio:
getSubjectX500Principal.
getVersion.
getSerialNumber.
checkValidity.
getKeyUsage.
...
Además de los de Certificate:
getPublicKey.


 Clases específicas: conjunto de métodos mucho
más extenso.

InputStream inStream = new FileInputStream(”fileName");

CertificateFactory cf = CertificateFactory.getInstance("X.509");

X509Certificate cert =
(X509Certificate)cf.generateCertificate(inStream);

Gestión de CRLs

 De la misma forma que, desde código se puede
asociar un certificado a una referencia Java,
también se puede hacer lo mismo con una lista
de revocación.
 Extensión de fichero: *.crl
 La clase CRL se encarga de modelar el concepto
de lista de revocación:
isRevoked.
getType.
toString

Gestión de CRLs

 Clase X509CRL:
Al igual que la clase específica para certificados X.509,
ésta ofrece métodos específicos para las listas de
revocación:
 getNextUpdate.
 getRevokedCertificate.
 getRevokedCertificates.
Métodos de la clase abstracta:
 isRevoked.
 getType.

Gestión de CRLs

 Ejemplo:
InputStream ficheroCRL =
new FileInputStream("PSCBanestoClientes.crl");

CertificateFactory cf= CertificateFactory.getInstance("X.509");

X509CRL crl = (X509CRL) cf.generateCRL(ficheroCRL);

 Una vez que se tiene la referencia, mediante los
métodos que define la clase se pueden extraer
toda la información que se necesite.

4. certificados digitales

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (15)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie 4. certificados digitales

Ähnlich wie 4. certificados digitales (20)

Mehr von 1 2d

Mehr von 1 2d (20)

4. certificados digitales