Criptografía C9

7/24/2019 Criptografa C9

1/44

1

Criptografa y Protocolos de Seguridad

Clase 9

Rosa Muoz Calanchie


2/44

Distribucin de Claves

Para dos partes A y B la distribucin de claves puede lograrse devarias maneras:

Clave seleccionada por A y enviada a B

Tercera parte selecciona clave y la reparte a A y B

Usa clave antigua para encriptar y transmite nueva clave de A a B

Usa clave antigua para transmitir nueva clave desde una tercera partea A y B


3/44

Los dos primeros implican reparto manual de clave. Para

encriptacin en un enlace es un requerimiento razonable, pero no

para encriptacin extremo a extremo.

El problema de la distribucin de claves es particularmente difcil enun sistema distribuido de rea amplia.

La tercera opcin es una posibilidad para la encriptacin de enlace

o la encriptacin extremo a extremo. Pero igual debe hacerse la

distribucin de clave inicial. Adems si una clave se comprometetodas las claves siguientes sern reveladas.

Para encriptacin extremo a extremo, algunas variantes de la

opcin 4 han sido ampliamente adoptadas. En este esquema un

Centro de distribucin de claves es responsable de la distribucin

de claves a pares de usuarios (host, procesos, aplicaciones)cuando se necesiten. Cada usuario debe compartir una clave nica

con el centro de distribucin de claves.


4/44

El uso de un Centro de distribucin de claves (KDC) se basa en el

uso de una jerarqua de claves. Como mnimo se usan dos niveles

de claves.

Comunicacin entre sistemas finales se encripta usando una clavetemporal, a menudo llamada clave de sesin. Tpicamente usada

mientras dura una conexin lgica y despus se descarta.

Las claves de sesin se transmiten encriptadas con una clave

maestraque es compartida por el centro de distribucin de claves yel sistema final o usuario.

Se disminuye la escala del problema, si hay N entidades que

quieren comunicarse en pares, de N*(N-1)/2 claves de sesin

necesitadas en algn momento, a solo N claves maestras, una para

cada entidad.

Las claves maestras pueden ser distribuidas en alguna forma no

criptogrfica, tal como reparto fsico.

Para redes muy grandes se puede establecer una jerarqua de

KDCs.


5/44

Distribucin Automtica de Claves para

Protocolos Orientados a Conexin


6/44

Distribucin Automtica de Claves

Clave de Sesin

Usada por la duracin de una conexin lgica

Destruida al final de la sesin

Usada para los datos de usuario

Clave Permanente

Usada para la distribucin de claves

Centro de Distribucin de Claves (KDC)

Determina cules sistemas pueden comunicarse

Provee una clave de sesin para esa conexin

Mdulo de Servicio de Seguridad (SSM)

Realiza encriptacin extremo a extremo

Obtiene claves para los host


7/44

Distribucin de Claves Descentralizada


8/44

Distribucin de Claves Descentralizada

No prctico para redes muy grandes usando encriptacin simtricasolamente, puede ser til dentro de un contexto local.

Requiere que cada sistema final sea capaz de comunicarse demodo seguro con todos los sistemas finales potencialespartners

para la distribucin de claves de sesin.

Puede necesitar hasta [n(n-1)]/2 claves maestras para unaconfiguracin con n sistemas finales.

Cada nodo debe mantener a lo mas (n-1) claves maestras y tantas

claves de sesin como requiera pueden ser generadas y usadas.

Las claves de sesin se utilizan por un tiempo limitado para

protegerlas.

Ya que los mensajes transferidos usando la clave maestra son

cortos el criptoanlisis es difcil.


9/44

Se puede definir diferentes tipos de claves de sesin segn su uso:

!

Clave de encriptacin de datos, para comunicaciones a travs deuna red

! Clave de encriptacin de Nmeros de Identificacin Personal (PIN),

usados en transferencias electrnicas de fondos y aplicaciones de

puntos de venta.

!

Clave de encriptacin de archivos, para encriptar archivos

almacenados en localizaciones de acceso pblico.

Puede ser deseable instituir controles en los sistemas que limiten el

modo en que se usan las claves, basados en caractersticas

asociadas con dichas claves. Ej; asociar un tagcon cada clave.

Un esquema mas flexible es el uso de un vector de control asociado

a cada clave de sesin, que consiste de un numero de campos que

especifican los usos y restricciones para esa clave de sesin. La

longitud del vector de control puede variar.

Control sobre el uso de las claves de sesin


10/44

El vector de control se acopla criptogrficamente con la clave

maestra en el momento de la generacin de clave en el KDC. Como

primer paso, el vector de control se pasa a travs de una funcin

hash que produce un valor de longitud igual a la de la clave deencriptacin. Entonces el hash es XOR con la clave maestra, el

resultado se usa como clave para encriptar la clave de sesin.

Hash = H = h(CV)

Clave de entrada = KmXOR H

Texto Cifrado = E(KmXOR H, Ks)

La clave de sesin se recupera con la operacin inversa:

Ks = D(KmXOR H, E(KmXOR H, Ks))

El vector de control se enva en claro junto con la clave de sesin.


11/44

Administracin de Claves

Encriptacin de clave pblica ayuda a resolver los problemas de la

distribucin de claves

Hay dos aspectos a considerar:

la distribucin de claves pblicas y,

el uso de encriptacin de clave pblica para distribuir claves

secretas


12/44

Distribucin de Claves Pblicas

Varias tcnicas han sido propuestas, las cuales pueden agruparse

en las siguientes categoras:

anunciadas pblicamente

directorio disponible pblicamente

autoridad de clave pblica

certificados de clave pblica


13/44

Anuncio Pblico

usuarios distribuyen claves pblicas a recipientes o broadcastatoda la comunidad

eg. agregar claves PGP a mensajes de emailo enviar a gruposde newso listas de email

Principal debilidad es la falsificacin

cualquiera puede crear una clave diciendo ser otra persona yrepartirla

hasta que la falsificacin sea descubierta puede suplantar alusuario


14/44


15/44

Directorio Pblico

se puede obtener mayor seguridad registrando las claves en undirectorio pblico

mantencin y distribucin del directorio pblico debe ser laresponsabilidad de alguna entidad u organizacin confiable.

con propiedades:

contiene entradas {nombre, clave-pblica}

registro de participantes seguro en el directorio

participantes pueden reemplazar claves en cualquier momento

directorio se publica peridicamente

directorio puede ser consultado electrnicamente

todava vulnerable a alteraciones o falsificacin


16/44


17/44


18/44

Certificados de Clave-Pblica

certificados permiten el intercambio de claves sin acceso en tiempo-real a la autoridad de clave-pblica

un certificado une la identidada una clave pblica

usualmente con mas informacin tal como perodo de validez,

derechos de uso etc

con todos los contenidos firmadospor una Autoridad de Clave-Pblica o Autoridad de Certificacin (CA) confiable

puede ser verificado por cualquiera que conozca la clave pblica de

las autoridades de clave-pblica o Autoridad de Certificacin (CA)

estndar X.509 aceptado como formato de certificados de clavepblica, ej: IP security, SSL, SET y S/MIME.


19/44

Uso de Certificado de Clave-Pblica


20/44


21/44

Distribucin de Claves Secretas usando

Claves-Pblicas

usa los mtodos anteriores para obtener clave-pblica

se pueden usar para confidencialidad o autenticacin

pero algoritmos de clave-pblica son lentos

por eso que generalmente se desea usar encriptacin de clave-privada para proteger el contenido del mensaje

necesitndose una clave de sesin

hay varias alternativas para negociar una clave de sesinconveniente


22/44


23/44

propuesto por Merkle en 1979

A genera un par nuevo de clave pblica temporalmente

A enva a B la clave pblica y su identidad

B genera una clave de sesin K la enva a A encriptada usandola clave pblica suministrada

A desencripta la clave de sesin y ambos la usan

el problema es que un oponente puede interceptar mensajes y

entonces suplantar ambas mitades del protocolo, este ataque se

conoce como man-in-the-middle.


24/44

Distribucin de Claves Secretas usando

Claves-Pblicas

si ya se ha intercambiado seguramente las claves-pblicas:

intercambio de clave secreta y autentificacion


25/44

Hybrid Key Distribution

usado en mainframes IBM

conserva el uso de KDC de clave-privada

comparte clave maestra secreta con cada usuario

distribuye clave de sesin usando clave maestra

Un esquema de clave-pblica se usa para distribuir claves maestras

especialmente util con usuarios muy distribuidos


26/44

Intercambio de Claves Diffie-Hellman

usuarios Alice & Bob desean intercambiar claves:

acuerdan dos primos q=353y a=3

seleccionan claves secretas aleatorias:

A elige xA=97, B elige xB=233

calculan claves pblicas respectivas:

yA=397

mod 353 = 40 (Alice)

yB=3233mod 353 = 248 (Bob)

calculan clave de sesin compartida como:

KAB= yBxAmod 353 = 248

97= 160 (Alice)

KAB= yAxBmod 353 = 40

233= 160 (Bob)


27/44


28/44

Protocolos de Intercambio de Claves

usuarios pueden crear claves privadas/pblicas D-H cada vez quese comunican

usuarios pueden crear una clave conocida privada/pblica D-H ypublicar en un directorio, luego se puede consultar y usar para

comunicarse con ellos

ambos son vulnerables al ataque man-in-the-middle

se requiere autentificacin de las claves


29/44

Diffie-Hellman ECC

Puede hacerse un intercambio de claves anlogo a D-H

usuarios seleccionan una curva conveniente Ep(a,b)

selecciona punto base G=(x1,y1) con orden mayor n s.t. nG=O

A & B seleccionan claves privadas nA


30/44

Protocolos de Autentificacin

Usados para convencer a las partes de la identidad de cada una ypara intercambiar claves de sesin

Pueden ser en un sentido o ambos

Temas claves son

confidencialidad para proteger claves de sesin

oportunidad para prevenir ataques de replay


31/44

Ataques de Replay

donde un mensaje vlido firmado es copiado y reenviado mas tarde

reenvo nico, el oponente copia un mensaje y lo reenva mastarde

repeticin que puede ser logged, un oponente coloca unmensaje con timestampdentro de la ventana de tiempo devalidez

repeticin que no puede ser detectada, si el mensaje original hasido eliminado y slo llega el mensaje reenviado

reenvo hacia atrs sin modificacin, este es el reenvo al emisordel mensaje, es posible si se usa encriptacin simtrica

contramedidas incluyen

uso de nmeros de secuencia (generalmente imprctico)

timestampso sellos de tiempo (necesitan relojes sincronizados)

desafo/respuesta (usando situacin actual nica)


32/44

Usando Encriptacin Simtrica

Se puede usar dos niveles jerrquicos de claves

Generalmente con un Centro de Distribucin de Claves confiable(KDC)

Cada participante comparte su propia clave maestra con el KDC

KDC genera claves de sesin usadas para conecciones entreparticipantes

Clave maestra usada para distribuir la clave de sesin entre

ellos


33/44

Protocolo Needham-Schroeder

Protocolo de distribucin de claves para sesin entre A y B mediadopor KDC

Protocolo es:

1.A!KDC: IDA|| IDB|| N12. KDC!A: EKa[Ks|| IDB|| N1|| EKb[Ks||IDA] ]3.A!B: EKb[Ks||IDA]4. B!A: EKs[N2]5.A!B: EKs[f(N2)]

Ka, Kb claves secretas de A y B que cada uno comparte con KDCKs clave de sesin que se desea distribuir a A y B.

N1, N2 nonces o desafos

Ambas partes deben confiar totalmente en el KDC, ya que elige Ks


34/44


35/44

Protocolo Needham-Schroeder

usado para distribuir de manera segura una nueva clave de sesinpara la comunicacin entre A & B

pero es vulnerable a un ataque de repeticin si una vieja clave desesin ha sido comprometida

entonces mensaje 3 puede ser reenviado convenciendo a B quese est comunicando con A

modificaciones para manejar esto requieren:

timestamps (Denning 81)

usar algna cosa de la situacin actual extra (Neuman 93)


36/44

Modificacion de Needham/Schroeder incluyendo

timestamps [Denning 82]

1.

A -> KDC: IDA"IDB2. KDC -> A:

EKa[KS"IDB"T"EKb[KS"IDA"T]]

3.

A -> B: EKb[KS"IDA"T]4. B -> A: EKS[N1]5. A > B: EKS[F(N1)]

Susceptible a ataques suppress-replay, por la necesidad desincronizacion. Se produce cuando el reloj del transmisor estaadelantado con respecto al reloj del receptor.


37/44

Modificacion en [KEHNE92] con Nonces

1.

A -> B: IDA"Na2.B -> KDC: IDB"Nb"EKb[IDA"Na "Tb]3.KDC -> A: EKa[IDB"Na"KS"Tb]"EKb[IDA"KS"Tb]"Nb

4.

A > B: EKb[IDA"KS"Tb]"EKS[Nb]

B le solicita al KDC que emita credenciales para A, en el bloqueencriptado con Kb, el bloque especifica el destinatario y un tiempo deexpiracion sugerido para las credenciales y el nonce recibido desde A.

El bloque que el KDC pasa a A, encriptado con Kb, puede servir como unticket que puede volver a ser usado por A.


38/44

Modificacion en [KEHNE92] con Nonces

Suponga que A y B establecen una sesion usando el protocolo propuestopor Kehne y esa sesion termina. Posteriormente, pero dentro del tiempolimite establecido por el protocolo, si A desea establecer una nuevasesion con B, el siguiente protocolo serviria:

1.

A > B: EKb[IDA"KS"Tb]"Na2. B -> A: Nb"EKS[Na]3. A -> B: EKS[Nb]

Cuando B recibe el mensaje del punto 1, verifica que el ticket no hayaexpirado. Como Tb es un tiempo relativo al reloj de B no se requiere quelos relojes de A y B esten sincronizados.

Los nuevos nonces Na y Nb aseguran que no es un ataque de replay.


39/44

Usando Encriptacin de Clave Pblica

Varias formas de hacerlo basados en el uso de encriptacin declave pblica

Necesita asegurar que tiene las claves pblicas correctas de losotros participantes

Usando un Servidor Central de Autentificacin (AS)

varios protocolos existen usando timestampso nonces(desafos)


40/44

Protocolo Denning AS

Denning 81 present:

1.A!AS: IDA|| IDB2.AS!A: EKRas[IDA||KUa||T] || EKRas[IDB||KUb||T]3.A!B: EKRas[IDA||KUa||T] || EKRas[IDB||KUb||T] || EKUb[EKRa[Ks||T]]

Note que la clave de sesin es elegida por A, por esto AS nonecesita ser confiable para protegerla

timestampsprevienen reenvos pero requiere relojes sincronizados


41/44

Propuesta de Woo y Lam usando nonces en vez de

timestamps para el caso de encriptacion de Clave

Publica, version revisada en [WOO92]

1.

A -> KDC: IDA"IDB2.

KDC -> A: EKRauth[IDB"KUb]3.

A -> B: EKUb[Na"IDA]4.

B -> KDC: IDB"IDA"EKUauth[Na]5.

KDC -> B: EKRauth[IDA"KUa]"EKUb[EKRauth[Na"KS"IDA"IDB]]6.

B -> A: EKUa[EKRauth[Na"KS"IDA"IDB]"Nb]7.

A > B: EKS[Nb]

Paso 5 dice que Ks es una clave secreta generada por el KDC a solicitud deB y ligada a IDa y Na, la union de Ks y Na asegura a A que Ks es fresca.

El paso 7 asegura a B que A conoce la clave de sesion Ks.


42/44

Autentificacin en un Sentido

Requerida cuando el emisor y receptor no estn en comunicacin al

mismo tiempo (eg. email)

El encabezado debe quedar en claro para que pueda ser entregado

por el sistema de correo electronico

Se puede desear que el contenido del cuerpo del mensaje est

protegido & autentificar al emisor


43/44

Usando Encriptacin Simtrica

Se puede refinar el uso de KDC pero no puede tener intercambiofinal de nonces:

1. A!KDC: IDA|| IDB|| N12. KDC!A: EKa[Ks|| IDB|| N1|| EKb[Ks||IDA] ]

3. A!B: EKb[Ks||IDA] || EKs[M]

no protege contra reenvos

puede apoyarse en timestampen el mensaje, aunque correosretrasados lo hacen problemtico


44/44

Variantes con Clave Pblica

si la mayor preocupacin es la confidencialidad, se puede usar:

A!B: EKUb[Ks] || EKs[M]

tiene clave de sesin encriptada, mensaje encriptado

si se necesita autentificacin se puede usar una firma digital con uncertificado digital:

A

!B: M || E

KRa[H(M)] || E

KRas[T||ID

A||KU

a]

con mensaje, firma, certificado

Criptografía C9

Documents

Transcript of Criptografía C9