1st Peruvian Workshop on IT Security 29.Dic.2003

Transcripción

1 1st Peruvian Workshop on IT Security 29.Dic.2003 Colaboración PKI aplicada Roger Carhuatocto Miembro escert -UPC Responsable de Servicios Educacionales Instituto de Investigación UNI-FIIS escert-upc C/ Jordi Girona, 1-3. Campus Nord, UPC Barcelona ~ España Tel. (34) ~ Fax. (34) 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 2 2

2 Servicios de Seguridad 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. 3 3 Infraestructura. Por qué?. 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. 4 4

3 Infraestructura. Conclusión 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. 5 5 Certificado y CA Almacén seguro Autoridad de Certificación (CA) 1. Da garantía: Firma digitalmente la relación clave pública e identidad del poseedor de la clave. 2. Dicha relación se añade a la estructura del CERTIFICADO 3. Gestiona la estructura de información (CERTIFICADO) 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) NO HAY INFORMACIÓN CONFIDENCIAL. 6 6

4 Certificado y CA Almacén seguro Autoridad de Certificación (CA) 1. Da garantía: Firma digitalmente la relación/asociación clave pública e identidad del poseedor de la clave. 2. Dicha relación se añade a la estructura del CERTIFICADO 3. Gestiona la estructura de información (CERTIFICADO) 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 7 NO HAY INFORMACIÓN CONFIDENCIAL. 7 Certificado, Firma y cifrado 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 Almacén seguro Autoridad de Certificación (CA) KAlice privada KAlice pública Firma Digital Verificación de Firma Digital SI? 8 8

5 Validación de mensajes firmados 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 9 9 Infraestructura. Ldap 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

6 Infraestructura. Ldap Autoridad de Certificación (CA) Almacén seguro X.500 Usuario A Usuario B Ldap 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 CA SubA.1 C=PE O=UNI-FIIS CN=Roger Carhuatocto CA SubA OU=ACME CA Raíz C=ES CA SubB 12 12

7 Certificados y CRLs 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 Certificados, CRLs y verificación 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

8 Conclusiones 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 Certificado X.509 Definición en ASN.1. Codificación DER. 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 } 16 16

9 Certificado Reconocido (Qualified Cert.) Tipo de certificados que debe usarse para generar Firmas Electrónicas Avanzadas (según la Directiva Europea) Es un perfil 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. 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 } AuthorityKeyId SubjectKeyId KeyUsage CertPolicies CRLDistributionPoint 18 18

10 Public Key Cryptography Standards 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

11 Aplicaciones. 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. Web seguro 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 22 22

12 Aplicaciones. Transacciones seguras 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 PKI: Ejemplos Autoridades de Certificación OpenCA Linux, GPL, basado en OpenSSL, Apache, Perl, MySQL y Ldap NewPKI Windows, GPL, C/C++, desarrollo propietario, MySQL y Ldap EJBCA Multiplataforma(Java), basada en API Criptográfico de Java, J2EE/Jboss, MySQL y Ldap BDs y Ldap MySQL Postgres OpenLdap Servidores web, application server Apache JBoss

13 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 distributedthrough 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. PrimaryWork Location: 61% North America, 24% Europe, 6% Asia Over 75% with 5 or more yearsexperience in InfoSec/Privacy 90% either helped deploypki or developedpki-related software Ver encuesta