4. certificados digitales

7,577 views
7,238 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,577
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
199
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

4. certificados digitales

  1. 1. Criptografía en aplicaciones Java Certificados digitales
  2. 2. 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?
  3. 3. ¿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, ...
  4. 4. ¿Qué es un certificado? 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})
  5. 5. ¿Qué es un certificado? 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, …
  6. 6. 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.
  7. 7. Autoridades certificadoras 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.
  8. 8. Autoridades certificadoras 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.
  9. 9. Autoridades certificadoras 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.
  10. 10. Autoridades certificadoras 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.
  11. 11. Autoridades certificadoras 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.
  12. 12. Autoridades certificadoras 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.
  13. 13. Autoridades certificadoras Normativa: url: http://www.mityc.es/DGDSI/Servicios/FirmaElectronica/Prestadores/
  14. 14. Autoridades certificadoras 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, …
  15. 15. Autoridades certificadoras Datos de FNMT:
  16. 16. Autoridades certificadoras
  17. 17. 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.
  18. 18. 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.
  19. 19. 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.
  20. 20. 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.
  21. 21. X.509
  22. 22. 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.
  23. 23. X.509 v3. Extensiones 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).
  24. 24. X.509 v3. Extensiones 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.
  25. 25. X.509 v3. ExtensionesSubject Key Identifier: proporciona una forma deidentificar certificados que contienen una determinadaclave pública. Esta extensión debe ser marcada comoNON-CRITICAL.Key Usage: define el propósito (cifrado,autenticación, firma de certificados,…) de la clavecontenida en el certificado. Se debe usar cuando sequiere restringir el uso de una clave que podría serusada para más de una operación. Esta extensióndebe ser marcada como CRITICAL.Private Key Usage Period: se recomienda no usaresta extensión. Las CAs no deberían generarcertificados con esta extensión, salvo bajocircunstancias muy concretas..
  26. 26. X.509 v3. ExtensionesCertificate Policies: contiene una secuencia de unoo más términos de información de políticas deseguridad. Indican la política de seguridad bajo la quese ha emitido el certificado y los propósitos para losque se debe usar.Policy Mappings: Se usa en certificados de una CA.Subject Alternative Name: permite asociaridentidades adicionales al sujeto del certificado. Lasopciones definidas incluyen una dirección email, unnombre DNS, una dirección IP y un identificadoruniforme de recurso (URI), aunque existen másopciones. También se pueden incluir múltiplesnombres y múltiples instancias de cada nombre.Siempre que se quieran enlazar esas identidades a uncertificado se DEBE usar esta extensión.
  27. 27. X.509 v3. ExtensionesIssuer Alternative Names: de forma semejante a laextensión anterior (Subject Alternative Names), seusa para asociar otras identidades al emisor delcertificado. La codificación de esta extensión esidéntica a la anterior.Subject Directory Attributes: no estáespecialmente recomendada. Se puede usar enentornos locales. Esta extensión debe ser NON-CRITICAL.Basic Constraints: sirve para identificar si el sujetodel certificado es una CA y la profundidad de la rutade certificación. Debe aparecer como CRITICAL entodos los certificados CA. NO DEBE aparecer encertificados finales de una entidad.
  28. 28. X.509 v3. ExtensionesName Constraints: sólo se debe usar en uncertificado de CA. Indica un espacio de nombres en elque todos los nombres de sujeto de los certificadosdeberían estar localizados.Policy Constraints: se puede usar en certificadosemitidos a CA. Esta extensión obliga a la validación dela ruta de dos formas. Se puede usar para prohibir elmapeado de políticas o para exigir que cadacertificado en una ruta contenga una identificador depolítica aceptable.Otras extensiones (Extended key usage, CRLDistribution Points, Authority Information Access,…)
  29. 29. Ejemplo de certificado X.509Certificate: 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 … …
  30. 30. 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.
  31. 31. Uso de certificados
  32. 32. 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…
  33. 33. Lista de anulación de certificados - CRLs 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.
  34. 34. Lista de anulación de certificados - CRLs 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.
  35. 35. Lista de anulación de certificados - CRLs 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).
  36. 36. Lista de anulación de certificados - CRLs 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.
  37. 37. Lista de anulación de certificados - CRLs Descargar ficheros CRL: Ejemplo: http://www.doegrids.org/CA/
  38. 38. Lista de anulación de certificados - CRLs Se selecciona la opción CRL: Se obtiene el fichero doegrids.crl
  39. 39. Lista de anulación de certificados - CRLs Ejemplo: Autoridad certificadora de Banesto. PSC Banesto. http://ca.banesto.es Descarga de lista de revocación.
  40. 40. 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.
  41. 41. Obtención de un certificado 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.
  42. 42. Obtención de un certificado 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.
  43. 43. 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.
  44. 44. 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.
  45. 45. 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
  46. 46. 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).
  47. 47. Gestión de certificados 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());}
  48. 48. Gestión de certificadosX509Certificate: 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.
  49. 49. Gestión de certificados 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);
  50. 50. 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
  51. 51. 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.
  52. 52. 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.

×