TEMA 2 - parte 3.Gestión de Claves

Transcripción

1 TEMA 2 - parte 3.Gestión de Claves SEGURIDAD EN SISTEMAS DE INFORMACIÓN Libre Elección 1 de marzo de 2011 FJRP, FMBR 2010 ccia SSI

2 1. Gestion de claves Dos aspectos dentro de la Gestión de claves: Utilización de cifrado de clave pública para distribuir claves secretas. Distribución de las claves públicas 1.1 Distribución de claves secretas mediante cifrado asimétrico Distintos formas de usar algoritmos asimétricos para intercambio de claves secretas. Opción 1: envío de claves secretas cifradas con clave pública del destinatario (cifrado con RSA) Ejemplos: Formato de mensaje de PGP (Pretty Good Privacy) Cuerpo del mensaje cifrado con un algoritmo asimétrico usando una clave secreta de un sólo uso Clave secreta se cifra con clave pública del destinatario y se envía incluida en el mensaje PGP Adicionalmente, se puede firmar el mensaje con clave privada de firma del emisor Negociación de la clave maestra en SSL/TLS (Secure Socket Layer / Transport Layer Security) Durante la fase de establecimiento de conexión, Servidor se autentica ante el Cliente con un certificado digital aceptado (opcionalmente, también el Cliente) que incluye su clave pública. Usando esa clave, el Cliente envía al Servidor la clave maestra cifrada con RSA. A partir de la clave maestra Cliente y Servidor generarán las claves de cifrado y atenticación a usar en los mensajes intercambiados una vez establecida la conexión. Opción 2: algoritmos asimétricos específicos para intercambio de claves (algoritmo de intercambio de claves de Diffie-Hellman)

3 Intercambio de claves Diffie-Hellman (DH) Primer uso práctico del cifrado asimétrico. Ejemplos de uso: Negociación de claves en IPSec (protocolo IKE (Internet Key Exchange)) Negociación de la clave maestra en SSL/TLS Logaritmos discretos Función one-way sobre la que se fundamenta DH (también ElGamal) Generalización del logaritmo en aritmética modular. Definición: c log b (a) (mod N) si y sólo si a b c (mod N) Se trata de encontrar el exponente c al que habría que elevar la base b para obtener el valor a Factible calcular (b c mod N) Computacionalmente impracticable (log b (a) mod N)) (para valores grandes de p y g) Funcionamiento intercambio de clave Diffie-Hellman A y B quieren intercambiar/acordar una clave secreta. 1. A y B acuerdan (parte pública) j un n o primo grande p n o entero g primo relativo con p 2. A selecciona un n o entero aleatorio grande x (parte privada) Calcula X = (g x mod p) y se lo envía a B. 3. B selecciona un n o entero aleatorio grande y (parte privada) Calcula Y = (g y mod p) y se lo envía a A. 4. A calcula K = (Y x mod p) 5. B calcula K = (X y mod p) Se verifica que K K (mod p) K = (Y x mod p) = ((g y mod p) x mod p) = = (g y x mod p) = (g x y mod p) = = ((g x mod p) y mod p) = (X y mod p) = K (1) K será la clave simétrica acordada (secreto compartido) K nunca viaja por la red Un atacante sólo tiene acceso a X, Y, p y g. j x = logg (X) mod p Para conocer K debe encontrar valores x e y que verifiquen y = log g (Y) mod p que es computacionalmente impractiable para valores grandes de p y g.

4 2. Distribución de claves públicas Punto clave métodos asimétricos: distribución fiable de claves públicas En teoría se asume que es trivial mantener en secreto las claves privadas. Se necesita disponer de KU (clave pública) del otro extremo para cifrar y validar firmas. Problema: suplantación de la clave pública de un usuario invalida el uso del cifrado asimétrico en cifrado y firma digital. Las aplicaciones del cifrado asimétrico exigen confianza en la autenticidad de las claves públicas utilizadas: Al enviar texto cifrado se confía en que la KU usada para cifrar es realmente la del destinatario Al recibir un mensaje cifrado se confía en que la KU usada para validarlo es realmente la del destinatario Si un atacante hace pasar como legítima una clave pública suplantada tendrá acceso al tráfico cifrado y podrá crear firmas que pasarán por válidas. (a) Distribución de claves públicas a pequeña escala Anuncio público. Directorio disponible públicamente. Autoridad de clave pública. (b) Esquemas reales para distribución de claves públicas Certificados digitales + infraestructuras de clave pública (PKI)

5 2.2.1 Anuncio público de las claves públicas. Idea base: cualquier participante puede enviar su clave pública a cualquier otro, hacer un broadcast a todos los interesados o publicarla en una página WEB, FTP, etc. Punto débil: cualquiera puede falsificar ese anuncio público Un atacante puede afirmar ser A y hacer pública su supuesta clave pública KU A Hasta que A descubre esa falsificación y alerta a los otros participantes: falsificador puede leer todos los mensajes destinados para A fasilficador puede usar la clave falsificada para autentificación y firma falsa j PGP (Pretty Good Privacy) Ejemplo: Intercambio de claves manual en gnu-pg (gnu Privacy Guard) Directorio disponible públicamente Idea base: Más comodidad y mayor grado de seguridad manteniendo un directorio público que contenga las claves públicas. El mantenimiento, gestión y distribución del directorio sería responsabilidad de alguna entidad u organización en la que todos los participantes confían. Idea de Funcionamiento: 1. Una autoridad centralizada mantiene un directorio con un par {nombre,clave pública} para cada participante. 2. Cada participante registra su clave pública (KU A ) en el directorio de la autoridad. Registro en persona o por alguna forma segura de comunicación autentificada. 3. Un participante podría reemplazar su clave por otra (ha utilizado demasiado tiempo su clave pública, la clave privada se ha visto comprometida, etc) 4. Periódicamente, la autoridad publica el directorio completo o sus actualizaciones. 5. Participantes pueden consultar el directorio electrónicamente Idealmente, empleando algún mecanismo de autenticación de las comunicaciones desde la autoridad al participante [ver siguiente esquema]. Ejemplo: Servidores de claves (key servers) en PGP / gnu-pg. Vulnerabilidad: Atacante consigue hacerse pasar por la autoridad de directorio (suplantación) Reemplaza al directorio legítimo y duplica el mecanismo de autentificación que usa Atacante puede falsificar claves públicas

6 2.2.3 Autoridad de clave pública. Idea base: (mejora del esquema anterior) mayor seguridad en la distribución de las claves públicas incluyendo mecanismos que garanticen la autenticidad de la información proporcionada por el directorio de clave pública (firma digital) Una autoridad central mantiene un directorio de las claves públicas de todos los participantes. Cada participante conoce fiablemente la clave pública de la autoridad. Autoridad de clave pública firma las respuestas a las consultas recibidas usando su clave privada. Posible esquema de funcionamiento: 1. A envía un mensaje con un timestamp (momento) a la autoridad pidiendo la clave pública actual de B. 2. La autoridad responde con un mensaje firmado con su clave privada A está seguro de que el mensaje se ha originado en la entidad autorizada El mensaje incluye: 8 >< >: - Clave pública de» B (KU B ) A podrá comprobar que es - Petición original respuesta a una petición suya - Timestamp original 3. A almacena la KU B y la utiliza para cifrar un mensaje para B Ese mensaje contiene: j» A podrá verificar que no es un mensaje viejo de la autoridad con una KU B antigua - Identificador de A - Momento (N 1 ) [identifica unívocamente esta transacción] 4. B obtiene la clave pública de A (KU A ) de la misma manera (2 mensajes) 5. B envía un mensaje a A cifrado con KU A Ese mensaje contiene: j - momento N1 - nuevo momento N 2 [generado por B] Sólo B pudo haber descifrado el mensaje del paso 3 Presencia de momento N 1 garantiza a A que es respuesta de B a su petición del paso 3 6. A devuelve el segundo momento N 2, cifrado con la clave pública de B B está seguro de que A recibió su respuesta. Se intercambian en total 7 mensajes. Los 4 iniciales (para consultar las claves públicas) no son frecuentes a partir de ahora A y B tienen las respectivas claves públicas del otro periódicamente un usuario podría obtener una copia nueva de la clave pública del destino para asegurar que la clave esté actualizada.

7 2.3 Certificados de clave pública Inconvenientes aproximación anterior: Dificulta interoperabilidad: depende de la existenca de una autoridad global común Escasa escalabilidad: autoridad clave pública única potencial cuello de botella No útil en aplicaciones a gran escala Cada usuario tiene que consultar con la autoridad de clave pública si necesita la KU de cualquier posible destino El directorio de nombres y claves públicas que mantiene la autoridad sigue siendo vulnerable a la manipulación. Aproximación alternativa: Uso de certificados digitales avalados por un tercero de confianza. Cada particiante dispone de un certificado de clave pública emitido por una autoridad reconocida que acredita la autenticidad de su KU y que puede distribuir a los demás participantes. Se evita tráfico de peticiones a la entidad certificadora (intercambio de claves no precisará de contactar constantemente con la autoridad de clave pública) Emisor podrá solicitar al destinatario su certificado digital Dispondrá una clave pública del destino avalada por la entidad certificadora (en la que el emisor confía), con un tiempo de vida limitado y que guarda en local La comunicación con la entidad certificadora central se limita a la obtención periódica de certificados caducados o a la consulta de certificados revocados. Funcionamiento: Una autoridad certificadora (C.A.) crea un certificado de clave pública para cada participante que se lo requiera Es un documento digital que contiene: Identificación del participante Clave pública del participante Info. adicional: periodo de validez, usos previstos, etc Toda esa información está firmada digitalmente por la C.A. (con su clave privada KR CA ) Solicitud en persona o por una comunicación autentificada segura

8 Un participante podrá distribuir su clave pública a quien desee, enviándole su propio certificado La C.A. garantiza que la clave publica pertenece al usuario identificado en el certificado C.A. se responsabiliza de comprobar la autenticiadad de esas KU Sólo la C.A. puede crear y modificar los certificados El participante destino puede verificar que el certificado es auténtico Fué creado y firmado por la autoridad certificadora correspondiente (reconocida por ambos). Puede recuperar la clave pública y comprobar su validez, comprobando la firma digital con la clave pública de la C.A. Cada certificado incluye un timestamp T que valida la vigencia del mismo. Requisitos generales 1. Contenido típico de los certificados Identificación del usuario: nombre, etc Valor de la clave publica de ese usuario Opcionalmente: periodo de validez Firma de las partes anteriores por la C.A. (con su KU CA ) 2. Cualquier participante podrá leer un certificado para ver el nombre y la clave pública del propietario del certificado. 3. Cualquier participante podrá verificar que el certificado originado por la entidad certificadora no es una falsificación. 4. Solo la autoridad certificadora puede crear y actualizar certificados. 5. Cualquier participante puede verificar la vigencia de un certificado. Esquema:

9 Formatos de certificados El formato de certificado más usado es el de los certificados X.509. Especificado en la definicion del servicio de directorio X.500 Define un contenedor par la info. de los certificados independiente de los algoritmos de cifrado. Estructura y campos:

10 Certificado de servidor (emitido y firmado por una Autoridad de Certificacion [CA]) openssl x509 -text -in mancomun.org.pem Certificate: Data: Version: 3 (0x2) Serial Number: (0x3cba25dd) Signature Algorithm: sha1withrsaencryption Issuer: C=ES, O=FNMT, OU=FNMT Clase 2 CA Validity Not Before: Mar 15 16:16: GMT Not After : Mar 15 16:16: GMT Subject: C=ES, O=FNMT, OU=FNMT Clase 2 CA, OU=publicos, OU= , CN=*.mancom Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:df:7a:37:12:8b:ce:7a:d4:ca:f9:bc:a8:26:bf: 27:66:df:ce:cf:8e:df:94:0d:05:52:5d:a4:aa:7e:... 35:e5:6b:9c:cb:c7:8f:ac:11 Exponent: (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: DirName:/ =S H/ =Xunta de G X509v3 Basic Constraints: CA:FALSE X509v3 CRL Distribution Points: DirName:/C=ES/O=FNMT/OU=FNMT Clase 2 CA/CN=CRL Signature Algorithm: sha1withrsaencryption 6d:7d:c2:67:cd:5c:36:28:ab:6f:71:14:03:66:79:25:d8:55: 31:62:29:7f:6e:f4:cd:3a:30:a9:2f:e7:e4:08:8e:e8:b3:ad:... cb:af

11 Certificado autofirmado (Autoridad de Certificacion RAIZ) openssl x509 -text -in FNMTClase2CA-FNMT.pem Certificate: Data: Version: 3 (0x2) Serial Number: (0x36f11b19) Signature Algorithm: sha1withrsaencryption Issuer: C=ES, O=FNMT, OU=FNMT Clase 2 CA Validity Not Before: Mar 18 14:56: GMT Not After : Mar 18 15:26: GMT Subject: C=ES, O=FNMT, OU=FNMT Clase 2 CA Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:98:3f:ad:19:36:93:3d:3e:fe:76:42:14:fd:35: 6f:f1:fa:ad:22:7a:58:e3:46:d0:5d:c6:5a:f9:62:... e2:ff:19:f4:94:09:d5:96:61 Exponent: 3 (0x3) X509v3 extensions: Netscape Cert Type: SSL CA, S/MIME CA, Object Signing CA X509v3 CRL Distribution Points: DirName:/C=ES/O=FNMT/OU=FNMT Clase 2 CA/CN=CRL1 X509v3 Basic Constraints: CA:TRUE... Signature Algorithm: sha1withrsaencryption 61:4c:a0:7c:59:63:5b:66:f8:ee:65:13:ce:43:80:47:b9:b2: 35:c9:c8:84:c7:6b:73:60:45:e4:9d:37:9d:f5:8e:25:b9:f9:... 08:5d <<-- Emisor (C.A.) <<-- Id. due~no de KU (C.A.) <<-- Valor de la KU <<-- Opcional <<-- Firma del certificado

12 Cadenas de certificados y jerarquías de C.A. Problema: comunicación con un usuario que tiene un certificado emitido por un C.A. no conocido. No es posible comprobar su validez, se deconoce KU del nuevo CA No hay confianza en el nuevo CA (nadie lo respalda) Solucion: Exigir que la nueva CA tenga un certificado que garantice la autenticidad de su clave publica Ese certificado estara firmado por otra CA en la que confiemos Puede establecerse una jerarquía de CAs Las CA de más bajo nivel certifican usuarios Las CA de cada nivel son certificadas por una de nivel superior Para verificar una clave publica puede ser necesario que el ususario envie, ademas de su certificado, el certificado de la CA que lo ha emitido El certificado de esa CA estará certificado por otra CA y asi hasta llegar a una CA raiz reconocida. Esto se denomina cadena de certificados

13 Listas de revocación de certificados CRL) La recomendacion X.509 define otra estructura que debe gestiona la C.A.: lista de revocacion de certificados (CRL) Sirve para publicar los certificados que han dejado de ser validos antes de su caducidad Motivos: otro certificado sustiuye al revocado, cambio/desaparicion de ese usuario, clave privada del usuario comprometida,... Para enviar un mensaje a otro usuario no basta sólo con verificar la firma de la CA en su certificado Es necesario obtener la CRL actual de nuestro C.A. y comprobar que el certificado no esta en ella Los CA hacen publica su lista CRL periodicamente Los usuarios informan de sus peticiones de revocacion por un procedimiento seguro y autentificado CA hace publica la CRL con los certificados revocados no caducados Cuando un certificado revocado alcanza su fecha de caducidad no es necesario incluirlo en la CRL