• Save
Public Key Infrastructure
Upcoming SlideShare
Loading in...5
×
 

Public Key Infrastructure

on

  • 1,890 views

Public Key Infrastructure

Public Key Infrastructure

Statistics

Views

Total Views
1,890
Views on SlideShare
1,880
Embed Views
10

Actions

Likes
0
Downloads
0
Comments
0

2 Embeds 10

http://www.slideshare.net 9
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Public Key Infrastructure Public Key Infrastructure Presentation Transcript

  • 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
  • Servicio de seguridad
    • Confidencialidad, sólo autorizados acceden a la información
    • Integridad, asegurar la no alteración
    • Autenticación, corroborar la identidad
    • Autenticación de mensajes, conocer el origen del mensaje
    • Firma, ligar identidad con información
    • Autorización, permiso de acceso a recursos
    • Validación, evento (limitada en tiempo y espacio) de autorización
    • Control de acceso, ingreso privilegiado
    • Certificación, aval de entidad de confianza
    • Testificación, aval extra de una entidad ajena a la primaria )
    • Sello de Tiempo (TIME STAMPING), registro de tiempo de un evento
    • Recibo, constancia de entrega para el emisor
    • Título de propiedad (OWNERSHIP), transferencia legal de un derecho de uso
    • Anonimicidad, la no relación de una identidad con una entidad
    • No repudio, prevenir negación de actos realizados
    • Revocación, cese de certificación
    • Las amenazas se reducen implantando Servicios de Seguridad
    • Los servicios de seguridad están basados sistemáticamente en el uso de técnicas criptográficas .
    Servicios de Seguridad
    • Usuarios necesitan claves públicas de otros usuarios. ¿Cómo se accede a claves públicas de otros usuarios?.
    • Se debería disponer de una base de datos de clave públicas asociadas a identidades de los usuarios que las poseen.
    • Los usuarios accederían a la BDs y obtendrían las claves necesarias.
    Infraestructura. ¿Por qué?.
    • Amenaza:
      • 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.
    • Solución:
      • Asegurar los depósitos de claves (seguridad no absoluta)
      • Asegurar las asociaciones claves públicas-identidades (Certificados digitales).
    • La BDs resultante “garantiza” (acto de fe/confianza) que una determinada clave pública pertenece a un determinado usuario.
    Infraestructura. Conclusión
  • Certificado y CA Almacén seguro Autoridad de Certificación (CA)
    • CERTIFICADO
    • La clave pública.
    • La identidad del poseedor.
    • La identidad de la CA.
    • Una fecha de validez para esta asociación.
    • Firma digital (para protegerlo de manipulaciones malintencionadas)
    • Da garantía: Firma digitalmente la relación clave pública e identidad del poseedor de la clave.
    • Dicha relación se añade a la estructura del CERTIFICADO
    • Gestiona la estructura de información (CERTIFICADO)
    NO HAY INFORMACIÓN CONFIDENCIAL.
  • Certificado y CA Almacén seguro Autoridad de Certificación (CA)
    • Da garantía: Firma digitalmente la relación/asociación clave pública e identidad del poseedor de la clave.
    • Dicha relación se añade a la estructura del CERTIFICADO
    • Gestiona la estructura de información (CERTIFICADO)
    NO HAY INFORMACIÓN CONFIDENCIAL.
    • CERTIFICADO
    • La clave pública.
    • La identidad del poseedor.
    • La identidad de la CA.
    • Una fecha de validez para esta asociación.
    • Identificación de la asociación
    • Firma digital (para protegerlo de manipulaciones malintencionadas)
    • Versión del formato
    • Algoritmos usados en firma y hash
    • ………
    • Alice descarga el certificado de Bob del almacén seguro
    • Alice firma el mensaje con su Kpriv, usará la Kpub de Bob si envía dicho mensaje de forma cifrada
    • Bob verifica la firma electrónica del mensaje y luego el certificado del remitente
    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
    • Validación de mensaje + Validación Certificado
      • Verificar la validez del certificado del remitente.
        • Existencia del certificado
        • Dentro del período de validez.
        • Certificado no revocado.
        • Firma electrónica de la CA correcta.
      • Verificar la firma electrónica del mensaje con la clave pública del remitente
    • 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
    Validación de mensajes firmados
    • Un lugar idóneo para guardar certificados es la base de datos distribuida X.500 (directorio).
    • X.500 asocia una entrada de una base de datos distribuida y organizada jerárquicamente según un árbol, a cada agente del sistema.
    • Cada usuario puede depositar su certificado en su entrada del directorio y el resto de usuarios puede acceder a dicha entrada y recogerlo.
    Infraestructura. Ldap
  • Infraestructura. Ldap X.500 Usuario A Usuario B Almacén seguro Autoridad de Certificación (CA)
    • X.500: Estructura de directorios jerárquica.
    • Cada entrada se etiqueta con un Nombre Distintivo (Distinguished Name -DN-).
    • Un DN contiene valores de atributos:
      • País
      • Organización
      • Unidad organizativa
      • Nombre de usuario
    • CAs y usuarios pueden depositar sus certificados en el directorio X.500
    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
    • Los certificados tienen una vida limitada. Al finalizar el período de validez, expiran.
    • Un certificado puede dejar de ser válido por varios motivos (REVOCADO):
      • Si se sospecha que alguien ha tenido acceso a la clave privada, debe revocarse el certificado con la correspondiente clave pública.
      • Cuando el poseedor de un certificado cambia de empresa su DN no es válido.
    • En tales casos, la CA debe realizar las operaciones necesarias para REVOCAR el certificado.
    • 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.
    • Estas listas pueden depositarse en la entrada de la CA en el directorio X.500.
    Certificados y CRLs
    • 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.
    • Proceso:
      • Recepción de mensaje firmado.
      • Acceso a X.500 para recoger certificado de usuario.
      • Comprobación de que no está revocado.
    • 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.
    Certificados, CRLs y verificación
    • En sistemas complejos: jerarquías de CAs.
    • Necesidad de verificar secuencias de certificados de CAs hasta llegar al de una CA en la que se confíe.
    • Usuarios y CAs intercambiarán mensajes de gestión de certificados (para solicitar certificados, entregarlos, solicitar revocación, confirmarla, etc.).
    • Al hablar de infraestructura pues, estamos refiriéndonos a agentes presentes, mensajes intercambiados y “reglas de juego”:
      • Servicios, plataformas, algoritmos, normas, protocolos, responsabilidades, estructutras
    Conclusiones
    • Definición en ASN.1. Codificación DER.
    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 }
    • Tipo de certificados que debe usarse para generar Firmas Electrónicas Avanzadas (según la Directiva Europea)
    • 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.
    Certificado Reconocido (Qualified Cert.)
    • Definición en ASN.1. Codificación DER.
    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 }
    • Necesidad de estándares: asegurar la INTEROPERABILIDAD entre aplicaciones que aplican Criptografía de Clave Pública, desarrolladas por fabricantes diferentes.
    • Desarrollados por RSA Security y fabricantes (Microsoft, Sun, Apple, etc)
    • Qué se ha estandarizado?:
      • la sintaxis de los mensajes
      • los algoritmos
    • Qué asuntos quedan abiertos, a criterio del desarrollador
    Public Key Cryptography Standards
  • Public Key Cryptography Standards Public-Key Cryptography Standards http://www.rsasecurity.com/rsalabs/pkcs/index.html
    • Autenticación del Origen
    • Integridad del Contenido
    • Confidencialidad del Contenido
    • No Repudio del Origen
    • 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
    • S/MIME (Multipurpose Internet Mail Extensions), igual que anterior, soporte MIME
    • PGP 
    Aplicaciones. email
    • Firma de formularios, Firma de páginas web, Firma de código
    • Autenticación
    • SSL
      • Desarrollado por Netscape Communications Corp.
      • Permite proteger cualquier comunicación de cualquier aplicación que opere sobre TCP (http, FTP, Telne, cualquier tunel SSL)
      • Ofrece servicios de Seguridad para Sesiones entre cliente/servidor
        • Autenticación del Servidor
        • Autenticación del Cliente
        • Integridad del Contenido transferido
        • Confidencialidad
    Aplicaciones. Web seguro
    • Pasarelas/medios de pago
    • e-commerce, e-business, m-commerce
    • e-gambling, e-voting (avanzada)
    • Firma y cifrado con XML, web services
    • Autenticación: SSO, Kerberos
    • Tokens: SmartCards de memoria y criptográfica, JavaCards
    Aplicaciones. Transacciones seguras
  • PKI: Ejemplos
    • Autoridades de Certificación
      • OpenCA – http://www.openca.org Linux, GPL, basado en OpenSSL, Apache, Perl, MySQL y Ldap
      • NewPKI – http://www.newpki.org Windows, GPL, C/C++, desarrollo propietario, MySQL y Ldap
      • EJBCA – http://ejbca.sourceforge.net Multiplataforma(Java), basada en API Criptográfico de Java, J2EE/Jboss, MySQL y Ldap
    • BDs y Ldap
      • MySQL – http://www.mysql.org
      • Postgres – http://www.postgres.org
      • OpenLdap – http://www.openldap.org
    • Servidores web, application server
      • Apache – http://www.apache.org
      • JBoss – http://www.jboss.org
  • June 2003 Survey on PKI Obstacles
    • Objetivo
      • Identificar principales obstáculos para el despliegue y uso de PKI
    • Cómo
      • Web-based survey deployed June 9 to 22, 2003 (OASIS)
      • Invitation distributed through PKI standards bodies, trade groups, user associations, etc.
    • Encuestados
      • 216 valid responses, many with careful text comments
      • 44% IT management and staff, remainder developers, consultants, etc.
      • Primary Work Location: 61% North America, 24% Europe, 6% Asia
      • Over 75% with 5 or more years experience in InfoSec/Privacy
      • 90% either helped deploy PKI or developed PKI-related software
    Ver encuesta http://www.ietf.org/proceedings/03nov/slides/pkix-2/pkix-2.ppt