Public Key Infrastructure

1,492
-1

Published on

Public Key Infrastructure

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,492
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Public Key Infrastructure

    1. 1. 1st Peruvian Workshop on IT Security 29.Dic.2003 PKI aplicada http://escert.upc.es Instituto de Investigación UNI-FIIS http://www.uni.edu.pe Colaboración Roger Carhuatocto Miembro esCERT-UPC Responsable de Servicios Educacionales esCERT-UPC C/ Jordi Girona, 1-3. Campus Nord, UPC 08034 Barcelona ~ España Tel. (34)934015795 ~ Fax. (34)934017055
    2. 2. Servicio de seguridad <ul><li>Confidencialidad, sólo autorizados acceden a la información </li></ul><ul><li>Integridad, asegurar la no alteración </li></ul><ul><li>Autenticación, corroborar la identidad </li></ul><ul><li>Autenticación de mensajes, conocer el origen del mensaje </li></ul><ul><li>Firma, ligar identidad con información </li></ul><ul><li>Autorización, permiso de acceso a recursos </li></ul><ul><li>Validación, evento (limitada en tiempo y espacio) de autorización </li></ul><ul><li>Control de acceso, ingreso privilegiado </li></ul><ul><li>Certificación, aval de entidad de confianza </li></ul><ul><li>Testificación, aval extra de una entidad ajena a la primaria ) </li></ul><ul><li>Sello de Tiempo (TIME STAMPING), registro de tiempo de un evento </li></ul><ul><li>Recibo, constancia de entrega para el emisor </li></ul><ul><li>Título de propiedad (OWNERSHIP), transferencia legal de un derecho de uso </li></ul><ul><li>Anonimicidad, la no relación de una identidad con una entidad </li></ul><ul><li>No repudio, prevenir negación de actos realizados </li></ul><ul><li>Revocación, cese de certificación </li></ul>
    3. 3. <ul><li>Las amenazas se reducen implantando Servicios de Seguridad </li></ul><ul><li>Los servicios de seguridad están basados sistemáticamente en el uso de técnicas criptográficas . </li></ul>Servicios de Seguridad
    4. 4. <ul><li>Usuarios necesitan claves públicas de otros usuarios. ¿Cómo se accede a claves públicas de otros usuarios?. </li></ul><ul><li>Se debería disponer de una base de datos de clave públicas asociadas a identidades de los usuarios que las poseen. </li></ul><ul><li>Los usuarios accederían a la BDs y obtendrían las claves necesarias. </li></ul>Infraestructura. ¿Por qué?.
    5. 5. <ul><li>Amenaza: </li></ul><ul><ul><li>Si se trata de una BD de acceso público, podría ser fácil cambiar sus contenidos, por ejemplo, cambiar la identidad asociada a una clave pública o viceversa. </li></ul></ul><ul><li>Solución: </li></ul><ul><ul><li>Asegurar los depósitos de claves (seguridad no absoluta) </li></ul></ul><ul><ul><li>Asegurar las asociaciones claves públicas-identidades (Certificados digitales). </li></ul></ul><ul><li>La BDs resultante “garantiza” (acto de fe/confianza) que una determinada clave pública pertenece a un determinado usuario. </li></ul>Infraestructura. Conclusión
    6. 6. Certificado y CA Almacén seguro Autoridad de Certificación (CA) <ul><li>CERTIFICADO </li></ul><ul><li>La clave pública. </li></ul><ul><li>La identidad del poseedor. </li></ul><ul><li>La identidad de la CA. </li></ul><ul><li>Una fecha de validez para esta asociación. </li></ul><ul><li>Firma digital (para protegerlo de manipulaciones malintencionadas) </li></ul><ul><li>Da garantía: Firma digitalmente la relación clave pública e identidad del poseedor de la clave. </li></ul><ul><li>Dicha relación se añade a la estructura del CERTIFICADO </li></ul><ul><li>Gestiona la estructura de información (CERTIFICADO) </li></ul>NO HAY INFORMACIÓN CONFIDENCIAL.
    7. 7. Certificado y CA Almacén seguro Autoridad de Certificación (CA) <ul><li>Da garantía: Firma digitalmente la relación/asociación clave pública e identidad del poseedor de la clave. </li></ul><ul><li>Dicha relación se añade a la estructura del CERTIFICADO </li></ul><ul><li>Gestiona la estructura de información (CERTIFICADO) </li></ul>NO HAY INFORMACIÓN CONFIDENCIAL. <ul><li>CERTIFICADO </li></ul><ul><li>La clave pública. </li></ul><ul><li>La identidad del poseedor. </li></ul><ul><li>La identidad de la CA. </li></ul><ul><li>Una fecha de validez para esta asociación. </li></ul><ul><li>Identificación de la asociación </li></ul><ul><li>Firma digital (para protegerlo de manipulaciones malintencionadas) </li></ul><ul><li>Versión del formato </li></ul><ul><li>Algoritmos usados en firma y hash </li></ul><ul><li>……… </li></ul>
    8. 8. <ul><li>Alice descarga el certificado de Bob del almacén seguro </li></ul><ul><li>Alice firma el mensaje con su Kpriv, usará la Kpub de Bob si envía dicho mensaje de forma cifrada </li></ul><ul><li>Bob verifica la firma electrónica del mensaje y luego el certificado del remitente </li></ul>Certificado, Firma y cifrado KAlice privada KAlice pública SI? Almacén seguro Autoridad de Certificación (CA) Firma Digital Verificación de Firma Digital
    9. 9. <ul><li>Validación de mensaje + Validación Certificado </li></ul><ul><ul><li>Verificar la validez del certificado del remitente. </li></ul></ul><ul><ul><ul><li>Existencia del certificado </li></ul></ul></ul><ul><ul><ul><li>Dentro del período de validez. </li></ul></ul></ul><ul><ul><ul><li>Certificado no revocado. </li></ul></ul></ul><ul><ul><ul><li>Firma electrónica de la CA correcta. </li></ul></ul></ul><ul><ul><li>Verificar la firma electrónica del mensaje con la clave pública del remitente </li></ul></ul><ul><li>Es necesario que el destinatario y el remitente pertenezcan al mismo circulo de confianza, es decir que ambas claves pública deben estar en “posesión” de una misma CA </li></ul>Validación de mensajes firmados
    10. 10. <ul><li>Un lugar idóneo para guardar certificados es la base de datos distribuida X.500 (directorio). </li></ul><ul><li>X.500 asocia una entrada de una base de datos distribuida y organizada jerárquicamente según un árbol, a cada agente del sistema. </li></ul><ul><li>Cada usuario puede depositar su certificado en su entrada del directorio y el resto de usuarios puede acceder a dicha entrada y recogerlo. </li></ul>Infraestructura. Ldap
    11. 11. Infraestructura. Ldap X.500 Usuario A Usuario B Almacén seguro Autoridad de Certificación (CA)
    12. 12. <ul><li>X.500: Estructura de directorios jerárquica. </li></ul><ul><li>Cada entrada se etiqueta con un Nombre Distintivo (Distinguished Name -DN-). </li></ul><ul><li>Un DN contiene valores de atributos: </li></ul><ul><ul><li>País </li></ul></ul><ul><ul><li>Organización </li></ul></ul><ul><ul><li>Unidad organizativa </li></ul></ul><ul><ul><li>Nombre de usuario </li></ul></ul><ul><li>CAs y usuarios pueden depositar sus certificados en el directorio X.500 </li></ul>Ldap CA Raíz CA Sub A CN=Roger Carhuatocto CA Sub B CA Sub A.1 C=PE C=ES O=UNI-FIIS OU=ACME
    13. 13. <ul><li>Los certificados tienen una vida limitada. Al finalizar el período de validez, expiran. </li></ul><ul><li>Un certificado puede dejar de ser válido por varios motivos (REVOCADO): </li></ul><ul><ul><li>Si se sospecha que alguien ha tenido acceso a la clave privada, debe revocarse el certificado con la correspondiente clave pública. </li></ul></ul><ul><ul><li>Cuando el poseedor de un certificado cambia de empresa su DN no es válido. </li></ul></ul><ul><li>En tales casos, la CA debe realizar las operaciones necesarias para REVOCAR el certificado. </li></ul><ul><li>Una alternativa es disponer de Listas Firmadas (CRL) por la CA en las que se incluyan los certificados generados y revocados por ella o referencias a éstos. </li></ul><ul><li>Estas listas pueden depositarse en la entrada de la CA en el directorio X.500. </li></ul>Certificados y CRLs
    14. 14. <ul><li>La verificación de un certificado implicará pues, la inspección de estas listas por ver si el certificado en cuestión está o no revocado. </li></ul><ul><li>Proceso: </li></ul><ul><ul><li>Recepción de mensaje firmado. </li></ul></ul><ul><ul><li>Acceso a X.500 para recoger certificado de usuario. </li></ul></ul><ul><ul><li>Comprobación de que no está revocado. </li></ul></ul><ul><li>Si el certificado NO ha sido expedido por una CA conocida, ír hacia arriba en el árbol de X.500 hasta dar con una en la que confiemos. </li></ul>Certificados, CRLs y verificación
    15. 15. <ul><li>En sistemas complejos: jerarquías de CAs. </li></ul><ul><li>Necesidad de verificar secuencias de certificados de CAs hasta llegar al de una CA en la que se confíe. </li></ul><ul><li>Usuarios y CAs intercambiarán mensajes de gestión de certificados (para solicitar certificados, entregarlos, solicitar revocación, confirmarla, etc.). </li></ul><ul><li>Al hablar de infraestructura pues, estamos refiriéndonos a agentes presentes, mensajes intercambiados y “reglas de juego”: </li></ul><ul><ul><li>Servicios, plataformas, algoritmos, normas, protocolos, responsabilidades, estructutras </li></ul></ul>Conclusiones
    16. 16. <ul><li>Definición en ASN.1. Codificación DER. </li></ul>Certificado X.509 Certificate::= SIGNED SEQUENCE { version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueId [1] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueI [2] IMPLICIT UniqueIdentifier OPTIONAL, extensions [3] Extensions OPTIONAL }
    17. 17. <ul><li>Tipo de certificados que debe usarse para generar Firmas Electrónicas Avanzadas (según la Directiva Europea) </li></ul><ul><li>Es un p erfil de certificado definido a partir del formato X.509, en el que se describen una serie de Extensiones que deben aparecer obligatoriamente. </li></ul>Certificado Reconocido (Qualified Cert.)
    18. 18. <ul><li>Definición en ASN.1. Codificación DER. </li></ul>Certificado Reconocido (Qualified Cert.) AuthorityKeyId SubjectKeyId KeyUsage CertPolicies CRLDistributionPoint Certificate::= SIGNED SEQUENCE { version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueId [1] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueI [2] IMPLICIT UniqueIdentifier OPTIONAL, extensions [3] Extensions OPTIONAL }
    19. 19. <ul><li>Necesidad de estándares: asegurar la INTEROPERABILIDAD entre aplicaciones que aplican Criptografía de Clave Pública, desarrolladas por fabricantes diferentes. </li></ul><ul><li>Desarrollados por RSA Security y fabricantes (Microsoft, Sun, Apple, etc) </li></ul><ul><li>Qué se ha estandarizado?: </li></ul><ul><ul><li>la sintaxis de los mensajes </li></ul></ul><ul><ul><li>los algoritmos </li></ul></ul><ul><li>Qué asuntos quedan abiertos, a criterio del desarrollador </li></ul>Public Key Cryptography Standards
    20. 20. Public Key Cryptography Standards Public-Key Cryptography Standards http://www.rsasecurity.com/rsalabs/pkcs/index.html
    21. 21. <ul><li>Autenticación del Origen </li></ul><ul><li>Integridad del Contenido </li></ul><ul><li>Confidencialidad del Contenido </li></ul><ul><li>No Repudio del Origen </li></ul><ul><li>PEM (Privacy enhancen mail) fue la primera propuesta realizada en Internet para asegurar mensajes de correo electrónico haciendo uso de firmas digitales y certificados X.509. No tuvo éxito porque no era compatible con MIME. Sólo permite firma y cifrado de parte del mail </li></ul><ul><li>S/MIME (Multipurpose Internet Mail Extensions), igual que anterior, soporte MIME </li></ul><ul><li>PGP  </li></ul>Aplicaciones. email
    22. 22. <ul><li>Firma de formularios, Firma de páginas web, Firma de código </li></ul><ul><li>Autenticación </li></ul><ul><li>SSL </li></ul><ul><ul><li>Desarrollado por Netscape Communications Corp. </li></ul></ul><ul><ul><li>Permite proteger cualquier comunicación de cualquier aplicación que opere sobre TCP (http, FTP, Telne, cualquier tunel SSL) </li></ul></ul><ul><ul><li>Ofrece servicios de Seguridad para Sesiones entre cliente/servidor </li></ul></ul><ul><ul><ul><li>Autenticación del Servidor </li></ul></ul></ul><ul><ul><ul><li>Autenticación del Cliente </li></ul></ul></ul><ul><ul><ul><li>Integridad del Contenido transferido </li></ul></ul></ul><ul><ul><ul><li>Confidencialidad </li></ul></ul></ul>Aplicaciones. Web seguro
    23. 23. <ul><li>Pasarelas/medios de pago </li></ul><ul><li>e-commerce, e-business, m-commerce </li></ul><ul><li>e-gambling, e-voting (avanzada) </li></ul><ul><li>Firma y cifrado con XML, web services </li></ul><ul><li>Autenticación: SSO, Kerberos </li></ul><ul><li>Tokens: SmartCards de memoria y criptográfica, JavaCards </li></ul>Aplicaciones. Transacciones seguras
    24. 24. PKI: Ejemplos <ul><li>Autoridades de Certificación </li></ul><ul><ul><li>OpenCA – http://www.openca.org Linux, GPL, basado en OpenSSL, Apache, Perl, MySQL y Ldap </li></ul></ul><ul><ul><li>NewPKI – http://www.newpki.org Windows, GPL, C/C++, desarrollo propietario, MySQL y Ldap </li></ul></ul><ul><ul><li>EJBCA – http://ejbca.sourceforge.net Multiplataforma(Java), basada en API Criptográfico de Java, J2EE/Jboss, MySQL y Ldap </li></ul></ul><ul><li>BDs y Ldap </li></ul><ul><ul><li>MySQL – http://www.mysql.org </li></ul></ul><ul><ul><li>Postgres – http://www.postgres.org </li></ul></ul><ul><ul><li>OpenLdap – http://www.openldap.org </li></ul></ul><ul><li>Servidores web, application server </li></ul><ul><ul><li>Apache – http://www.apache.org </li></ul></ul><ul><ul><li>JBoss – http://www.jboss.org </li></ul></ul>
    25. 25. June 2003 Survey on PKI Obstacles <ul><li>Objetivo </li></ul><ul><ul><li>Identificar principales obstáculos para el despliegue y uso de PKI </li></ul></ul><ul><li>Cómo </li></ul><ul><ul><li>Web-based survey deployed June 9 to 22, 2003 (OASIS) </li></ul></ul><ul><ul><li>Invitation distributed through PKI standards bodies, trade groups, user associations, etc. </li></ul></ul><ul><li>Encuestados </li></ul><ul><ul><li>216 valid responses, many with careful text comments </li></ul></ul><ul><ul><li>44% IT management and staff, remainder developers, consultants, etc. </li></ul></ul><ul><ul><li>Primary Work Location: 61% North America, 24% Europe, 6% Asia </li></ul></ul><ul><ul><li>Over 75% with 5 or more years experience in InfoSec/Privacy </li></ul></ul><ul><ul><li>90% either helped deploy PKI or developed PKI-related software </li></ul></ul>Ver encuesta http://www.ietf.org/proceedings/03nov/slides/pkix-2/pkix-2.ppt

    ×