PKI: infraestructura de clave pública (1/2)

(1)

PKI: infraestructura de clave pública (1/2)

 PKI (Public Key Infrastructure)

 Se define como la infraestructura de red formada por servidores y servicios que en base a claves públicas gestionan de forma segura TODAS las transacciones realizadas

 Se basa en dos operaciones básicas:

 Certificación (medio por el cual las claves se publican)

 Validación, a través de revocación y autentificación

 El modo de realizar estas operaciones define las características de cada PKI.

 Las claves públicas pueden ubicarse en servicios de directorios, en autoridades de certificación, redes de confianza, ...

 Los gobiernos y grandes empresas toman protagonismo en las PKI, dado que requiere una inversión a gran escala, sin embargo

actualmente no hay excesivas iniciativas, sólo en 17 países.

(2)

PKI: infraestructura de clave pública (2/3)

I nfraestructura de clave pública (PKI)

• ^C onsiste en hardware, software, personal, políticas y procedimientos que ayudan a crear, gestionar, distribuir, utilizar, guardar y revocar certificados digitales

• En criptografía, un PKI es un acuerdo que une claves públicas a sus respectivos usuarios utilizando una autoridad CA.

•Un usuario solicita un certificado con su clave pública a una autoridad de registro (RA)

•Esta última confirma la identidad

del usuario a la autoridad de certificación (CA), la cual emite el certificado

• Ahora el usuario puede firmar un contrato digitalmente utilizando su certificado

•Luego el otro individuo comprueba su identidad utilizando una autoridad de validación (VA), la cual a su vez recibe información sobre certificados emitidos de la CA

(3)

PKI: infraestructura de clave pública (3/3)

 Objetivo:

 Dotar a los miembros de una corporación de los mecanismos de autenticación de usuarios, no repudio, integridad de la

información, auditoría, negociación de claves secretas

 Elementos que la componen:

 Certificados digitales (X509) para personas, máquinas, procesos, ...

 Organización jerárquica: bien basadas en CA y RA o bien basada en redes de confianza como PGP

 Directorios de certificados (X.500, LDAP) o repositorios de llaves

 Sistema software de administración de certificados: generación,

revocación de certificados y comprobación a través de lista de

certificados revocados

(4)

Software de la PKI

 Los servicios fundamentales en la PKI son:

 Los servidores web seguros en base a procesos certificados que utilizan SSL (Secure Socket Layer) y X.500/LDAP para consultas.

 Netscape dispone de software para muchos elementos de la PKI:

 Autoridades de Certificación

 Servidores de Directorio

 Software de Cliente

 Microsoft también ;-)

 Correo electrónico seguro con S/MIME, PGP,...

 Fabricantes de PKI: RSA Labs, Verisign GTE Cyber Trust,

Xcert, Netscape,....

(5)

Certificado digital

● Certificado de clave pública o certificado de identidad

● Es un documento electrónico que utiliza una firma digital para unir una clave pública con una entidad:

● Información como el nombre de una persona u organización, su dirección, etc...

● Los certificados digitales funcionan de forma similar a tarjetas de identificación como pasaportes o DNI

● Son emitidos por las autoridades de certificación (CAs) que tienen que validar la identidad del titular de un certificado, antes de emitirlo y cuando está en uso.

● Los certificados se pueden usar para verificar que una clave pública pertenece a un individuo:

● Normalmente en una PKI, la firma será de la autoridad de certificación (CA) ● En una red de confianza, la firma es de:

– Del propio usuario (un certificado firmado por sí mismo) – U otros usuarios ("confirmaciones")

● En cualquier caso, las firmas en los certificados constituyen una garantía por parte de la persona que firma de que la identidad y la clave pública van juntas

● Se pueden crear certificados para servidores basados en Unix con herramientas como

openssl

(6)

Contenidos de un certificado digital X.509 típico

● Número de serie: identificador único para el certificado

● Algoritmo de firma: El algoritmo usado para crear la firma

● Emisor: La entidad que verificó la información y emitió el certificado

● Válido desde: La fecha a partir de la cual el certificado tiene validez.

● Válido hasta: La fecha de caducidad

● Sujeto: La persona o identidad identificada

● Clave pública de sujeto: El propósito de SSL al usarlo con HTTP no es solo encriptar el tráfico sino tambien autenticar al propietario

de la página web.

● Uso de clave: El propósito que tiene la clave pública (ej:cifrado, firma, firmar otros certificados...)

● Firma digital de CA:

● Algoritmo de huella: El algoritmo utilizado para sacar el hash del certificado

● Huella: El hash utilizado para asegurarse de

que no se ha modificado el certificado

(7)

CA (Certificate Authority) y distribución

● Un PKI X.509 típico permite que cada certificado esté firmado solo por una entidad: la autoridad de certificación (CA)

● El certificado de la propia autoridad puede estar a su vez firmado por otra CA, formando una cadena hasta un certificado raíz que está firmado por sí mismo. Este es el certificado root.

● Los certificados ráiz deben de estar disponibles para aquellos que usan un CA de nivel más bajo por lo que se distribuyen ampliamente

● Se distribuyen con navegadores web, clientes de email, etc...

● De esta manera páginas protegidas con SSL/TLS, mensajes de email, etc...

se pueden autenticar sin que los usuarios tengan que instalar certificados raíz manualmente

● Las aplicaciones software normalmente incluyen cientos de certificados raíz

de varios PKIs, los que aseguran a su vez la validez de todos los certificados

de la jerarquía de la cual forman parte.

(8)

Como se crean los certificados

● Generar un par de claves: el solicitante genera un par de claves pública y privada.

● Recopilar la información requerida: el solicitante recopila toda la información que requiere la CA para emitir un certificado.

● Solicitar el certificado: el solicitante envía una solicitud de certificado,consistente de su clave pública e información adicional a la CA.

● La solicitud de certificado, la cual se firma con la clave pública del cliente, también se puede encriptar utilizando la clave pública de la CA.

● Verificar la información: la CA aplica distintas políticas para comprobar si el solicitante debe recibir un certificado.

● Creación del certificado: la CA crea y firma un documento digital que contiene la clave pública del solicitante y el resto de información pertinente.

● La firma de la CA autentica la unión del nombre del sujeto y su clave pública. El documento firmado es el certificado.

● Envío del certificado: la CA envía el certificado al solicitante o lo coloca en un

directorio para que se pueda acceder desde ahí.

(9)

GESTIÓN DE OPENLDAP SEGURA:

Preparar el servidor LDAP indexando índices para optimizarlo:

Parar.el.servidor:/etc/init.d/slapd.stop:

C rea r f i c h ero olc D b I n d ex . l d i f : ge d i t ol c D b I n de x . l di f

dn: olcDatabase={1}hdb,cn=config changetype: modify

add: olcDbIndex

olcDbIndex: cn pres,sub,eq - add: olcDbIndex

olcDbIndex: sn pres,sub,eq - add: olcDbIndex

olcDbIndex: uid pres,sub,eq - add: olcDbIndex

olcDbIndex: displayName pres,sub,eq - add: olcDbIndex

olcDbIndex: default sub - add: olcDbIndex

olcDbIndex: uidNumber eq - add: olcDbIndex

olcDbIndex: gidNumber eq - add: olcDbIndex

olcDbIndex: mail,givenName eq,subinitial - add: olcDbIndex

olcDbIndex: dc eq

# ldapmodify -Y EXTERNAL -H ldapi:/// -f olcDbIndex.ldif

(10)

AUTENTIFICACIÓN SEGURA CON LDAP:

I n s t a la r el pa q u et e open s s l : apt-get install openssl

C rea r u n a en t i d a d c e rt i f i c a d ora : /usr/lib/ssl/misc/CA.pl -newca

C rea u n a pet i c i ón d e f i rm a d e c ert i f i c a d o d e s erv i d or :

openssl req -newkey rsa:1024 -nodes -keyout newreq.pem -out newreq.pem Fi rm a el c ert i f i c a d o c on la en t i d a d c ert i f i c a d ora :

/usr/lib/ssl/misc/CA.sh -sign

C opi a r los c ert i f i c a d o s a la c a rpet a d es ea d a , ren om b ra r y prot eg er:

mkdir /etc/ldap/certs

cp demoCA/cacert.pem /etc/ldap/certs/cacert.pem cp newcert.pem /etc/ldap/certs/servercrt.pem cp newreq.pem /etc/ldap/certs/serverkey.pem chmod 400 /etc/ldap/certs/serverkey.pem

chown -R openldap:openldap /etc/ldap/certs/cacert.pem chown -R openldap:openldap /etc/ldap/certs/servercrt.pem chown -R openldap:openldap /etc/ldap/certs/serverkey.pem

Configurar el servidor slapd para que utilice los certificados en openldapv3(olc):

C rea r a rc h i v o olc S S L . ld i f : dn: cn=config

add: olcTLSCACertificateFile

olcTLSCACertificateFile: /etc/ldap/certs/cacert.pem - add: olcTLSCertificateKeyFile

olcTLSCertificateKeyFile: /etc/ldap/certs/serverkey.pem - add: olcTLSCertificateFile

olcTLSCertificateFile: /etc/ldap/certs/servercrt.pem ldapmodify -Y EXTERNAL -H ldapi:/// -f olcSSL.ldif C on f i g u ra L D A P S en / et c / d ef a u lt / s la pd :

SLAPD_SERVICES="ldap:/// ldaps:/// ldapi:///"

(11)

A ñ a d i m os el u s u a ri o open ld a p a l g ru po d e c ert i f i c a d os s s l - c ert :

#usermod -a -G ssl-cert openldap

P ru eb a s i el s erv er es t á es c u c h a n d o por el pu ert o 6 3 6 : aptitude install gnutls-bin

gnutls-cli-debug -p 636 <fqdn_de_tu_servidorLDAP>

Y a po de m o s e n t r a r c o n P hpl d a pa dmin / J X pl o r e r e n e l s e r v ido r po r e l pue r t o 6 3 6 .

(12)

Aplicaciones y protocolos seguros

 Ofrecen integridad, validación y no repudio

 Los elementos vistos anteriormente, firma y clave pública, están íntimamente relacionados con los siguientes protocolos:

 Utilización de certificados y autoridades de certificación y registro (x.509)

 Servidores de directorios (X.500 y LDAP)

 En correo electrónico, para correo firmado o confidencial (PGP, PEM,S/MIME)

 Infraestructuras de clave pública (PKI Public Key Infraestructure) y tarjetas inteligentes

 Protocolos SSL y TSL: Secure Socket Layer (Transport Secure Layer)

(13)

HTTP FTP

HP

AP CSCP ADP

RP TCP

SSL: Introducción

 Secure Socket Layer (SSL), desarrollado por Netscape en 1995.

 SSL se localiza sobre el nivel de transporte, e independiente del protocolo superior ( interfaz similar a BSD Sockets ). Se puede utilizar con cualquier protocolo: HTTP, FTP, SMTP, etc . Ejemplo: https://correo.uv.es

 SSL cifra los datos intercambiados entre el servidor y el cliente con cifrado simétrico (RC4 o IDEA) y cifrando la clave de sesión mediante un algoritmo de cifrado de clave pública, típicamente el RSA. Antes de establecer la

conexión, pueden pactar o negociar la forma de conectarse de forma segura.

 Comprende los protocolos

 Record Protocol (RP)

 Alert Protocol (AP)

 Handshake Protocol (HP)

 Change Cipher Spec (CCSP)

 Application Data Protocol (ADP) SSL

(14)

SSL/TLS: comentarios

 Cuando el navegador opera en modo de conexión

segura, aparece el dibujo de un candado o llave en la barra inferior.

 Los puertos utilizados son 443 para HTTPS, 465 para SSMTP, 563 para SNEWS, 636 para SS-LDAP, 995 para SPOP3

 SSL protege del ataque de "men in the middle" a través de certificados digitales X.509v3

 SSL reduce las prestaciones de un sistema normal, debido al cifrado en el establecimiento de la conexión

 TLS: Para no vincularse a un fabricante (Netscape), se ha creado una generalización de SSL, llamado Transport Layer Security (TLS). La TSLv1.1 es el RFC-4346 del

IETF (2006), modificación de SSL v3.0

(15)

• Transport Layer Security (TLS)/Secure Sockets Layer (SSL)

o Son protocolos criptográficos que proporcionan seguridad para las comunicaciones a través de internet

o TLS/SSL permiten la autenticación de servidores y clientes, además de encriptar datos y asegurar su integridad en redes como la World Wide Web

o TLS y SSL encriptan la comunicación por encima de la capa de transporte (TCP), usando:

o Criptografía simétrica para privacidad

o Y un código de autenticación para la confiabilidad del mensaje

o El protocolo TLS permite a las aplicaciones cliente/servidor

comunicarse a través de una red evitando que los datos sean

vistos o modificados por terceras personas.

(16)

Handshake

● Un cliente TLS y un servidor negocian una conexión con estado usando el procedimiento de handshake (“apretón de manos”)

● Durante este handshake, el cliente y el servidor se ponen de acuerdo sobre varios parámetros.

● El handshake comienza cuando el cliente se conecta a un servidor con TLS habilitado, solicitando una conexión segura y presentando una lista de

CipherSuites que soporta (cifrados y funciones hash)

● A partir de esta lista el servidor toma el cifrado y función hash más seguros que también soporta él y luego notifica al cliente de su decisión

● El servidor manda al cliente su identificación en forma de un certificado digital:

nombre del servidor, autoridad de certificación (CA) y la clave pública del servidor

● El cliente puede contactar con el servidor que proporciona el certificado (la CA) y confirmar que la validez del certificado antes de continuar

● Para poder generar las claves de sesión utilizadas en la conexión segura, el

cliente encripta un número aleatorio con la clave pública del servidor y manda el resultado a éste. Solo el servidor debería de poder desencriptarlo con su clave privada.

● A partir del número aleatorio, ambas partes generan material encriptado con una

clave simétrica que pueden encriptar y desencriptar.

(17)

Handshake

● Esto finaliza el handshake y comienza la conexión segura, que se encripta/desencripta con criptografía simétrica hasta que se cierre la conexión

● Si alguno de los pasos anteriores falla, el handshake TLS fallará y por lo tanto no se establecerá la conexión.

● El sistema de cifrado de clave pública se usa solo para el handshake y el intercambio de clave simétrica.

● Una vez que se haya hecho el intercambio, las claves simétricas se utilizan para encriptar la comunicación entre cliente y servidor

● Esto se hace así porque los sistemas de cifrado de clave pública utilizan muchos recursos computaciones, por lo que se intenta minimizar su uso.

● TLS se puede usar con cualquier aplicación cliente-servidor, pero el uso más típico es con HTTP.

● De hecho, lo que conocemos por HTTPS es simplemente HTTP con TLS (o SSL)

● Mientras que el puerto TCP para HTTP es 80 para HTTPS usa el puerto 443

● Ya que TLS/SSL se implementa por debajo de la capa de aplicación, la mayoría de sus

operaciones no son visibles al cliente.

(18)

Usos frecuentes de TLS/SSL

● Mucha gente piensa que TLS y SSL son protocolos utilizados solamente en navegadores web. Sin embargo, son protocolos de propósito general que

se pueden utilizar siempre que sea necesario autenticar y proteger datos.

● Por ejemplo, se puede TLS/SSL para:

● Transacciones seguras SSL en una página de comercio electrónico

● Autenticación de un cliente en una página web que usa SSL

● Acceso remoto

● Acceso SQL

● E-mail

● Esta no es una lista exhaustiva. Es más, al poder acceder a estos protocolos a través de una interfaz (Security Service Provider Interface), es posible usarlos para cualquier tipo de aplicación.

● Muchas aplicaciones antiguas se modifican para aprovechar las ventajas de

TLS/SSL

(19)

SSH Datos: Ficheros de Configuración

Elección de clave de autenticación:

• RSA es por defecto y normalmente es la mejor opción.

Los archivos importantes son:

/etc/ssh/ssh_config /etc/ssh/sshd_config

~/.ssh/identity and identity.pub

~/.ssh/id_dsa and id_dsa.pub

~/.ssh/id rsa and id rsa.pub

-/.ssh/known_hosts and known_hosts2

~/.ssh/authorized_keys and authorized_keys2

(20)

Intercambiando Claves

Conectando por primera vez con ssh:

[hervey@localhost .ssh]$ ssh root@localhost

The authenticity of host 'localhost (127.0.0.1)' can't be established.

RSA key fingerprint is 66:3c:ab:30:3c:be:5b:28:43:f2:e0:5c:6c:af:c0:d3.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'localhost' (RSA) to the list of known hosts.

root@localhost's password:

Last login: Tue Mar 2 22:55:33 2004 from localhost.localdomain

En este punto el cliente tiene en el archivo ~/.ssh/known_hosts el contenido del archivo /etc/ssh/ssh_host_rsa_key.pub del otro pc.

Próxima conexión:

[hervey@localhost .ssh]$ ssh root@localhost root@localhost's password:

Last login: Tue Mar 2 22:56:01 2004 from localhost.localdomain

(21)

Intercambiando Llaves

Comando Tipo de Llave Generadora Archivo Público

ssh-keygen RSA (SSH protocol 1) identity.pub ssh-keygen -t rsa RSA (SSH protocol 2) id_rsa.pub ssh-keygen -t dsa DSA (SSH protocol 2) id_dsa.pub

• Tamano por defecto de la llave/clave es 1024 bits.

• Archivos publicos son de texto.

• Archivos privados estan cifrados.

Los archivos que se corresponden al intercambio de llaves del host son:

RSA/DSA (SSH Protocolo 2) ==> known_hosts (known_hosts2)

RSA (SSH Protocolo 1) ==> known_hosts

(22)

Intercambiando Claves

¿Cómo decide SSH qué archivos se van a comparar?

Mira en /etc/sshd_config. Para OpenSSH version 2 y 3 el servidor usa protocolo 2 y después 1 por defecto.

Por defecto los clientes de OpenSSH version 2 se conectan en este orden:

• RSA version 2

• DSA version 2

Presta atencion a la configuracion de "HostKeyAlgorithms" /etc/ssh/ssh_config

que determina el orden. Se pueden usar parámetros en el comando de ssh

para ignorar esta configuración.

(23)

Lab de SSH

• Generación de Llaves rsa1/rsa2/dsa

Ahora vamos a generar una sola llave del protocolo RSA para SSH de 2048 bits. Para hacer esto, ejecuta el siguiente comando.

ssh-keygen -t rsa -b 2048

Antes de continuar tal vez tendras que editar /etc/ssh/ssh_config

y asegurar que la opcion de "Protocol" esta puesta a "Protocol

2,1" o "Protocol 2"

(24)

Lab de SSH cont.

• Generacion de llave de RSA2

La salida del comando "ssh-keygen -t rsa -b 2048":

[hervey@localhost .ssh]$ ssh-keygen -t rsa -b 2048 Generating public/private rsa key pair.

Enter file in which to save the key (/home/hervey/.ssh/id_rsa): [enter]

Enter passphrase (empty for no passphrase): [pw]

Enter same passphrase again: [pw]

Your identification has been saved in/home/hervey/.ssh/id_rsa Your public key has been saved in /home/hervey/.ssh/id_rsa.pub.

The key fingerprint is: f1:4f:cb:cd:c2:62:d7:ab:e7:a1:17:5e:4e:4c:e8:54

(25)

Lab de SSH cont.

• Copiando Clave Pública

Ahora que tenemos un par de llaves (pública y privada) vamos a copiar la clave pública al ordenador donde conectamos inicialmente para grabar esta clave en el archivo.

PKI: infraestructura de clave pública (1/2)