seguridad en el correo electrónicodi002.edv.uniovi.es/~fcano/sr/transparencias/... ·...

Post on 18-Jul-2020

18 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Seguridad en el Correo ElectrónicoFundamentos de SR. Aplicaciones y Estándares (William Stallings)

Fernando Cano Espinosa

Abril de 2010

0-0

Seguridad en el Correo Electrónico

PGP

S/MIME

1

PGP (Pretty Good Privacy)

1. Desarrollado por Phiplip Zimmermann

2. Gratuito para Windows, Unix y Mac

3. Utiliza los algoritmos más seguros:

Cifrado asimétrico: RSA, DSS y Diffie-Hellman

Cifrado simétrico: CAST-128, IDEA y 3DES

Hash: SHA-1

4. No está controlado por ningúna organización gubernamental

5. Es un estandar recogido en la RFC 3156

2

PGP: Servicios

1. Autenticación: firma digital

2. Confidencialidad: cifrado simétrico y asimétrico

3. Compresión: zip

4. Compatibilidad : radix 64

5. Segmentación

3

Autenticación PGP

4

Confidencialidad PGP

]

5

Autenticación y Confidencialidad PGP

���������������������������

���������������������������������

������������������������������������

����������������������������������������������������

KR a

MZ EC

K s EP

KU b KU b[K ] sE

DP

DC

KR b

K s

Z−1

M

M

DP

KU a

H

KR a[H(M)]E

H EP

Comparar

]

6

Compresión

Se comprimedespués de firmar. Así no hace falta guardar una

versión comprimida del mensaje para poder validar la firma.

Se comprimeantes de cifrar: Se refuerza la seguridad criptográfica

7

Compatibilidad: radix 64

Objetivo: realizar una conversión de una cadena binaria en una serie

de caracteres imprimibles.

Los 65 caracteres son: [A-Za-z0-9], ’+’, ’/’ y el ’=’

El ’=’ se usa de relleno

Cada 6 bits se convierten en un códifo ASCII de 8 bits. Ejemplo

1. 000000 → 0 → A → 65(01000001)

2. 100110 → 38 → m → 109(01101101)

3. 001000110101110010010001 → I1yR

8

Segmentación y reensamblado

Si los mensajes son demasiado largos se trocean y en la recepción se

reensamblan

9

Gestión de claves: tipos

Clave simétricas de sesión de un solo uso

Clave públicas (asimétricas)

Clave privadas (asimétricas)

Frases clave (simétricas)

10

Gestión de claves: identificadores

Permiten determinar qué clave hay que utilizar para descifrar

Con unIDUser y un IDKey debe ser suficiente para determinar una

clave

El IDKey se calcula obteniendo los últimos 64 bits de la clave pública

(KUa mod 264)

El identificador de firma digital sigue el mismo criterio

11

Componentes de un mensaje

1. Componente mensaje

2. Componente firma (opcional)

3. Componente clave sesión (opcional)

12

El componente mensaje

Incluye:

1. Datos que se van a transmitir

2. Nombre de archivo

3. Sello de tiempo (de cuando fue creado)

13

El componente firma

Incluye:

1. Sello de tiempo (cuando se firmó)

2. Resumen (SHA-1 de 160 bits) cifrado con laKRemisor se calcula

con el sello de tiempo para evitar repeticiones.

3. Dos octetos iniciales del resumen: para permitir que el receptor

determine si se usó la clave pública correcta.

4. IdKeyde la clave pública del emisor.

5. Este componente y el anterior (componente de mensaje) pueden

comprimirse y cifrarse mediante una clave de sesión.

14

El componente clave sesión

Incluye:

1. La clave de sesión cifrada

2. IdKeyde la clave pública que utilizó el emisor para cifrar la clavede

sesión.

15

Gestión de claves: ficheros

Fichero (anillo) de claves públicas

(∼/.pgp/pubring.pkr,∼/.gnupg/pubring.gpg)

Fichero (anillo) de claves privadas

(∼/.pgp/secring.pkr,∼/.gnupg/secring.gpg)

16

Gestión de claves: Fichero de Claves Privadas

Campos

Sello de tiempo

Identificador de clave: 64 bits menos significativos de la clave

pública.

Clave pública

Clave privada: se cifra en símétrico utilizando como clave un SHA-1

de lafrase de paso(frase clave)

Identificador de usuario

17

Gestión de claves: Fichero de Claves Públicas

Campos

Sello de tiempo

Identificador de clave:64 bits menos significaticvos de la clave

pública.

Clave pública

Confianza en el dueño

Identificador de usuario

Legitimidad de la clave

Firmas

Confianza en la firma

18

Confianza en las claves públicas

El campolegitimidad de la clavelo calcula PGP y mide la confianza

que se tiende de la validez de esa clave.

CadaKU tiene a sociadas cero o más firmas con la confianza que

PGP tiene de cada firma. PGP calcula la legitimidad de la clavea

partir de la confianza .

El campo confianza en el dueñoindica la confianza en esa clave

para firmar otros certificados. Este valor lo asigna el usuario.

19

S/MIME

Secure / Multipurpose Interner Mail Extension

Correo electrónico: RFC 822

Documentos MIME: RFC 2045→ RFC 2049

Documentos S/MIME: RFC 2630, RFC 2632 y RFC 2633

Versión española: http://www.rfc-es.org/rfc/rfc2045-es.txt

20

S/MIME

RFC 2045: define el formato del cuerpo de los mensajes MIME

RFC 2046: define la estructura general del sistema de identificación

de contenido MIME y define un conjunto inicial de tipos de

contenido.

RFC 2047, describe extensiones a RFC 822 para permitir

información de texto en los campos de la cabecera de correo Internet

en otro conjunto de caracteres distinto al US-ASCII.

RFC 2048, especifica varios procedimientos para registrar programas

o módulos para MIME.

RFC 2049, describe los criterios de evaluación de cumplimiento de

MIME, y muestra ejemplos ilustrativos de formatos de mensaje

MIME

21

MIME (rtf2045)

Mime redefine el formato de los mensajes para permitir:

cuerpos de los mensajes de texto en otros conjuntos de caracteres

diferentes al US-ASCII

un conjunto ampliable de diferentes formatos para cuerpos de

mensajes no de texto.

cuerpos de mensajes multi-parte, y

información de texto en la cabecera en juegos de caracteres diferentes

al US-ASCII

22

MIME (rtf2045)

Mime incluye los siguientes elementos (compatibles con RFC822):

Cinco nuevos campos de cabecera del mensaje que aportan

información sobre el cuerpo del mensaje

Se definen una serie de formatos de contenido

Se define formatos de codificación y conversiones de formato para

ser transmitidos en distintos sistema de correo.

23

MIME: Campos Cabecera

1. MIME-Version : por defecto 1.0

2. Content-Type: especifica tipo y subtipo del conteniod del cuerpo

3. Content-Transfer-Encoding: las transformaciones de código y el

tipo de codificación final

4. Content-ID: Identificador del contenido (opcional)

5. Content-Description: descripción (opcional)

24

Una pincelada de ABNF (BNF aumentada)(rfc2234)

Una regla gramatical o dereescrituratiene la formaA := α, siendoA un símbolo (no-terminal) de la gramática yα una cadena por laque se puede reescribirA.

Los corchetes significan opcionalidad:[opcional]

’|’ denota distintas opciones:[opcion1|opcion2]

’*elemento’ denota repeticiones del elemento 0 o más veces

’n*m(elemento)’ repeticiones del elemento de n a m veces

’#elemento’ lista de elementos separados por comas

Entre dobles comillas (" * ") se puede denotar una cadenatal cual

... (ver como ejemplo una lista de identificadores)

25

MIME: Definición formal de campos cabecera

entity-headers := [ content CRLF ]

[ encoding CRLF ]

[ id CRLF ]

[ description CRLF ]

* ( MIME-extension-field CRLF )

MIME-message-headers := entity-headers

fields

version CRLF

; El orden es independiente

MIME-part-headers := entity-headers

[ fields ]

; Cualquier campo que no empiece con

; "content-" puede ser ignorado.

26

MIME: Definición formal de los Campos

Cabecera

Podemos refinar más ...

version := "MIME-Version" ":" 1 * DIGIT "." 1 * DIGIT

...pero lo dejaremos aquí

27

MIME: Tipos de contenido

1. Se definen unos tipos principales y unos subtipos

2. El tipo declara el tipo general de datos

3. El subtipo especifica el formato para ese tipo de datos

4. IANA ( Internet Assigned Numbers Authority): gestiona las

definiciones de tipos y subtipos. Estableciendo los mecanismos para

incorporar otros nuevos.

5. Visitar: http://www.iana.org/assignments/media-types/

28

MIME: Tipos IANA actuales (abril 2010)

1. aplication

2. audio

3. example

4. image

5. message

6. model

7. multipart

8. text

9. video

29

MIME: Tipo Texto ( text)

1. Se utiliza para transmitir texto que no necesita de software adicional

para ser mostrado

2. Tiene entre muchos subtipos

plain: texto claro (ASCII, ISO-8859)

enriched: texto enriquecido

csv: ver como ejemplo el RFC 4180

Otros:dns, html, rtf,sgml, etc.

30

MIME: Tipo Multiparte ( multipart)

Indica que el cuerpo tiene varias partes independientes

El parámetro de este tipoboundary define el delimitador de las

partes

Cada límite empieza en una nueva línea y está formado por dos

guiones y el valor delboundary ( - - myBoundary)

31

MIME: Tipo Multiparte ( multipart)

Tiene entre varios subtipos, entre otros

1. mixed: las partes son independientes pero van juntas y deben

mostarse en el orden en que aparecen.

2. parallel: no se establece ningún orden

3. alternative: las partes son diferentes versiones de lo mismo,

normalmente en diferentes formatos

4. encrypted, signed: para implementar s/mime

32

MIME: Tipo aplicación ( aplication)

Suelen ser datos binarios que son procesados por diferentes

aplicaciones. Tiene gran cantidad de subtipos

• Ejemplos:pdf, postcript, msword, ogg, etc

• Otros comopkcs10,pkcs7-mime,pkcs7-signatureestán

relacionados con la seguridad

33

MIME: Tipo mensaje ( message)

Permite incluir mensajes dentro de mensajes.

El subtiportf822 indica que el cuerpo es un mensaje completo que

incluye cabecera y cuerpo. Este mensaje puede ser a su vez un

mensaje MIME.

El subtipopartial permite trocear un mensaje en partes que se unirán

posteriormente en destino.

El subtipoexternal-bodyindica que el cuerpo no incluye incluye los

datos sino información de dónde localizarlos.

34

MIME: Definición formal de tipos de contenido

content := "Content-Type" ":" type "/" subtype

* (";" parameter)

; La concordancia de tipo y subtipo de contenido

; es SIEMPRE insensible a mayúsculas.

type := discrete-type / composite-type

discrete-type := "text" / "image" / "audio" / "video" /

"application" / extension-token

composite-type := "message" / "multipart" / extension-tok en

35

MIME: Codificación

Se admiten diferentes tipos de codificación

7 bits: lineas cortas de caracteres ASCII

8 bits: lineas cortas de bytes

binario: en general no es compatible con SMTP

Imprimible textualmente: se codifica fundamentalmente en caracteres

ASCII, y es un formatocasi legible

base64: se codificasn cada 6 bits mediante 8 bits que se traducen en

caracteres ASCII

x-token: codificaciones específicas.

36

S/MIME: funcionalidad

Con S/MIME podremos firmar y cifrar mensajes utilizando las siguientes

funciones:

Datos empaquetados(enveloped data): consiste en contenido

cifrado

Datos firmados (signed data): consiste en una firma digital. El

resumen del contenido del mensaje se cifra con laKR del firmante.

El contenido más la firma se codifican mediante base-64. Este tipo de

mensaje solo lo puede ver un receptor con capacidad S/MIME.

37

S/MIME: funcionalidad

Datos firmados en claro (signed data): consiste en una firma

digital, igual que antes, pero solo se codifica la firma en base-64. Este

tipo de mensaje solo lo puede ver un receptor sin capacidad S/MIME,

aunque no puede validar la firma.

Datos firmados y empaquetados: consiste en anidar entidades para

que se puedan firmar datos cifrados y cifrar datos firmados.

38

S/MIME: Algoritmos criptográficos

Paracrear un resumen: se DEBE soportar SHA-1 y se DEBERÍA

soportar MD5

Paracifrar un resumen: se DEBE soportar DDS y se DEBERÍA

soportar RSA

Paracifrar la clave de sesión: se DEBE soportar Diffie-Hellman

(ElGamal) y se DEBERÍA soportar RSA

Paracifrar el mensaje con la clave de sesión: se DEBERÍA soportar

3DES y RC2/40 (exportable un USA) para cifrar y para descrifrar

DEBE soportar 3DES.

39

S/MIME: Selección de algoritmos

Un emisor puede comunicar sus capacidades de descifrado para que

futuros mensajes que le manden

Si se conocen las capacidades del receptor hay que aplicarlas

Si no se conocen las capacidades del receptor se utiliza el algoritmo

que se utilizó en la última conexión.

Si el emisor no tiene información del receptor utilizar 3DESo

RC2/40 si no quiere arriesgar a que no ser descifrado

Si las capacidades de descifrado son distintas para los diferentes

destinatarios se deben manda mensajes distintos.

40

S/MIME: Mensajes

Se crea el subtipomultipart/signed: es un mensaje firmado en claro

en dos partes: mensaje y firma

Se crea el subtipoaplication/pkcs7-mimecon distintos parámetros:

• SignedData: entidad firmada

• EnvelopedData: entidad cifrada

• degenerates signed Data: para certificados

41

S/MIME: Entidades en mensajes

Una entidad MIME puede ser:

• un mensaje completo (menos la cabeceras rfc822)

• y si es multiparte, una o más subpartes

Las entidades, más alguna otra información asociada a la seguridad,

se denominanobjetos PKCSy se incluyen en el mensaje como un

contenidomás.

42

S/MIME: EnvelopedData I

Content-Type: aplication/pkcs7-mime; smime-type=enveloped-data;

Se genera una clave de sesión y se cifra con laKU del receptor

Para cada receptor se crea unRecipienInfo, que incluye:

• Identificador del certificado del receptor (X.509)

• Identificador algoritmo para cifrar la clave de sesión

• La cave de sesión cifrada

Después se cifra en contenido con la clave de sesión

El resultado se codifica enbase64

43

S/MIME: EnvelopedData II

El receptor del enveloped-data debe hacer lo siguiente:

• Eliminar la codificaciónbase64

• Desencriptar la cave de sesión mediante su clave privada (KR)

• Desencriptar el contenido con la clave de sesión

44

S/MIME: SignedData I

Content-Type: aplication/pkcs7-mime; smime-type=signed-data;

El proceso consiste en:

• Calcular el resumen del contenido (SHA-1, MD5)

• Cifrar el resumen con laKR del firmante

• Crear un bloqueSignedInfo incluyendo

45

S/MIME: SignedData II

El bloqueSignedInfo incluye:

• certificado de laKU del firmante,

• identificador del algoritmohashpara calcular el resumen

• identificador del algoritmo para cifrar el resumen

• el resumen cifrado

Es posible incluir la cadena de certificados desde la CA raiz hasta el

firmante.

46

S/MIME: clear signing

Content-Type: multipart/signed;

protocol="application/pcks7-signature"

mical = sha-1; boundary = mi-delimitador

El mensaje se envía en claro para que cualquier que use MIME pueda

leerlo, y sólo los que utilizan S/MIME pueden verificar la firma

Se incluyen dos partes una de ellas es de tipo signed-data

La otra es de cualquier tipo MIME (lo que se va a firmar)

47

S/MIME: Solicitud de registro

Content-Type: aplication/pkcs10-mime;

Se utiliza para transferir una solicitud de certificación

incluye en nombre del sujeto cuya clave va a ser certificada y la

propia clave.

48

S/MIME: Mensaje contenedor de certificados

Content-Type: aplication/pkcs7-mime; smime-type=degenerate;

Se utiliza para transferir certificados o una lista de revocación de

certificados (CRL)

49

S/MIME: Certificados

Se sigue el estandar X.509

La gestión es un híbrido entre la jerarquía X.509 y la red de confianza

de PGP.

Las listas de clave fiables y de revocaciones las gestiona el

adminitrados del agente de usuario.

50

Un ejempo vale más que ...

http://www.nisu.org/smime/exMail/exMail.html

51

top related