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.

http://es.wikipedia.org/wiki/Prestador_de_Servicios_de_Certificaci%C3%B3n





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.

http://es.wikipedia.org/w/index.php?title=Certificado_p%C3%BAblico&action=edit&redlink=1

http://es.wikipedia.org/w/index.php?title=Certificado_p%C3%BAblico&action=edit&redlink=1


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.

http://es.wikipedia.org/wiki/Servidor_web

http://es.wikipedia.org/wiki/Servidor_web

http://es.wikipedia.org/wiki/Aplicaci%C3%B3n

http://es.wikipedia.org/wiki/Aplicaci%C3%B3n

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/w/index.php?title=Pol%C3%ADtica_de_Certificaci%C3%B3n&action=edit&redlink=1

http://es.wikipedia.org/w/index.php?title=Pol%C3%ADtica_de_Certificaci%C3%B3n&action=edit&redlink=1


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/

http://www.mityc.es/DGDSI/Servicios/FirmaElectronica/Prestadores/

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:

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

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

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 protected]

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.

Uso de certificados

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/

http://www.doegrids.org/CA/

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.esDescarga de lista de revocación.

http://ca.banesto.es

http://ca.banesto.es

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).


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());

}

Clases abstractas: conjunto de métodos muy limitado.


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.


InputStream inStream = new FileInputStream(”fileName");

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

X509Certificate cert =

(X509Certificate)cf.generateCertificate(inStream);

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

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:

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.

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

CertificateFactory cf= CertificateFactory.getInstance("X.509"); X509CRL crl = (X509CRL) cf.generateCRL(ficheroCRL);

4. certificados digitales

Documents

Transcript of 4. certificados digitales