PDF de programación - II55 - Seguridad y Protección de la Información - Ingeniería Superior en Informática

Apuntes

Ingeniería Superior en Informática

II55 - Seguridad y Protección de la Información II

Fernando Marco Sales

6 de mayo de 2008

1

ÍNDICE

Índice

1. Infraestructuras de clave pública

1.1. Funciones Hash. Tipos y funciones
. . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Repaso del modelo x509 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Autoridades de certificación x509 . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1. Declaración de prácticas de certificación (CPS)
. . . . . . . . . . . . . .
1.3.2. Tipos de certificados habituales . . . . . . . . . . . . . . . . . . . . . . .
1.3.3. Modelos de expedición de certificados . . . . . . . . . . . . . . . . . . .

3
3
6
7
7
7
8
. . . . . . . . . . . . . . . . . . . . . . . . 10

2

1.4. Dispositivos criptográficos. El clauer

2. Librerías y arquitecturas criptográficas

11
2.1. OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1. Openssl desde la línea de comandos
. . . . . . . . . . . . . . . . . . . . 11
2.1.2. Programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2. CrytoAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2. CSP y Certificate Store Provider . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3. Capicom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3. Pkcs11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3. Protocolos criptográficos

18
3.1. Firma ciega de Chaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Lanzar una moneda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3. Compartición de secretos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4. Dinero electrónico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5. Voto telemático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6. Voto electrónico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7. Firma digital en la práctica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4. Anexo A: Generación de números aleatorios

27

5. Anexo B: Generación de números primos y Aritmética modular

28
5.1. Aritmética modular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. Generación de números primos . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1 INFRAESTRUCTURAS DE CLAVE PÚBLICA

3

1.

Infraestructuras de clave pública

1.1. Funciones Hash. Tipos y funciones

Hay diferentes tipos de funciones Hash, entre las que tenemos:

md5: 128 bits

sha1: 160 bits

sha2: 256 bits

Algunas características de éste tipo de funciones son:

Dados 2 mensajes distintos, en la práctica nunca tendrán el mismo Hash

De un Hash, es imposible sacar el mensaje

Este tipo de funciones son las que su utilizan a la hora de firmar los documentos y poste-
riormente comprobar que no estan corruptos por cualquier motivo. Esto lo podemos hacer
calculando el md5 de un mensaje y cifrándolo con KA, más tarde para comprobar que el do-
cumento no está corrupto calculamos el md5 del mensaje y comprobamos que es igual al que
el documento lleva cifrado, si es así podemos tener la certeza de que el documento esta bien
(ver. figura 1).

Figura 1: Firma de un documento

En cambio para cifrar se creo una llave única de sesión. Con esta llave ciframos el mensaje.
Despues enviamos la llave de sesión cifrada con PB junto con el mensaje cifrado (ver. figura 2).
Ademas de todo sabemos que si tenemos un mismo mensaje, podemos generar 2 mensajes
distintos y conseguir que tengan el mismo Hash. Mas tarde si pegamos un mismo mensaje en
ambos seguiran teniendo el mismo Hash (ver. figura 3) . Por lo tanto sabiendo esta vulnera-
bilidad del md5 y del sha1, hoy en día a la hora de firmar lo que se hace es calcular el md5,
despues el sha1 y por último juntar ambos resultados.

Pero en lo referido a la firma, hay un factor que también nos afecta como es la confianza.

Algunos aspectos que tendremos que tener en cuenta son los siguientes:

1 INFRAESTRUCTURAS DE CLAVE PÚBLICA

4

Figura 2: Cifrado de un documento

Figura 3: Propiedades del Hash

La confianza en el Software instalado, ya que hoy en día muchos de ellos contienen
Spyware

La confianza en el equipo que utilizaremos el Software

La confianza en la llave pública. El saber que una llave es de un persona, no nos lo dice
ningún programa, sino que es todo por confianza, directa o indirecta.

• Directa: El propietario te da su llave pública
• Autoadquirida: Un ejemplo es con ssh, ya que tu aceptas la primera vez la llave
y despues conforme interactuas conla máquina te cercioras de que realmente es
quien tu creias que era.

Además tenemos 2 tipos de modelos de confianza, que son:

1 INFRAESTRUCTURAS DE CLAVE PÚBLICA

5

Horizontal:
Todos los usuarios estan en el mismo nivel. Se rige por la regla: ”Los amigos de mis
amigos, son mis amigos”. Estos sistemas requieren de usuarios expertos, para que sepan
adaptar niveles de confianza.

Vertical:
No requieren de usuarios expertos. Estos sistemas requieren de TDC(Terceros de con-
fianza). Este es aquel en que todos confian en una tercera persona, como por ejemplo
las CA’s.

Por lo tanto cuando me hago un certificado, tengo que confiar que la CA, hace su trabajo

correctamente y que he obtenido su llave pública de una forma segura.

1 INFRAESTRUCTURAS DE CLAVE PÚBLICA

6

1.2. Repaso del modelo x509

Este modelo nos dice como tiene que ser el certificado y la CRL. Los campos de los que se

compone son:

Issuer y Subject = DN(Distinguished Name)

• CN(Common Name)
• O(Organization)
• OU(Organizational Unit)
• L(Location)
• ST(State)
• C(Country)
Número de serie

CA emisora

Fecha inicio - fecha fin

Versión

Extensiones

Algoritmo utilizado

Llave pública

Firma del certificado

Proposito del certificado

La sintaxis del X509 se define mediante el lenguaje ASN1(para su estructura) y los forma-
tos de codificación más comunes son el DER o el PEM. Según la notación ASN1 un certificado
se puede agrupar en 3 grandes grupos como son:

1. El primer grupo contiene los datos que identifican a la persona propietaria del certifica-
do(CN, O, OU, L, ST y C), además de el no de serie, el tiempo de validez, la CA emisora,
...

2. Consta de dos campos para almacenar la llave pública, en el primero de ellos nos dice el
algoritmo utilizado para la generación de la llave y el segundo contiene la llave pública

3. Este grupo contiene 3 atributos como son el algoritmo de firma utilizado, el hash de la

firma y la propia firma digital

1 INFRAESTRUCTURAS DE CLAVE PÚBLICA

7

Una cosa que no especifican es el contenido obligatorio de extensiones, por lo que se uti-
liza para poder meter toda aquella información que no se recoge en los demás campos(por
ejemplo, el DNI en españa). El problema que genera este campo extensiones, es el necesitar
para cada tipo de certificado su SW correspondiente, ya que al poder variar este campo, no
existe ningún SW que los reconozca todos. Como en todo, existe siempre la posibilidad de que
perdamos el certificado, nos lo roben, etc ..., es por ello que el modelo X509, obliga a todas las
CA, a que tengan una CRL (Certificate Revocation List). La CRL, es un documento firmado por
la propia CA, en el cual aparecen todos los números de serie de los certificados que han sido
rebocados, el cual podremos utilizar para comprobar la validez del certificado que esten usan-
do. Pero este método es un poco farragoso, ya que tienes que descargarte siempre la CRL de la
página de la CA, para poder realizar las comprobaciones oportunas, es por eso que se invento
el OCSP (Online Certificate Status Protocol), que es un método para comprobar la validez de
los certificados vía web.

Anteriormente hemos comentado que los certificados pueden ser rebocados por los titu-
lares de los mismos en cualquier momento, pero no hemos comentado nada de los posibles
hechos por los que se permite la rebocación del mismo. Algunos de los motivos admitidos para
la rebocacion de los certificados son:

Perdida del certificado

Robo del certificado

Voluntad del usuario (raro pero cierto)

1.3. Autoridades de certificación x509
1.3.1. Declaración de prácticas de certificación (CPS)

El CSP (Certificate Practice Statement), es un documento obligatorio que toda CA debe te-
ner. En el viene recogida toda la política que sigue esta CA, los procedimientos que utiliza para
otorgar los certificados, etc... Este documento viene auditado por una autoridad competente
para ello, la cual nos da seguridad de que dicha CA cumple a la perfección su CSP. Hoy en día
este tipo de documentos son auditados por el WebTrust CA.

1.3.2. Tipos de certificados habituales

En el mundo de los certificados digitales, existen mas tipos aparte del certificado personal,

que vemos en clase, algunos de estos tipos son:

Certificado de pertenencia a empresa:
Acredita tanto la identidad personal del titular como su vinculación con la entidad para
la cual trabaja

1 INFRAESTRUCTURAS DE CLAVE PÚBLICA

8

Certificado de representante:
Idéntico que el anterior, pero además acredita los poderes del titular dentro de la em-
presa

Certificado de persona jurídica:
Identifica a una empresa o organización, como tal a la hora de hacer trámites ante las
administraciones o instituciones

Certificado de servidor seguro:
Se utiliza en los servidores que quieren proteger contra terceros el intercambio de infor-
macion con los usuarios

Certificado de firma de código:
Para garantizar la autoría y la no modificación del código de aplicaciones informáticas

1.3.3. Modelos de expedición de certificados

Generalitat Valenciana

Tiene dos tipos, uno de ellos es el soft, que guarda la llave en algu