Implementación de una BridgeCA

1. Implementación de una BridgeCA Gabriel López Millán Universidad de Murcia gabilm@dif.um.es

2. Objetivos • Realizar una estudio de los principales modelos de certificación cruzada • Jerárquica, Peer-to-Peer, BridgeCA, … • Definir un modelo de confianza basado en una Federación de PKIs en un entorno real • Escenario multidominio • Tipos de relaciones entre las organizaciones • Establecer los requerimientos de certificación • Servicios de certificación • Tipos y uso de las extensiones de certificados para certificación cruzada • Desplegar el escenario

3. Contenido • Introducción • Escenario real de certificación • Modelo de confianza para una Federación de PKIs • Conclusiones y Vías Futuras

4. RootCA RootCA Certificación cruzada • Establecer relaciones de confianza entre CAs • Los certificados se pueden validar de forma automática por las terceras partes confiables • La relación de confianza puede ser unidireccional o bidireccional • Definidas por un certificado cruzado en cada sentido • Certificado cruzado: • Certificado de CA firmado por otra CA • Porta las restricciones de la relación: extensiones • Se definen caminos de certificación que hay que descubrir y validar reverse forward

5. RootCA SubCA SubCA end entity end entity Principales modelos de Certificación Cruzada - Jerárquico • Única CA Raíz • Certificación unidireccional • CA superior  CA subordinada • Fácil de implantar y mantener • Caminos de certificación sencillos • Modelo ideal para organizaciones con grandes requerimientos de control • Útil para el caso de mono-dominios, pero surgen problemas en relaciones multi-dominio • Relaciones con otras CAs Raíz

6. RootCA RootCA RootCA RootCA Principales modelos de Certificación Cruzada – Peer-to-Peer • Ideado para relaciones con CAs externas • Relaciones bidireccionales • CA1  CA2 • CA2  CA1 • Se establecen mallas de certificación • Más complejo de implantar y gestionar • Aumentan los caminos de certificación • Aumenta la longitud de estos caminos • Difíciles de descubrir (detección de búcles) • Requiere un SLA (Service Level Agreement) entre las organizaciones • Para n CAs  n(n-1)/2relaciones

7. RootCA RootCA RootCA RootCA BCA Principales modelos de Certificación Cruzada - BridgeCA • Actúa como punto neutral de confianza • Cada CA relacionada expande la nube de confianza, según las restricciones impuestas • Es necesario establecer un SLA para cada relación • Soluciona problema de escalabilidad anterior • n CAs  n relaciones

8. Principales modelos de Certificación Cruzada • Otros modelos (1) • Cross Recognition: “The (foreign) CA is regarded as trustworthy if it has been licensed/accredited by a formal licensing/accreditation body or has been audited by a trusted independent party”. • Certificate Trusted List: “… a signed PKCS#7 data structure that can contain, among other things, a list of trusted CAs . A trusted CA is identified within the CTL by a hash of the public key certificate of the subject CA. The CTL also contains policy identifiers and supports the use of extensions”

9. Principales modelos de Certificación Cruzada • Otros modelos (2) • Accreditation Certificate: “…it introduces the use of an accreditation certificate that could be used to indicate that a given CA is accredited by the Australian government.”

10. Restricciones en Modelos de Certificación Cruzada • Vendrán definidas por las extensiones que portan los certificados cruzados emitidos para establecer la relación • Definidas en RFC3280 • Basic Constraints • Certificate Policies • Name Constraints • Policy Constraints • Policy Mapping

11. Contenido • Introducción • Escenario real de certificación • Modelo de confianza para una Federación de PKIs • Conclusiones y Vías Futuras

12. Descripción del escenario real • Uso de la red definida por el proyecto Euro6IX • Red IPv6 pan-europea • Formada por IXs, proveedores de red y usuarios finales • Participan las principales operadoras europeas • TID, TILAB, BT, FT,… • Cada IX ofrece servicios a nivel de aplicación • Seguridad, QoS, movilidad, multihoming,… • Seguridad: AAA, DNSSec, VPNs… • Requisitos de certificación comunes  Federación de PKIs

13. Red Euro6IX

14. Tipos de relaciones • Relaciones Fuertes • Establecidas entre IXs • Entre organizaciones bien conocidas con intereses comunes • Relación estable y duradera • Basadas en SLAs • Cada IX tendrá su propia CA Raíz • FLSD = First Level Security Domain • Relaciones Normales-Débiles • Establecidas entre IXs y proveedores de red o entre proveedores de red • Basadas en requerimientos de negocios o políticos • Pueden cambiar más frecuentemente • Cada proveedor de red puede tener su propia CA Raíz o usar los servicios de un IX • SLSD = Second Level Security Domain

15. Contenido • Introducción • Escenario real de certificación • Modelo de confianza para una Federación de PKIs • Conclusiones y Vías Futuras

16. Requerimientos del escenario (I) • Cada dominio puede tener su propio modelo de certificación interno: Jerárquico, Peer-to-Peer, BridgeCA, etc.. • Solución basada en dos niveles: • Primer nivel basado en BCA • Relaciones entre FLSD

17. Requerimientos del escenario(II) • Segundo nivel basado en Peer-to-Peer • Relaciones entre SLSD

18. Requerimientos del escenario (III) • Servicios de Validación • Determinan si un certificado es válido o no • CRL/ARL • OCSP (On-line Certificate Status Protocol) RFC2560 • Utilizado por las terceras partes confiables • Usuarios • Sistemas finales (nodos VPNs, servidores, etc) • Gestión de los caminos de certificación • Descubrimiento • Validación • Protocolos de acceso a los servicios de validación • DVCS (Data Validation and Certification Server Protocols) RFC3029 • SCVP (Simple Certificate Validation Protocol). Draft

19. Requerimientos del escenario (IV) • Acceso a repositorios públicos para descubrimiento del camino de certificación • LDAP • DNSSec • DB interna • Servicio de gestión de claves basado en protocolos estándar • Permiten gestionar el ciclo de vida de los certificados digitales • CMC (Certificate Management Messages over CMS) RFC2797 • CMP (Certificate Management Protocol) RFC2510

20. Gestión de caminos de certificación • Bob en SLSD-C recibe mensaje protegido con clave privada de Alice en SLSD-A • Bob confía en Alice si: • Existe un camino de certificación entre Alice y una entidad confiable por Bob • El camino es válido • El camino CA(SLSD‑C)CA(FLSD-1)BCA(Euro6IX)CA(FLSD-2)CA(SLSD-A)C(Alice)debe ser descubierto por el servicio de validación del dominio SLSB-C • Algoritmo de construcción de caminos • Uso de extensiones CRLDistributionPoint, AuthorityInformationAccess y SubjectInformationAccesspara descubrir servicios (CRL, OCSP) y repositorios (LDAP, DNSSec)

21. Extensiones de certificados • M=Mandatory • O=Optional • R=Recommended • N=Not recomended

22. Despliegue del escenario • PKI: UMU-PKIv6 (http://pki.dif.um.es) • Servicios: • LDAP: OpenLDAP, • CRLs/ARLs, CCs (crossCertificatePair) • DNSSec: Bind 9.2.1, Almacena certificados: EE, CA y CRL • TSIG: interacción mediante claves simétricas • SIG(0): en proceso • Autoridades OCSP y TSP. Basados en Java-Servlets • Autoridad de Servicios de Validación. • Uso CRLs, OCSP y LDAP • Basado en DVCS y SCVP • Gestión de claves: CMC. APIs: Java/Perl/C

23. Despliegue del escenario Version=V3 Serial Number=13D Signature Algorithm=sha1RSA Issuer=”CN=UMU PKI CA (pki.dif.um.es), OU=UMU DIIC, O=UMU, C=ES” Valid after=01/01/04,Valid before=31/12/06 Subject=”CN=EURO6IX BCA (bca.euro6ix.org), OU=BCA, O=EURO6IX” Public Key=RSA(2048) “1920 FA71 ....” Fingerprint=”51FE CE95….” Extensions: Basic Constrainst=”CA: True, pathLen=optional” Key Usage=”Digital Signature, Key Ciphered, Data Ciphered, Certificate Signature, CRL Signature” Extended Key Usage=”Email Signature, Server Authentication” CRLDistributionPoint=”http://pki.dif.um.es/servlet/GetCRL” SubjectKeyIdentifier=”31 32 d1 ….” CertificatePolicies=”OID.umu_policy_low,http://pki.dif.um.es/cps” Policy Mappings=”{OID.umu_policy_low,OID.euro6ix_bca_policy}” Name Constraints= “ExcludedSubtress (O=UMU,C=ES)” AuthorityInformationAccess=“(OID.ocsp,http://pki.dif.um.es/servlet/OCSPResponder),(OID.caRepository,ldap://ldap.dif.um.es)”

24. Despliegue del escenario • Estado actual: • BCA en estado de pruebas situada en UMU • CA Raíz de UMU para el proyecto Euro6IX conectada a BCA • Varias CAs raíces piloto conectadas a la BCA • Desarrollo de la Autoridad de Servicios de Validación • Descubrimiento de caminos • Extensiones de certificación • LDAPv6, DNSSec • Validación en base a CRL, ARLs y OCSP • Interfaz basada en DVCS y SCVP

25. Contenido • Introducción • Escenario real de certificación • Modelo de confianza para una Federación de PKIs • Conclusiones y Vías Futuras

26. Conclusiones • Implantación de una Federación de PKIs basada en BCA en un entorno real • Fácilmente exportable a otros escenarios • Recursos y entidades interesadas • Es necesario definir formalmente como gestionar SLAs • Establecimiento, Renovación, Revocación • Reduce la sobrecarga de la gestión de seguridad dentro de la Federación • Es necesario definir requisitos: • Servicios, Protocolos, Certificados • Uso de UMU-PKIv6

27. Vías Futuras • Despliegue de la infraestructura en cada IX y proveedor de red del proyecto • Migración a otros escenario • Uso en entornos de roaming • Integración con aplicaciones y servicios basados en certificación X.509

28. ¿Preguntas? gabilm@dif.um.es http://pki.dif.um.es