Seguridad en Redes. Administración de Claves Asimetricas. PKI Ing Hugo Pagola.

Transcripción

1 Seguridad en Redes Administración de Claves Asimetricas PKI Ing Hugo Pagola

2 Administración de claves (key management) Posibilidades: Distribución de claves publicas Anuncio Publico Directorio Publico Autoridad de claves publicas Autoridad Certificante Uso de claves publicas para distribuir claves simétricas 2

3 Anuncio publico Los usuarios distribuyen sus claves ej. Incorporar las claves PGP al enviar claves PGP. Debilidad Cualquiera puede enviar un haciéndose pasar por otro 3

4 Directorio Publico Las claves se registran en un directorio publico Debe ser confiable y cumplir con: Tener entradas {nombre, clave publica} Los usuarios se deben registrar de forma segura Los participantes deben poder hacer un ABM de sus entradas Debe ser publico Debe poder ser accedido electrónicamente NO ES ESCALABLE Único punto de falla 4

5 Autoridad de claves publicas (Public-Key Authority) Mejora la seguridad validando las claves que retorna el directorio (mediante firma digital) Requiere que los usuarios conozcan la clave publica de la autoridad Los usuarios consultan con la autoridad para obtener la clave Requiere acceso en línea con la autoridad 5

6 Autoridad de claves publicas (Public-Key Authority) 6

7 Certificados: Autoridad Certificante Permiten el intercambio de claves sin el acceso en línea con la autoridad PKI El certificado es equivalente una cedula de identidad, la identidad es demostrada por el certificado Usualmente contiene la identidad, periodo de validez, derechos de uso, etc. Es un archivo con un formato especifico que contiene registros. Dicho archivo es firmado por la autoridad certificante. (Certificate Authority CA) Puede ser verificado por cualquiera que conozca la clave publica de la autoridad. 7

8 Certificados: Autoridad Certificante 8

9 Distribución de claves simétricas por medio de PKI Usar cualquiera de los métodos anteriores para obtener las claves publicas de las partes Se negocia una clave de sesión. Generada Por una de las partes Por las dos partes Ej. Diffie Hellman 9

10 Merkle: Generación de clave de sesión A genera un par de claves asimetricas A envía a B su clave publica y su identidad B genera la clave de sesion K y se la envia utilizando la clave publica recibida A desencripta con la privada. Un tercero puede interponerse y personificar al lado A. man in the middle 10

11 Public-Key Distribution of Secret Keys Requisito, claves publicas ya intercambiadas: 11

12 Needham-Shroeder (autoridad de claves) A S B A,B Public data k A, k B [B,k B ] k S {A,n A } kb B,A [A,k A ] k S {n A,n B } ka {n B } kb 12

13 Needham-Shroeder Ataque de Lowe A B: {A,n A } kb B A: {n A,n B } ka A B: {n B } kb A I B {A,n A } ki Public data k A, k B, k I {A,n A } kb {n B } ki {n A,n B } ka {n B } kb Se omitio intercambios con autoridad. Ataque descubierto 17 años despues de creacion algoritmo 13

14 Needham-Shroeder Ataque de Lowe A B: {A,n A } kb B A: {n A,n B } ka A B: {n B } kb A I B {A,n A } ki Public data k A, k B, k I {A,n A } kb {n A,n B,B} ka Se omitio intercambios con autoridad. Ataque descubierto 17 años despues de creacion algoritmo 14

15 Infraestructura de clave publica PKI

16 Software, hardware, personas, políticas y procedimientos necesarios para Crear, manejar, guardar, distribuir y revocar un Certificado Digital. La conexión entre claves y usuarios se establece por los procesos Registracion emisión de certificados. 16

17 Usos de la tecnología PKI Login de de usuarios y sistemas (Autenticación) Identificación del interlocutor Cifrado de datos digitales Firma digital de documentos, software, etc. Comunicaciones: SSL, ipsec/vpn. Garantía de no repudio. Bootstraping. Conexión segura inicial para por ejemplo, negociar una clave simétrica. 17

18 Servicio de Autenticación X.509 Es parte de la norma CCITT X.500 servicio de directorio. Servidores distribuidos, y base de seguridad Define un Framework para servicios de autenticación: El directorio contiene claves publicas Con la clave publica del usuario Firmados por la autoridad certificante Se definen protocolos de autenticación Los algoritmos no están estandarizados pero es recomendado el RSA 18

19 IETF PKIX IETF basado en certificados X.509 desarrollo la arquitectura PKIX. El término PKIX se refiere a la infraestructura de clave pública basada en certificados X.509 (Public Key Infrastructure X.509) Hace referencia a los perfiles de certificado y de listas de revocación basados en el estándar de certificados X.509v3. El grupo de trabajo PKIX ha producido: una serie de estándares para satisfacer las necesidades de una PKIX. RFC 2510 CMP (Certificate Management Protocols) RFC 3647 Certificate Policy and Certification Practices Framework RFC 3280 Certificate and CRL Profile RFC 2560 Online Certificate Status Profile RFC 3161 Time Stamp Protocol 19

20 Modelo Simple de un PKI CA Aplicacion Cert. Request Signed Certificate Internet RA Certs, CRLs Directorio Persona Persona Local 20

21 Arquitectura de PKIX Usuarios Obtencion de Certificados / CRLs Entidad Final Registro de Datos Autoridad de Registración Publicacion de Certificados / CRL Autoridad yes Certificante Publicacion de CRL Emisor de CRL Infraestructura PKI 21

22 Arquitectura de PKIX Componentes Proveedor: RA (Registration Authority) Recibe las solicitudes de certificados, puede generar las llaves. CA (Certification Authority) Firma los certificados con clave privada. Equipo offline. Repositorio de los certificados Directorios de certificados (X.500, LDAP). Emisor CRL (Cetificate Revocation List) Lista certificados revocados (tiempo de vida, o otros motivos). Componentes Usuario Aplicaciones preparadas para PKI

23 RA Autoridad de Registración Elemento opcional de la arquitectura PKIX que puede asumir algunas funciones administrativas de la CA Tareas Básicas: El proceso de registro de las entidades finales. Puede realizar el proceso de revocación de certificados El manejo de los datos de la entidad final. Dentro de una jerarquía de certificación pueden existir una o varias autoridades de registro, las cuales pueden ser internas o externas a la jerarquía de certificación del PSC. 23

24 CA Autoridad de Certificación Tareas Básicas Encargada de emitir los certificados digitales X.509. Usualmente también las listas de revocación de certificados (CRLs). A veces se delega la función de emitir CRLs a un elemento Emisor CRL. También puede desempeñar funciones administrativas como las de registro de entidades finales o publicación de certificados pero normalmente estas funciones son desempeñadas por las autoridades de registro. Existen como mínimo dos tipos de CAs en una jerarquía de certificación: CA raíz (RootCA) La primera es la que emite certificados a otras CAs y la que cuyo certificado ha sido autofirmado. CA subordinada (SubCA). Es la que emite certificados de entidad final y cuyo certificado ha sido firmado digitalmente por la CA raíz. En una jerarquía pueden haber una o varias CAs subordinadas. 24

25 Arquitecturas de CA CA CA CA CA Directory Services CA RA CA CA CA RA RA Internet RA RA RA Internet LRA LRA 25

26 Entidad final Es el nombre que reciben los usuarios de una PKI Estos pueden ser identificados en el campo que define al propietario del certificado X.509. Emisor CRL Elemento opcional de la arquitectura PKIX a el que la CA puede delegar la función de emitir las CRLs. Algunas veces se encuentra integrado en la CA a modo de servicio. 26

27 PKIX Términos Repositorio: Hace referencia a cualquier método existente para: Almacenar certificados. Almacenar CRLs. Método de acceso para ser obtenidos por las entidades finales. El mas común es LDAP. Típicamente Directorio X500, DAP, ldap. 27

28 PKIX Términos Autoridad de Validación (Validation Authority, VA): Puede existir un sexto elemento Da información sobre la vigencia de los certificados digitales. Recoge la información de qué certificados han sido anulados. Habitualmente utiliza el protocolo OCSP para prestar los servicios de validación y no está incluida en la arquitectura PKIX porque es común que estos servicios los preste la misma CA. Para aislar los datos de la comprobación de la vigencia de un certificado de los datos de identidad de su titular se recomienda usar una autoridad de validación separada. 28

29 PKIX funciones de gestión Registro: Este es el proceso por el cual una entidad final registra sus datos en una CA o por medio de una RA. Inicialización: Es el proceso por el cual el cliente se inicializa, de forma segura, con su clave pública y con otra información relevante de la CA en la que se ha registrado. La información de esta CA es la que se utilizará en el camino de validación de certificados Certificación: Es el proceso por el cual la CA crea un archivo que certifica que una determinada clave pública pertenece a una entidad final, y se lo retorna al sistema del cliente o lo almacena en un repositorio. Recuperación del par de claves: Este proceso permite a las entidades finales volver a obtener su par de claves, para esto las piden a una entidad autorizada de resguardo de claves. Usualmente la misma CA que emitió el certificado hace el papel de esta autoridad. Si se ha perdido el acceso a la clave de desencriptación no se podrán recuperar los datos encriptados. 29

30 PKIX funciones de gestión 2 Pedido de Anulación (revocación): Una persona autorizada avisa a la CA que ha ocurrido un suceso anormal y pide anulacion del certificado de una entidad final. Los motivos pueden ser el compromiso de la clave privada, el cambio de nombre de la entidad, entre otros. Certificación cruzada: Es el proceso en el cual dos CAs intercambian la información necesaria para emitir un certificado cruzado. Este certificado es el que una CA raíz emite a una CA subordinada, siempre y cuando esta última CA cuente con una clave de firma autorizada para emitir certificados, normalmente, de entidad final. 30

31 Prácticas y Políticas de Certificación Los prestadores de servicios de certificación están obligados a: Efectuar una supervisión y gestión permanente de los certificados electrónicos que expiden Documentar los procedimientos y prácticas que desarrollen a fin de cumplir con esta gestión. Este documento debe estar disponible al público de manera fácilmente accesible. En RFC 3647 (Certificate Policy and Certification Practices Framework) se describen cada uno de los puntos que necesitan ser cubiertos por este documento. 31

32 Declaración de Prácticas de Certificación En este documento se especifican: Las condiciones aplicables a la solicitud, expedición, uso, suspensión y extinción de la vigencia de los certificados electrónicos. Se explican las obligaciones del prestador en cuanto a la gestión de los datos de creación de firma y de certificados electrónicos. También se decriben las medidas de seguridad técnicas y organizativas de la empresa, Los tipos de perfiles que existen Los servicios de validación de certificados disponibles. 32

33 Políticas de Certificación Cada tipo de certificado emitido se rige por condiciones particulares de emisión recogidas en un documento denominado Política de Certificación. Existe una política de certificación por cada tipo de certificado emitido por una CA. Servidor Seguro SSL Firma de Código Persona Vinculada 33

34 Proveedores de PKI IBM Entrust ChosenSecurity RSA Security, Cyber Trust CA Microsoft Novell 34

35 twg/index.html 35

36 Certificados Digitales

37 Certificados Digitales y Estándar PKCS Un certificado digital es un documento que contiene datos de identidad, el nombre de un usuario y su clave pública, es firmado por una Autoridad Certificante (AC). El emisor y el receptor deben confiar en la AC. El usuario se autenticará ante el otro, presentando el certificado. El certificado contiene la clave pública firmada por dicha autoridad. 37

38 Certificados X.509 Expedido por la Autoridad Certificante (Certification Authority - CA), incluye: versión (1, 2, or 3) Numero de Serie para identificar el Certificado (Unico en el CA) Identificación del Algoritmo de Firma Nombre X.500 de la CA Periodo de validez del certificado (Desde - Hasta) Identificación X500 del Dueño del certificado.( subject X.500 name) Información de la clave publica (algoritmo, parámetros, clave) issuer unique identifier (v2+) subject unique identifier (v2+) extension fields (v3) Firma del Hash de todos los parametros Version Numero de Serie Identificador del Algoritmo dn del Emisor Periodo de Validez Algoritmo Parametros Desde Hasta dn del Dueño (subject) Informacion de la clave publica Algoritmo Parametros Clave Version 1 Identificador unico del emisor Identificador unico del subject Version 2 Extensiones Version 3 FIRMA algoritmo Parametros firma La notación CA<<A>> indica que el certificado de A esta expedido o firmado por CA 38

39 39

40 -----BEGIN CERTIFICATE----- MIIDZjCCAs+gAwIBAgIQDYtP7qrSGFv0dWqdKeF/+zANBgkqhkiG9w0BAQIFADBf MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT LkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw HhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVy avnpz24sieluyy4xhzadbgnvbastflzlcmltawduifrydxn0ie5ldhdvcmsxrjbe BgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC esbszwyulexjquiutfrekgmpotgxsdbgbgnvbamtp1zlcmltawduiensyxnzideg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCB nzanbgkqhkig9w0baqefaaobjqawgykcgyeau1peigqwu1x9a3qklzrpfxg2ua1k sm+cvl+86hcqnbnwaluv2tfbchqbs7lie1ytxwjhhekrwkksq0rcqklwgg4c6s/7 wju7vskncl22sdzcm7vuvihph0q/gdr5fegph7yc48zgmo5/aiss4/zgzbqnsx7v yds3ashkyakg5jkcaweaaaobtdcbstarbglghkgbhvhcaqeebamcaqywnqydvr0f BC4wLDAqoCigJoYkaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS4xLjEuY3Js MEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZl cmlzawdulmnvbs9yzxbvc2l0b3j5l1jqqtapbgnvhrmecdagaqh/ageamasga1ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQBCfA7fjHlMrL8I7E1VL1CJoMVeTi5e ltkbea1leqscslle1agxiy7eejtscmuh5go558g0eakj8rwgqvhajiprit6qivxz 4yHSz2WMBjOwzSCyM80KvT7hncE1qWSwp6UkW+nxaOsTxHw39JRkDZrFvTMX74Mz od7lqj6u2hmfrq== -----END CERTIFICATE

41 Formatos de certificado Certificado X.509 v1 Certificado X.509 v3 Certificados de una CA Certificados de una CRL PKCS Contenedores de estructuras criptográficas 41

42 Certificado X.509 v1 Ejemplo: Una CA identifica a un certificado por su Serial umber SEQUE CE { tobesigned: SEQUENCE { version: 0 (v1) serial umber: signature: pkcs1-sha1withrsasignature issuer: CN=root, O=UOC, C=ES validity: SEQUENCE { notbefore: [utctime] " Z" notafter: [utctime] " Z } subject: CN=Name Surname1, OU=Development, O=Empresa1, C=ES subjectpublickeyinfo: "AF3FD31ABEE4C1F743D... 0BD8F8DF7" } D : Distinguished ame CN : Common ame (nombre común) OU : Organizational Unit (departamento) O : Organization (organización) C : Country (país) Periodo de validación Incluye otra secuencia ASN.1 codificada en DER signaturealgorithm : pkcs1-sha1withrsasignature signature: "56A376E029E DFB19FBFAF } Firma digital con la clave privada de la CA emisora 42 Au: Raúl González Martínez

43 Certificado X.509 v3: extensiones Extensiones más comunes: SubjectAltName: Nombre alternativo del titular (web o del titular) keyusage (crítico): Indica el uso que se debe hacer de ese certificado, por ejemplo si es para firmar, cifrar, firmar CRL s, etc... ExtendedKeyUsage (crítico): Similar al anterior. crldistributionpoints (crítico): Identifica los puntos donde se podrá acceder a las CRL s para comprobar si el certificado ha sido revocado. basiccontraints (crítico): Indica si el certificado proviene de una CA o no. En caso afirmativo, indica si es raiz o no. 43

44 KeyUsage ::=BIT STRING { digitalsignature (0), nonrepudiation (1), keyencipherment (2), dataencipherment (3), keyagreement (4), keycertsign (5), crlsign (6), encipheronly (7), decipheronly (8) } digitalsignature se usara para firma digital en autenticación de partes o autenticación de origen. nonrepudiation se usara para garantizar el no repudio. Una tercera parte confiable debera mediar. keyencipherment Se usara para cifrado de claves dataencipherment Se usara para cifrado de datos keyagreement: El certificado sera usado para un algoritmo de intercambio de claves. Ej Diffie- Hellman keycertsign se usara para verificar claves publicas (CA) crlsign se usara para verificar CRLs encipheronly se usara para cifrar en el intercambio de claves decipheronly se usara para descifrar en el intercambio de claves 44

45 id-kp-serverauth: Autenticación Server TLS Keyusage: digitalsignature, keyencipherment o keyagreement id-kp-clientauth: Autenticacion cliente TLS Keyusage: digitalsignature, keyencipherment o keyagreement id-kp-codesigning: Firma de codigo ejecutable. Keyusage: digitalsignature id-kp- protection Proteccion Keyusag: digitalsignature, nonrepudiation, y/o (keyencipherment o keyagreement) id-kp-timestamping: Fechado de un Hash KeyUsage: digitalsignature y/o nonrepudiation id-kp-ocspsigning -- Firma de respuestas OCSP KeyUsage: digitalsignature y/o nonrepudiation 45

46 Certificados de la Autoridad de Certificación Cuando el emisor de una CA es el mismo que el receptor, campos Issuer y Subject respectivamente, se dice que que el certificado es auto-firmado. En este caso estaremos hablando de una CA raíz. No todas las CA s son raíz, existen también subordinadas que disponen de un certificado firmado por una CA de nivel superior. 46

47 Extensiones de archivo de certificados.cer Certificado codificado en CER, algunas veces es una secuencia de certificados.der Certificado codificado en DER.PEM Certificado codificado en Base64 encerrado entre "-----BEGIN CERTIFICATE y "-----END CERTIFICATE-----" 1..P7B.P7C.P12.PFX Estructura PKCS#7 SignedData sin datos, solo certificado(s) o CRL(s) Usado para Firmar y/o cifrar mensajes. PKCS#12, puede contener certificados y claves privadas (protegido con clave) 47

48 PKCS #7: Contenedores de datos PKCS #7: Contenedores de datos no estructurados. Usos: Datos firmados no incluidos. (No contiene los datos que firma) Datos firmados incluidos. Datos cifrados. Datos cifrados y firmados. Cadenas de certificación. Certificados individuales. (por ejemplo que responden a una petición de certificación). 48

49 Contenedores de estructuras criptográficas: PKCS (Public( Key Criptograhic Standards) Uno de los usos de los PKCS son las peticiones de certificados. Básicamente existen dos maneras de pedir un certificado: 1. El cliente genera su clave pública y privada y manda a validar su certificado a una CA. 1. PCSK #10 para el envió de la solicitud. 2. PKCS#6 para la respuesta con el certificado 2. El cliente pide a una CA un certificado. En este caso es la CA quien genera el par de claves y se lo envía con un PKCS #12. Este contenedor ira protegido con un password para que nadie pueda ver la clave privada emitida. 49

50 PKCS #10: Petición n de un certificado SEQUENCE { tobesigned: SEQUENCE { version: 0 (v1) subject: CN=Melcior, O=Reis Mags subjectpublickeyinfo: "AF3FFDA...08F8DF7" attributes:... signaturealgorithm: sha1withrsasignature } signature: " 7767DD DC00F60A } 50

51 PKCS#10. Entorno de uso Petición de Certificado PKCS#10 CA Certificado PKCS#6 Certificado X

52 PKCS#12. Entorno de uso Petición de Claves CA PKCS#12 Certificado X

53 PKCS#12. Introducción Describe una sintaxis de transferencia de información personal: Claves privadas Certificados Cualquier tipo de información secreta Extensiones Las máquinas,aplicaciones y navegadores que soportan esta norma permiten importar, exportar y emplear un conjunto de información con un identificador personal. Soporte de la información personal que se transfiere. 53

54 S/MIME Basado en PKCS#7 Definido inicialmente para proteger 54

55 S/MIME : Ejemplo Content-Type: multipart/signed; protocol= application/x-pkcs7-signature ; micalg=sha1; boundary= -----aaaaa -----aaaaa Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello! -----aaaaa Content-Type: application/x-pkcs7-signature Content-Transfer-Encoding: base64 MIIN2QasDDSdwe/625dBxgdhdsf76rHfrJe65a4f fvvsw2q1ed+sfds543sdwe6+25dbxfder0edsrs aaaaa 55

56 Anulación de Certificados

57 Anulación de Certificados Tienen un periodo de Validez Se puede necesitar anular, Ej: 1. Clave privada comprometida 2. El usuario no sera mas certificado por la CA 3. La CA esta comprometida La CA Mantiene una lista de certificados Anulados Certificate Revocation List (CRL) OCSP Los sistemas deben verificar la CRL 57

58 Certificate Revocation List Certificate Revocation List Los certificados anulados permanecen en la CRL hasta su expiración. 58

59 CRL Lists 59

60 60

61 61

62 Online Certificate Status Protocol (OCSP) Alternativa a los CRL Servicio definido por IETF/PKIX para verificar si un certificado fue anulado o suspendido. Requiere Alta Disponibilidad del Servicio OCSP 62

63 Comparación de CRL y OCSP User Descarga CRL CRL CA Directorio CRL User IDs de los certificados a ser verificados Estado de los certificados OCSP Server Descarga CRL CRL Directorio CA OCSP 63

64 Cadena de Certificacion

65 CA Hierarchy if both users share a common CA then they are assumed to know its public key otherwise CA's must form a hierarchy use certificates linking members of hierarchy to validate other CA's each CA has certificates for clients (forward) and parent (backward) each client trusts parents certificates enable verification of any certificate from one CA by users of all other CAs in hierarchy 65

66 Jerarquía a de certificación CA Raíz Autofirmada CA 1 Sub nivel 1 CA 2 Sub nivel 1 CA 1 Sub nivel 2 CA 2 Sub nivel 2 Cliente Cliente Cliente 66

67 CA Hierarchy Use 67

68 Referencias Public-Key Infrastructure (X.509) (pkix), Internet X.509 Public Key Infrastructure Certificate and CRL Profile (RFC 3280), X.509 Extensions for IP Addresses and AS Identifiers (RFC 3779),

69 Algunos problemas

70 Autenticación de Usuario: Al momento de emitir como se autentica al usuario remoto? Autenticación de CA CRL: Cómo se asegura la distribución de las Root CA? Disponer de las listas CRL a tiempo presenta algunos problemas al escalar. Muchas veces la infraestructura termina funcionando sin un sistema de anulación. Calidad de la Clave de Cifrado de la privada Generalmente no hay manera de garantizar la calidad de la clave con que se cifra la privada Servidores con clave privada en texto claro, o fácil de obtener 70

71 Usos PKI

72 PKI y Algunos estándares y aplicaciones 72

73 Public Key Infrastructure (PKI) Technical Specifications: Part A - Technical Concept of Operations 73

74 Firma Digital

75 Digital Signature Message Message Digest Algorithm Hash Function Digest Algorithm Hash Function Digest Public Key Private Key Encryption Decryption Signature Expected Digest Actual Digest Signer Channel Receiver 75

76 PKCS7 signed data Version (Set of) Digest Algorithms Content type Content Info Content Set of certificates Set of CRLs Signer Info Version Signer ID (issuer and ser. no.) Digest Algorithm Authenticated Attributes Digest Encryption Alg. Encrypted digest (signature) 76

77 Sobre Digital Mensaje Mensaje Cifrado Clave Simétrica Sobre Digital Publica del destino Clave Cifrada 77

78 Sobre Digital Mensaje Cifrado Mensaje Clave Simetrica Sobre Digital Clave Privada Clave Cifrada 78

79 PKCS7 enveloped data Version Originator Info Recipient Info Version Recipient ID (issuer and s.no.) Key Encryption Algorithm Encrypted Key Encrypted Content Info Content type Content Encryption Alg. Encrypted Content 79

80 Fechado de Transacciones Time-Stamping

81 PKI-. Time-Stamping Authority (TSA), Su función es la emisión de los sellos digitales de tiempo -TST- solicitados por los usuarios. Así como la administración y control de la infraestructura de todos los servicios de sellado de tiempo TSS. 81

82 Formato del TST Los datos incorporados en los Sellos Digitales de Tiempo se encuentran firmados electrónicamente. Para la creación de la firma, se utiliza un certificado electrónico emitido para ese único fin, el cual esta sometido a una Política de Certificación específica. Exactitud Los sellos digitales de tiempo TST- se emiten con una exactitud de 1 segundo. Una fuente segura de tiempo sincronizada con la Escala de Tiempo Universal (UTC). El Servicio TimeStamping funciona usando protocolo NTP generalmente a nivel Stratum 1. 82

83 Sellado de Tiempo El usuario envía el valor hash de un documento D; es decir, h(d) a la TSA. El TSA anade el tiempo t, en la forma de fecha y hora de la recepción, -> (h(d), t) La TSA Firma Digitalmente calculando Firma(h(D), t) Envía el Sello Digital de Tiempo al usuario. Se puede verificar el sello y probar que D existía en el tiempo t. 83

84 Tipos de TST TST cliente Emitido a requerimiento de un usuario en apoyo de la generación de una firma electrónica avanzada. TST Servidor Emitido a requerimiento de un equipo informático en apoyo de la generación de una firma electrónica avanzada. TST Auditor Emitido con el fin de atender cualquier otra necesidad que precise demostrar que un dato existió antes de un momento particular. Sistema habitualmente utilizado por clientes. RFC Internet X.509 Public Key Infrastructure Time-Stamp Protocol 84

85 Certificación Cruzada Cross-Certification

86 Una CA emite un certificado para que otra CA pueda crear certificados reconocidos por la primer CA. Puede ser combinado con Jerarquia de CAs 86

87 Cross-Certification and Path Discovery Trusted Root Trusted Root 3 87

88 Las CAs se pueden certificar en forma cruzada Generalmente el atributo crosscerti-ficatepair soporta cadenas de confianza (trust) que van en las dos direcciones. El modelo de confianza pasa a ser entre pares en lugar de originar desde una raiz (root CA). crosscertificatepair Incluye dos certificados. (forward / reverse) El certificado directo es emitido por una CA a la otra CA. El reverso es emitido a la inversa. 88

89 Modelo NIST Arquitectura Federal (USA) 89

90 Argentina

91 Ley Nº Autoridad de Aplicación: Subsecretaría de la Gestión Pública Factura Electronica 91