criptografia_avanzada_(modulo_3)

7/24/2019 Criptografia_avanzada_(Modulo_3)

1/60

Protocolos

criptogrficosLloren Huguet Rotger

Josep Rif Coma

Juan Gabriel Tena AyusoPID_00200954


2/60

Los textos e imgenes publicados en esta obra estn sujetos excepto que se indique lo contrario auna licencia de Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 Espaa deCreative Commons. Podis copiarlos, distribuirlos y transmitirlos pblicamente siempre que citisel autor y la fuente (FUOC. Fundaci per a la Universitat Oberta de Catalunya), no hagis un usocomercial y no hagis una obra derivada. La licencia completa se puede consultar enhttp://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es


3/60

CC-BY-NC-ND PID_00200954 Protocolos criptogrficos

ndice

Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1. Protocolos de gestin y distribucin de claves . . . . . . . . . . . . . . . 9

1.1. Protocolo de transporte de una clave privada . . . . . . . . . . . . . . . . . 10

1.2. Protocolo de intercambio de dos claves de Needham-Schroeder 11

1.3. Protocolo de distribucin de claves centralizado . . . . . . . . . . . . . . 11

1.4. Protocolo de acuerdo de claves de Diffie-Hellman . . . . . . . . . . . . 12

2. Protocolos de autenticacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1. Protocolo de tres pasos de Shamir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2. Protocolo de Omura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3. Protocolo de Needham-Schroeder. .. .. . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4. Protocolo de Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5. Protocolo STS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.6. Otros protocolos: ISO, CCITT X.509, SSL . . . . . . . . . . . . . . . . . . . . . 24

2.7. Protocolos de identificacin de conocimiento nulo . . . . . . . . . . . 26

3. Transacciones electrnicas seguras: dinero electrnico . . . . . 30

3.1. Protocolo de Chaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2. Transacciones sin rastro. Firmas digitales ciegas de Chaum . . . 33

3.3. Sistemas de pago electrnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4. Protocolos de transferencia inconsciente. . . . . . . . . . . . . . . . . . . . . 38

4.1. Protocolo de Rabin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2. Protocolos de compromiso de bits .. . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3. Firma electrnica de contratos: Protocolo de Even . . . . . . . . . . . . 43

4.4. Protocolo de correo electrnico certificado. . . . . . . . . . . . . . . . . . . . 46

5. Esquemas umbral y reparto de secretos. . . . . . . . . . . . . . . . . . . . . . . 49

5.1. Esquema de Shamir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6. Votaciones electrnicas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1. Garantizar la privacidad y la correccin de los resultados .. . . . 53

6.2. Garantizar la auditora de la votacin .. .. . .. . . . . . . . . . . . . . . . . . . 55


4/60

CC-BY-NC-ND PID_00200954 Protocolos criptogrficos

Ejercicios de autoevaluacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Solucionario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59


5/60

CC-BY-NC-ND PID_00200954 5 Protocolos criptogrficos

Introduccin

Las comunicaciones electrnicas ofrecen nuevas posibilidades en los inter-

cambios de informacin, sobre todo en el campo de las transacciones comer-

ciales y en la administracin electrnica.

En el mundo no electrnico los intercambios de informacin, llevados a cabo

con medios ms convencionales, presentan problemas de seguridad y descon-

fianza que se resuelven a travs de un arbitraje con terceras partes de confian-

za, como, por ejemplo, jueces, notarios y agentes postales, entre otros, que

tradicionalmente son los que han dado seguridad a estos intercambios.

En las transacciones electrnicas, llevadas a cabo mediante protocolos de co-

municacin, la seguridad tiene un papel incluso ms relevante, ya que ne-

cesita dar, adems, una proteccin contra posibles amenazas, como son las

manipulaciones desautorizadas de los datos o las falsificaciones.

Al conjunto de acciones bien definidas y coordinadas descritas por un cierto

algoritmo, que permiten una interaccin entre dos, o ms, usuarios para llevar

a cabo un intercambio de datos o de informacin, se le llamaprotocolo.

Los protocolos criptogrficos son aquellos que, para llevar a cabo esta in-

teraccin, usan funciones criptogrficas para poder asegurar los requisitos de

seguridad en las comunicaciones entre los usuarios que intervienen en el in-

tercambio: la confidencialidad, la integridad, la autenticidad y el no repudio.

Vamos a encontrar ejemplos de uso de los protocolos criptogrficos en mbi-

tos tan diversos cmo: en comercio electrnico, donde tienen que utilizarse

firmas compartidas; en correo electrnico seguro, donde se necesitar algo

ms que un acuse de recibo; en la implementacin de sistemas electrnicos depagos con la utilizacin de firmas ciegas o en sistemas de votacin electrnica.

En muchos casos se necesitar, tambin, el arbitraje de una tercera parte de

confianza para garantizar todos los requisitos de seguridad en estas transac-

ciones electrnicas.

La diversidad de mbitos hace que exista tambin una amplia variedad de

protocolos criptogrficos para dar respuesta a los diferentes objetivos, pero

todos ellos se usan, generalmente, para eliminar desconfianzas.

Podemos dar la siguiente clasificacin, segn los objetivos que se quieran

lograr:


6/60


Gestin y distribucin de claves. Permiten y garantizan la generacin,

almacenamiento, mantenimiento y distribucin de claves de un sistema

criptogrfico de clave privada. En algunos casos, esta distribucin se har

utilizando criptosistemas de clave pblica.

Autenticacin de usuario. Permiten garantizar que el remitente de un

mensaje, con quien se establece comunicacin, es realmente quien preten-

de ser.

Transacciones electrnicas seguras. Permiten realizar las operaciones ban-

carias habituales, en particular, implementar sistemas de pago electrnicos

sustitutivos de las tarjetas de crdito y de dbito en las transacciones eco-

nmicas en el comercio electrnico, con una utilizacin muy especial en

el caso de micropagos (menos de 10 e).

Transferencias inconscientes o transcordadas. Permiten a un usuario en-

viar un mensaje o un secreto, entre dos posibles, a otro usuario. El usuario

emisor no conoce cul de los dos ha recibido el receptor. Estos protocolos

permiten la firma electrnica de contratos.

Compromiso de bit. Permiten a un usuario de una red comprometerse

con la eleccin de un bit (o ms, generalmente con una serie de bits) sin

revelar tal eleccin hasta un momento posterior. El protocolo garantiza a

la otra parte que el usuario no cambia su eleccin.

Comparticin de secretos. Permiten distribuir un cierto secreto entre un

conjunto de participantes de manera que ciertos subconjuntos prefijados

entre los participantes puedan, uniendo sus participaciones, recuperar el

secreto.

Pruebas de conocimiento nulo. Permiten a un usuario de una red con-

vencer a otro que el primero posee una cierta informacin, sin revelar nada

sobre el contenido de la misma.

Votaciones electrnicas. Permiten realizar un proceso electoral electrni-

camente, garantizando la privacidad de cada votante y la imposibilidad de

fraude.


7/60


Objetivos

En los materiales didcticos de este mdulo el estudiante encontrar los con-

tenidos necesarios para alcanzar los objetivos siguientes:

1. Conocer los protocolos ms importantes de gestin y distribucin de claves.

2. Conocer los protocolos ms importantes de autenticacin.

3. Conocer los protocolos ms importantes de transacciones electrnicas se-

guras y sistemas de pago electrnico.

4. Conocer los protocolos ms importantes para implementar la firma de con-

tratos y el correo electrnico certificado.

5. Conocer los fundamentos de los esquemas de umbral.

6. Conocer los fundamentos de las votaciones electrnicas.


8/60


9/60


1. Protocolos de gestin y distribucin de claves.

Uno de los problemas de la criptografa de clave privada est en la distribucin

de las claves entre los usuarios de una red de comunicaciones, en la que cada

pareja de usuarios A,B necesita compartir una clave KAB, para crear un canal

privado virtual entre ambos.

Esta clave no puede ser enviada por la propia red de comunicaciones (que

consideraremos insegura) y que, adems, por motivos de seguridad, debe ser

cambiada peridicamente. Muchas veces,KABes desechable y se la llamaclavede sesin.

Por lo que hace a la gestin de claves, sta comporta interrogantes, como ase-

gurar quines asumen la responsabilidad de la creacin de las claves (con di-

ferentes alternativas: autoridad central o sistema totalmente descentralizado),

construir diferentes tipos de claves (de comunicaciones, maestras, de sesin),

definir los requisitos de seguridad en el almacenamiento de las mismas, etc.

En este apartado pondremos nfasis en los protocolos de distribucin:

Notacin

A lo largo de este mdulo,cuando nos referimos a unsistema criptogrfico de clavepblica, la notacin queusaremos, asociada a unusuarioU, ser:

IdU: Identidad usuario. EU(m): Proceso de cifrar

un mensajem, con la

clave pblica deU. DU(c): Proceso de des

cifrar un criptogramac,con la clave privada deU.

1) Gestin de claves en los sistemas criptogrficos de clave pblica. En un

sistema criptogrfico de clave pblica, donde cada usuario Udispone de su pa-

reja de claves:EUpara cifrar yDUpara descifrar, no es necesaria la distribucin

de las clave para cifrar; al contrario, han de estar accesibles para cualquiera que

desee utilizarlas y poder comunicarse con el propietario de las mismas. Existe,

sin embargo, el riesgo de la impersonacin, es decir, un adversario C puede

hacer creer que su clave pblicaECes la clave pblica de otro usuario.

Consideramos cuatro esquemas posibles de gestin de claves pblicas:

Anuncio pblico: cada participante difunde su clave pblica al resto de

usuarios. El riesgo de impersonacin es grande.

Directorio pblico: mantenido por una cierta autoridad, una tercera parte

de confianza, con acceso directo y libre (para lectura) por parte de cual-

quier usuario al directorio de claves TPD (trusted public directory). Cualquier

usuarioUregistra en el TPD su identidad; IdU; y su clave pblica, EU, en

persona o mediante comunicacin autorizada, lo cual, en principio, elimi-

na el riesgo de la impersonacin.

Autoridad pblica: similar al anterior, pero los usuarios no tienen acceso

directo al directorio de claves, sino que interaccionan con un centro de


10/60


distribucin de clavesKDC (key directory centre). Si el usuarioA desea cono-

cer la clave pblica del usuario B, debe formular una peticin expresa a la

autoridad que mantiene el directorio.

*Ver el subapartado 2.6 del

mdulo Elementos de

criptografa.

Autoridad certificadora: es una tercera parte de confianza,T, que expide

a cada usuario Uun certificado de su clave pblica, ligada a su identidad

IdU, junto con otros datos. Este certificado va firmado con la clave privada

deT. As, un usuarioA puede enviar a otro usuario B este certificado y ste

puede comprobar, utilizando la clave pblica de la autoridad ET, la validez

de la clave, la identidad del emisor, as como los otros datos incluidas, entre

ellos el periodo de vigencia del certificado, etc.*

2) Distribucin de claves en los sistemas criptogrficos de clave privada.

En los sistemas criptogrficos de clave privada, las claves se deben distribuir de

forma centralizada puesto que en otro caso, el administrador de una red ten-

dra que proporcionar claves a cada pareja de usuarios que quieran intercam-

biarse informacin secreta. Esto querra decir que el administrador necesitara

tener almacenadas`n

2

=

n(n 1)

2 =O(n2) claves, y cada usuario (n 1) claves.

En un sistema criptogrfico de clave privada, dos usuarios A y B pueden esta-

blecer una claveKAB, compartida por ambos, por dos mtodos:

Transporte de claves: un usuario crea una clave y la transfiere, con segu-

ridad, al otro usuario (alternativamente, puede ser una tercera parte quien

la crea y transfiere a ambos).

Acuerdo de claves (key agreement): la clave es calculada por los usuarios

como una cierta funcin de la informacin suministrada por ambos usua-

rios. En principio ningn usuario, por s mismo, puede predeterminar el

valor de esta clave.

Un problema adicional que puede plantearse es el de la autenticacin de las

claves y de los usuarios que las acuerdan o envan. Tal autenticacin ser re-

suelta con los protocolos de distribucin, en la mayora de casos utilizando

sistemas criptogrficos de clave pblica para distribuir una clave privada.

1.1. Protocolo de transporte de una clave privada

Este protocolo permite transferir una clave KA, elegida por el usuarioA, a otro

usuarioB, mediante un algoritmo de un solo paso.

Supondremos que el usuario A tiene acceso a una copia autenticada de EB y

que usa un parmetro temporal,TP.

Protocolo

A B. El usuarioA enva aB:EB(IdA,KA,TP)


11/60


Ahora, el usuarioBpuede descifrar lo que ha recibido, con su clave privada DB

y, de este modo, verificar la identidad del emisor, el parmetro temporal TPy

asociar la claveKAal usuarioA.

Resumen de las transacciones del protocolo:

A B

EB(IdA,KA,TP))

1.2. Protocolo de intercambio de dos claves de Needham-Schroeder

Este protocolo permite intercambiar dos claves secretas entre dos usuarios A

y B, respectivamente, KA y KB, con solo 3 pasos, al mismo tiempo que los

usuarios se autentican mutuamente.

Autenticaciones

Autenticacin de Bporparte de A: el usuarioAcomprueba queRAescorrecto, con lo cualautentica aB y confirmaque ha recibidoKB.

Autenticacin de A por

parte deB

: el usuarioBcomprueba queRB escorrecto, con lo cualautentica aA y confirmaque ha recibidoKA.

Protocolo

A B. El usuarioA elige un nmero aleatorioRAy envaa B:EB(IdA,KA,RA).

B A. El usuarioB descifra lo que ha recibido, con su clave privada DB,

y obtieneRA, adems de la clave pblica y la identidad de A. AhoraB elige

otro nmero aleatorioRB y enva aA:EA(KB,RA,RB).

A B. El usuarioA descifra lo que ha recibido, con su clave privada DA,y obtiene RB, adems de la clave pblica y la identidad de B, y enva a B:

EB(RB).


A B

EB(IdA,KA,RA)

EA(KB,RA,RB)

EB(RB)

1.3. Protocolo de distribucin de claves centralizado

Este protocolo permite la distribucin de una clave de sesin a dos usuarios A

yB, para utilizar en un sistema criptogrfico de clave privada.

Caso prctico

Se puede pensar en un

protocolo donde se quierausar una clave de sesin parautilizar con el sistemaAES,mientras que la distribucinse hace con un sistemaElGamal.

Supongamos queA yB disponen de un sistema criptogrfico de clave pblica y

que, en este caso, interviene una autoridad pblica,T, que gestiona un centro

de distribucin de clavesKDC.


12/60


Para iniciar el protocolo, el usuarioA comunica a la autoridad pblica T, que

se quiere comunicar con B y, para ello, solicita la identidad deB y una clave

de sesinKABpara compartir. Adems, se utilizar un parmetro temporal TP,

para controlar el plazo de vigencia.

Protocolo

T A. La autoridad pblicaTenva aA:EA(IdB,KAB,TP,EB(IdA,KAB,TP)).

El usuario A descifra lo que ha recibido, con su clave privada DA, y obtiene:

IdB,KAB, el parmetroTPy EB(IdA,KAB,TP).

A B. El usuarioA enva aB:EB(IdA,KAB,TP).

El usuario B descifra lo que ha recibido, con su clave privada DB, y obtiene:

IdA,KABy TP.

Finalmente, para iniciar la transmisin con total garanta, hara falta un acuse

de recibo por parte deB a A, contrastando la validez del valor TP.


T A

EA(IdB,KAB,TP,EB(IdA,KAB,TP))

A B

EB(IdA,KAB,TP)

1.4. Protocolo de acuerdo de claves de Diffie-Hellman

Este protocolo se basa en la funcin exponencial y el logaritmo discreto, en

un cuerpo finito Zp, y no necesita ninguna otra intervencin ms que la de

los propios usuarios. La seguridad del protocolo se basa, precisamente, en la

intractabiliddad del clculo del logaritmo discreto.

Todos los usuarios conocen el valor del primo p y el de un elemento primitivo

Zp.

Cada usuario Ubusca al azar xU Zp , que guarda secreto, y hace pblico el

valor deyU =xU (mod p). As, cada usuarioUcoloca (IdU,yU) en el directorio

pblicoTPD.


13/60


Para compartir una clave de sesin,KAB, entre dos usuariosA y B, stos harn

lo siguiente.

Protocolo

El usuarioA obtieneyBdelTDP, calculaKA= yxA

B (mod p) =xBxA (modp).

El usuarioB obtieneyA del TDP, calculaKB= yxB

A (mod p) =xAxB (modp).

AhoraA y B ya pueden compartir una misma clave KAB = KA = KB (efectiva-

mente:xAxB (modp) = xBxA (mod p)) para intercambiarse mensajes, en un

sistema criptogrfico de clave privada, sin queA necesite del valor secretoxB,

niB necesite del valor secretoxA.

Resumen del protocolo:

A B

KA= yxA

B (mod p) KB= yxB

A (mod p)

Simulador de clculosen Zp

Para comprobar los clculosde este ejemplo, podis usaraplicativos de uso libre,como SAGE(http://www.sagemath.org).

Ejemplo 1.1.

Ay B quieren intercambiar una clave de sesinKAB, usando el cuerpo Zp, conp = 1999 yel elemento primitivo = 33. En realidad, este valor de p debera ser muy grande.

Supongamos queA escogexA = 47 y B escogexB = 117. Entonces, ambos usuarios harnlos siguientes clculos:

El usuarioA calculayA = xA (mod p) = 3347 (mod 1999) = 1343;

El usuario B calcula yB = xB (modp) = 33117 (mod 1999) = 1991;

As, (IdA,yA= 1343), (IdB,yB = 1991) figurarn en elTPD.

Protocolo

El usuarioA calculaKAB = yxAB (mod p) = 199147 (mod 1999) = 1506. El usuarioB calculaKBA = y

xBA (mod p) = 1343

117 (mod 1999) = 1506.

La clave secreta compartida por A y B serKAB = KBA = 1506.

Nota

El protocolo de acuerdo de claves de Diffie-Hellman es vulnerable, frente a ataques deimpersonacin.

Puede haber un espa activo-pasivo,C, que enve mensajes a B, a partir de los que recibedeA. Los usuariosAyBcreen que estn interconectados cuando en realidad sus mensajesson filtrados y/o manipulados por C, puesto que es Cquien realmente est conectado con

Ay con B.


14/60


Protocolo para impedir la impersonacin

Este problema de autenticacin de A por parte de B, o deB por parte de A, se

puede resolver con la intervencin de una autoridad pblica T.

El usuarioA enva aTla peticin que quiere conectarse con B.

T A. La autoridad pblicaTenva aA los siguientes certificados:

CA= DT(IdA,EA,TP) iCB= DT(IdB,EB,TP)

dondeTPes un parmetro temporal.

A B. El usuarioA calcula una clave de sesinKABy la enva aB, debida-

mente firmada y cifradaEB(CA,CB,X= DA(KAB)).

El usuario B comprueba, aplicando su clave privada, DB, a lo que acaba de

recibir; el certificado de A,CA, su certificado, CB, y la clave pblica de A, EA,

con la cual puede calcular la clave de sesin: KAB= EA(X).

A partir de ahora, los usuariosAy B, ya pueden empezar la transmisin segura

con la clave de sesin KAB.

Resumen de las transacciones para evitar el ataque de impersonacin:

T A

CA= DT(IdA,EA,TP); CB = DT(IdB,EB,TP)

A B

EB(CA,CB,X= DA(KAB))


15/60


2. Protocolos de autenticacin.

Los protocolos de autenticacin permiten verificar la identidad de un usuario

A, ante un usuario B, de forma que B pueda confirmar que es el usuario A

quien le ha envado un cierto mensaje.

Son protocolos que demuestran la identidad de A a B (en este apartado, lla-

maremos a verificador al usuario B). A veces, la identificacin consiste en

demostrar la posesin de un cierto secreto (que puede ser una clave), sin ne-

cesidad de revelarlo.

En general, el usuario A deber proporcionar una respuesta a un ciertodesafo

planteado por el verificador (normalmente, dentro de un plazo de tiempo

determinado). Por esto, a veces, a estos protocolos se los denomina de desafo-

respuesta.

Para la implementacin, un protocolo de autenticacin debera satisfacer los

requisitos siguientes:

Tendra que implementar conjuntamente con un protocolo de intercambio

de claves. Es este ltimo el que demuestra que no solo todos los participan-

tes son quienes dicen ser, sino que, adems, puede haber un intercambio

de informacin.

Tendran que encadenarse los mensajes que se van cruzando dentro de una

ejecucin concreta de forma que no pudieran ser sacados de contexto.

Tendra que evitarse la utilizacin de sellados de tiempo, lo que se conoce

comotimestamps, como herramienta de seguridad, aun cuando son tiles

desde un punto de vista administrativo y documental.

Tendra que evitarse que la revelacin de las claves intercambiadas en una

sesin comprometiera el secreto de las claves intercambiadas previamente. Tendra que poderse aadir a los datos a cifrar, en cada paso, algn otro

dato seleccionado aleatoriamente por los participantes lo que se conoce

comoadd your own salt, de manera que se impedir que la otra parte dis-

ponga de clculos que de otra manera no podra efectuar.

.

Definicin 2.1 (Protocolo de autenticacin seguro).

Diremos que un protocolo de autenticacin es seguro si, en el momento

en que un usuario acepta la identidad del otro, los registros que amboshan guardado de la sesin de autenticacin coinciden. Y, adems, no

debe ser computacionalmente eficiente que un tercer usuario pueda re-

cuperar el desafo aceptado.


16/60


.

Definicin 2.2 (Protocolo de autenticacin directo).

Diremos que el protocolo es de autenticacin directa si acaba inter-

cambiando mensajes entre los participantes usando las claves generadas

previamente.

Ejemplo 2.1.

Veremos dos protocolos de desafo-respuesta y, en ambos casos, usaremos un sistemacriptogrfico de clave pblica.

Protocolo 1:

Supongamos queA, para identificarse, quiere demostrar a B que posee la clave de desci-fradoDA, de un sistema criptogrfico de clave pblica.

B A. El verificadorB, enva a A: (IdB,d = (EA(RB)), donde des el desafo y RB unnmero aleatorio escogido porB.

A B. El usuarioA, dentro del plazo establecido, con su clave privadaDA, recuperaRB = DA(d), y lo enva aB.

El verificadorB, aceptar la identificacin deA si el valor recibido coincide conRB que lmismo haba enviado.


A B

IdB,d= (EA(RB)

RB = DA(d)

Protocolo 2:

B A. El verificadorB, enva a A: (IdB,RB), dondeRB es un nmero escogido por B.

A B. El usuarioA, dentro del plazo establecido, usando su clave privadaDAenva:(RA,IdB,DA(RA,RB,IdB)), dondeRAes un nmero escogido porA, y lo enva a B.

El verificadorB, aplicar, con la clave pblica de A,EAa la ltima componente del vector

recibido y comprobar la coincidencia deIdBy RAcon las dos primeras componentes delvector recibido y, adems, que RB coincide con el que l mismo le haba enviado.


A B

IdB,RB

RA,IdB,DA(RA,RB,IdB)

2.1. Protocolo de tres pasos de Shamir

Este protocolo permite el envo de informacin secreta deA a B, sin intercam-

bio previo de claves, a la vez queB tendr la certeza de que el emisor es A.


17/60


Para llevar a cabo este protocolo necesitamos una funcin criptogrfica que

sea conmutativa para cada pareja de usuarios, EA EB= EB EA.

Protocolo

A B. El usuarioA cifra con su clave pblica el mensaje m: EA(m), y lo

enva aB.

El usuarioB no puede calcularm, puesto que no conoce DA.

B A. El usuario B cifra con su clave pblica lo que acaba de recibir:

EB(EA(m)), y lo enva aA.

A B. El usuarioA, debido a la propiedad conmutativa presupuesta, pue-

de descifrar con su clave privada lo que ha recibido y recuperar EB(m), queenva aB. Efectivamente:DA(EB(EA(m)) = DA(EA(EB(m)) =EB(m)

AhoraB puede conocerm, descifrando con su clave privada lo que ha obteni-

do:m = DB(EB(m))) y, al mismo tiempo, estar seguro de que este mensaje lo

ha enviadoA.


A B

EA(m)

EB(EA(m))

EB(m)

Nota

Este esquema no asegura la autenticacin ni, en general, el secreto como se puede ver enel siguiente ejemplo.

Ejemplo 2.2.

Usaremos el sistema criptogrfico de clave pblica, de Pohlig-Hellmanque, basando suseguridad en el problema del logaritmo discreto, consiste en:

Escoger un grupo multiplicativoZp , dondep es un nmero primo grande.

Cada usuario elige un valoreU, relativamente primo con (p) = p 1 y calculadU =e1U

(mod (p)). La clave secreta de cada usuario ser el valor dU.

Para un mensajem y un criptogramac:

Cifrado:EA(m) =meA (mod p) y

Descifrado:DA(c) = cdA (mod p)


18/60


Evidentemente, este sistema criptogrfico de clave pblica cumple la condicin mencio-nadaEA EB = EB EA.

Por lo tanto, es seguro respecto al secreto, pero no desde el punto de vista de la autenti-cacin, como veremos en el ataque de impersonacin de Massey-Omura.

Empecemos con un ejemplo numrico de este protocolo:Tomandop= 103; si el usuarioA escoge e

A= 19 (d

A= e1

A (mod (p)) = 191 (mod 102) =

43) y el usuarioB escogeeB = 23 (dB = e1B (mod (p)) = 23

1 (mod 102) = 71);suponiendo que el mensaje que A quiere enviar a B es m = 10, el protocolo de tres pasosde Shamir sera el siguiente:

A B. El usuarioA enva aB:EA(m) = 1019 (mod 103) = 3.

El usuarioB no puede calcularm = 10, puesto que no conoceDA.

B A. El usuarioB calculaEB(EA(m)) = EB(3) = 323 (mod 103) = 95.

A B. El usuarioA puede calcular el valor de EB(m), mediante su clave privada DA:EB(m) = DA(EB(EA(m) = DA(95) = 95

43 (mod 103) = 27. El usuario A enva el valor 27aB.

Este valor coincide, efectivamente, conEB(10) = 1023 (mod 103) = 27.

Ataque de impersonacin de Massey-Omura

Veamos ahora, como en el ejemplo anterior, que un espa C se puede interpo-

ner entre los dos usuariosA y B violando el secreto de la transmisin.

Este tipo de ataques, tambin son conocidos como man-in-the-middle.

Protocolo

Si el usuario A quiere enviar un mensaje m, cifrado, al usuario B, calcula

EA(m) =meA (mod p).

A B. El usuarioA envaEA(m) aB

Si un espaC intercepta este mensaje cifrado puede retornar a A:

EC(EA(m)) = (meA )eC (mod p)

A C. el espaC envaEC(EA(m)) aA.

El usuarioA no t ningn mecanismo para comprobar que lo que recibe sea

deB.

SiA no desconfa, sigue con el tercer paso del protocolo de tres pasos de Sha-

mir:

DA((meA )eC ) (mod p) = ((meA )eC )dA (modp) =meC (modp).


19/60


A B. El usuarioA piensa que enva EB(m) y, en cambio, est enviando

EC(m) = meC (modp).

El espaC al recibir este valor, y dado que l conoceDC, puede calcular: (meC )dC

(mod p) = m.

De este modo el espaC ha podido conocer el mensaje m que A quera enviar

aB.

Resumen de las transacciones del ataque de impersonacin

A C

EC(EA(m)))

EC(m)

Ejemplo 2.3.

Usaremos el mismo sistema criptogrfico de clave pblica, de Pohlig-Hellman que en elejemplo anterior.

Tomemos p = 103; ya conocemos las claves pblicas y privadas de A y B, respectivamente:{eA = 19,dA = 43}y {eB = 23,dB = 71}.

Suponiendo que los parmetros del espa C sean {eC= 5,dC = 41} el ataque de autenticacin

seguira los siguientes pasos. Supongamos que el mensaje que se quiere enviar es m = 10:

A B. El usuarioA calculaEA(m) = 1019 (mod 103) = 3 y lo enva a B.

El espaC intercepta este mensaje y calcula:

EC(EA(m)) = (meA )eC (mod p) = 35 (mod 103) = 37.

A C. El espaC enva aA:EC(EA(m)) = 37.

El usuarioA no tiene ningn mecanismo para comprobar que lo que recibe es de B y, al nodesconfiar, descifra el mensaje recibido, mediante su clave privada dA:DA(EC(EA(m)) = DA(37) = 3743 (mod 103) = 90

A B. El usuarioA piensa que enva a B el valor 90 = DA(EB(EA(m)) = meB (mod p),

pero en realidad est enviando DA(EC(EA(m)) = EC(m).

El espaC recibe este valor y dado que l posee dC puede calcular: (meC )dC (mod p) = m. Para

ello calcula:DC(90) = 9041 (mod 103) = 10; y, por tanto, C conoce el mensaje m = 10 que A

enviaba aB.

2.2. Protocolo de Omura

Este es un protocolo semejante al de Diffie-Hellman de acuerdo de claves,

que permite la autenticacin de dos usuarios, sin que nadie ms que ellos

intervenga.


20/60


Sea Zpun elemento primitivo y supongamos que cada usuarioUtiene una

clave secretaxUy una clave pblicayU=xU (modp).

Protocolo

Una vez queA ha informado aB que l esA y que lo quiere probar, el protocolo

consiste en los dos pasos siguientes:

B A. El usuarioBescoge al azar un valorx, calculay= x (modp) y enva

ya A.

A B. El usuarioA calculayxA (modp) y enva el resultado aB.

El usuario B verifica la igualdad entre lo que acaba de recibir (yxA (mod p) y

el clculo a partir de la clave pblica de A y el valor x por l escogido ((yA)x

(mod p)). En caso de igualdad, acepta la autenticacin de A y, de lo contrario,

la rechaza.

Resumen de las transacciones del protocolo

A B

y= x (modp)

yxA (modp)

Ejemplo 2.4.

Utilizamos los parmetros del ejemplo 1.1.

Sea el cuerpo Zp, conp = 1999 y el elemento primitivo = 33.

Supongamos las claves pblicas y privadas deA y B, respectivamente:{xA = 47,yA =

xA (mod p) = 1343,xB = 117,yB = xB (modp) = 1991}

Los pasos del protocolo son (suponiendo que el usuario B ha sido avisado de que elusuarioA quera autenticarse):

B A.B escoge el valorx = 13, calcula y= 13 (mod 1999) = 319 y lo enva aA.

A B.A calculayxA (mod p) = 31947 (mod 1999) = 1465 y enva el resultado a B.

El usuario B verifica si el valor recibido coincide con = (yA)x (mod p). Efectivamente:

134313 (mod 1999) = 1465 y el usuario B da por autenticado al usuarioA.

2.3. Protocolo de Needham-Schroeder

Este es un protocolo de autenticacin e intercambio de claves, usando un

sistema criptogrfico de clave pblica y mediante un centro de distribucin de


21/60


claves, KDC, gestionado por la autoridad pblica T, que sigue los siguientes

pasos.

Protocolo

A T. El usuario A enva a T: DA(IdA,IdB,RA), donde RA es un nmero

aleatorio escogido porA.

T A. La autoridadTdevuelve aA:EA(RA,IdB,KAB,EB(KAB,IdA)), dondeKAB

es la clave de sesin, generada por elKDC, que han de utilizar A y B en su

intercambio.

A B. El usuarioA envaEB(KAB,IdA) aB.

B A. El usuarioB enva, cifrando con la clave de sesin: EKAB (RB) a A,dondeRB es un nmero aleatorio escogido por B.

A B. El usuarioA devuelveEKAB (RB 1) aB.

Cuando el usuarioB, descifrando con la clave de sesin, KAB, recibe el valor de

RB 1, da por autenticado al usuarioA.


A T

DA(IdA,IdB,RA)

EA(RA,IdB,KAB,EB(KAB,IdA))

A B

EB(KAB,IdA)

EKAB (RB)

EKAB (RB 1)

2.4. Protocolo de Kerberos

Este es un protocolo de distribucin de claves de sesin, mediante un centro

de distribucin de claves, KDC, que proporciona autenticacin del usuario

y establece la clave de sesin entre dos usuarios A y B, usando un sistema

criptogrfico de clave privada y terceras partes de confianza.


22/60


Hay otras versiones del protocolo para poder utilizar sistemas criptogrficos

de clave pblica.

ConsideramosT, el servidor de autenticacin Kerberos, como tercera parte de

confianza.

El protocolo de Kerberos se basa en el protocolo que acabamos de ver de

Needham-Schroeder. Se usan vales y sellado de tiempo para asegurar la iden-

tidad de los usuarios.

La utilizacin de los vales y del periodo de validez de la clave KAB evita que

pueda haber ataques usando claves de sesin utilizadas previamente.

Autenticacin Kerberos

Kerberos permite laautenticacin deA anteB.Incluye sellado de tiempo yuna autoridad decertificacinon-line, quecomparte una clave privadacon cada usuario para hacerlas operaciones de cifradoEAT,EBT. ElvaleB vaacompaado delautenticador.

Protocolo

A T. El usuarioA envaT: (IdA,IdB,RA,TSA), dondeRAes un valor aleato-

rio escogido porA y TSA es un sellado de tiempo deA.

T A. El servidor de autenticacin enva aA: (valeB,EAT(KAB,RA,L,IdB),

dondeEATes la operacin de cifrar con la clave privada que comparten A y

T,L indica el periodo de validez de la claveKABy elvaleB= EBT(KAB,IdA,L).

A B. El usuarioA enva a B: (valeB,autenticador), donde autenticador =

EKAB (IdA,TSA), creado porA y que contiene el sellado de tiempo,TSAcifrado

con la clave de sesin KAB.

B A. El usuarioB enva aA:EKAB (IdA,TSA)

A partir de aqu, los usuariosA y B comparten una clave de sesinKABy estn

mutuamente autenticados.


A T

IdA,IdB,RA,TSA

valeB,EAT(k,NA,L,IdB)

A B

valeB,autenticador

EKAB (TSA)


23/60


2.5. Protocolo STS

Este protocolo responde al acrnimo (station-to-station) y fue creado por Diffie,

Oorschot, Wiener como una propuesta de protocolo seguro para la autentica-

cin y el intercambio de claves, basado en un sistema criptogrfico de clave

pblica.

Consideraciones dediseo

Los valoresp y los escogecada usuario y mejor si sondiferentes, puesto que losataques ms eficientes allogaritmo discreto se basanen la construccin de tablas apartir del conocimiento dep.En el segundo pasoB enva a

Asu certificadoCertB = (IdB,EB,DT(B,EB)). Deeste modoA podr calcularEB y comprobar queyB secorresponde con elhashfirmadoDB{yB,yA}. Esto daautenticidad aB.El usuarioB tiene que utilizarlos parmetros pasados porAen el primer paso, en lugarde buscarlos en un directoriopblico. En el tercer paso elcertificado deA asegura aBque estos parmetros soncorrectos.

Supondremos que, al igual que en el protocolo de Diffie-Hellman, todos los

usuarios conocen el valor del nmero primo py del elemento primitivo Zp

y que cada usuario Usube (IdU,yU) al directorio pblico TPD (recordar que cada

usuario haba escogido un valor xU Zp , que guardaba secreto, y calculaba el

valor pblicoyU=xU (mod).

Protocolo

A B. El usuarioA escoge un valorxA y calculayA = xA (mod p). Enton-

ces, enva aB: (,p,yA).

B A. El usuarioB escoge un valorxBy calculayB= xB (mod p) as como

tambin calcula la clave de sesin KAB= yxB

A (mod p).

Entonces, enva aA: (yB,CertB,EKAB (DB{yB,yA}),

donde {yB,yA} significa el resultado de aplicar una funcin de hash a los

parmetrosyB,yA.

A B. El usuarioA tambin puede calcular la clave de sesin KAB = yxA

B

(modp) y enva a A: (CertA,EKAB (DA{yA,yB})

En este protocolo,CertA = (IdA,EA,,p,DT(IdA,EA,,p)), dondeDT(IdA,EA,,p) es

la firma de una autoridad de certificacin Tsobre estos parmetros.

En el ltimo paso del protocolo, el usuarioA queda autenticado ante el usua-

rioB.


A B

(,p,yA)

yB,CertB,EKAB(DB{yB,yA})

CertA,EKAB(DA{yA,yB})


24/60


2.6. Otros protocolos: ISO, CCITT X.509, SSL

Para acabar este apartado, veamos otros protocolos que se pueden considerar

estndares:

1) ISO (CD 9798-3. 1991). Es equivalente al protocolo STS en el cual susti-

tuimos las exponenciales x,y por valores aleatorios RA,RB. Sin embargo, de

este modo obtenemos un protocolo de autenticacin pero sin intercambio de

claves.

Protocolo

A B. El usuarioA envaRA a B.

B A. El usuarioB envaRA, junto con (CertB,DB({RB,RA})), aA.

A B. El usuarioA envaB:CertA,DA({RB,RA})


A B

RA

RA,CertB,DB({RB,RA})

CertA,DA{RB,RA}

2) CCITT X.509. Es un algoritmo de intercambio de claves, con autenticacin,

de tres pasos y se basa en un sistema criptogrfico de clave pblica.

El usuario A que quiere intercambiar una clave KAB, con B, tiene una copia

autenticada deEB.

Protocolo

A B. El usuarioA enva aB: (SA,CertA,DA(SA)), donde

SA= (RA,IdA,EB(KAB)), yRAes un nmero aleatorio escogido por A.

B A. El usuarioB enva aA: (SB,CertB,DB(SB)), donde

SB= (RB,IdB,EA(KAB)), yRB es un nmero aleatorio escogido por B.

A B. El usuarioA enva aB: (RB,IdB,DA(SB,IdB)).

Evidentemente, B ha podido autenticar A y descifrando: DB(EB(KAB) = KAB,

obtiene la clave de sesin KABque emplear para comunicarse con A.


25/60



A B

SA,CertA,DA(SA)

SB,CertB,DB(SB)

RB,IdB,DA(SB,IdB)

3) SSL (Secure Socket Layer). Es un protocolo abierto creado por Netscape y

ha llegado a ser un estndar para Internet. Se implementa entre la capa de

aplicacin (HTTP, Telnet, FTP,...) y la capa de transporte (TCP).

El SSL es transparente para la aplicacin que lo utiliza y aade los siguientes

servicios seguros a una conexin TCP/IP:

Cifrado de datos usando los sistemas criptogrficos de clave privada: DES,

RC4.

Autenticacin, usando los sistemas criptogrficos de clave pblica: RSA,

DSA. Implementa tanto la autenticacin mutua emisor/receptor como la

de servidor/cliente.

Integridad de los datos mediante funcioneshashMAC (message authentica-

tion code): SHA, MD5.

Fases del SSL

Fragmentacin delmensaje en bloques demedida menor que 214bytes. TCP aadefiabilidad.

Posibilidad decompresin (opcional).

Clculo de un MAC. Cifrado de los datos y del

MAC (messageauthentication code).

Transmisin por TCP.

El protocolo SSL sigue los siguientes pasos:

1) A B. El usuarioA enva un valor aleatorioRA a B.

2) B A. El usuarioB enva aA: (RB,CertB,DB(RB,RA)).

3) A B. El usuarioA enva, opcionalmente, aB: (CertA,DA(RA,RB)).

4) B A. El usuarioB escoge una clave de sesinKABy enva aA: (EA(KAB),RA).

5) A B. El usuarioA enva aB:EKAB (RA).

En este ltimo paso, el usuario B cifra con la clave KAB, el valor aleatorio RA

que le haba enviadoA en el paso anterior.


Observaciones

El paso tercero esopcional.

En el cuarto paso,B haescogido la clave desesin,KAB.

En el quinto paso,A, cifra

con la claveKAB, el valoraleatorioRA que le habaenviadoB, en el pasoanterior.

A B

RA

RB,CertB,DB(RB,RA)

CertA,DA(RA,RB)

EA(KAB),RA

EKAB (RA)


26/60


2.7. Protocolos de identificacin de conocimiento nulo

En los protocolos de desafo-respuesta, vistos anteriormente, aunque el usua-

rio A no revele el secreto, el usuario B puede conseguir alguna informacin

durante el proceso.

Condiciones de unaprueba de conocimientonulo

1) SiA posee el secreto,siempre podr convencer aBque acepte su demostracin.

2) SiA no posee el secreto,la probabilidad que engae aBpuede hacerse tan pequeacomo se quiera, repitiendo elprocedimiento el suficientenmero de veces.

.

Definicin 2.3 (Prueba de conocimiento nulo).

Una prueba de conocimiento nulo es un proceso interactivo donde el

candidato convence al verificador, hasta un nivel aceptable, que cono-

ce, o tiene algn secreto, sin que el verificador pueda extraer ninguna

informacin de la prueba que no pudiera haber extrado por cualquier

otro procedimiento, con o sin la participacin del candidato o, incluso,

si este miente en la prueba.

Las pruebas de conocimiento nulo adoptan la forma de una demostracin

interactiva, implicando un cierto nmero de etapas y, en cada una de ellas, se

seguir el siguiente protocolo:

Protocolo bsico

A B. El usuarioA quiere probar algo al verificador B y le enva algn

elemento para su identificacin.

B A. El verificadorB presenta un desafo aA.

A B. El usuarioA tiene que efectuar unos clculos privadamente y enviar

al verificadorB una respuesta al desafo planteado.

Si alguna de las respuestas es incorrecta,Bdeduce queAno dispone del secreto

y rechaza su identidad. Por el contrario, si en todas las etapas la respuesta es

correcta, entoncesB acepta queA conoce (o tiene) el secreto.

Protocolo de Fiat-Shamir

Sea n = p1 p2, que todo el mundo puede conocer, generado por una terce-

ra parte de confianza Ty que mantiene secretos los valores de los nmeros

primosp1 y p2.

Cada usuarioU elige un elemento xU Zn y calcula yU = x

2U (mod n). As, la

clave secreta deA serxA y la clave pblica yA, que se registra en el directorio

pblico deT.


27/60


Protocolo

A B. El usuarioA genera al azar un valor r Zn, calculay1 =r2 (modn)

y lo enva a B, junto con un mensaje diciendo que quiere probar su iden-

tidad.

B A. El verificadorB enva aA un bit, al azar:y2 {0,1}.

A B El usuarioA calculay3 de la siguiente manera:

siy2= 0, entonces y3= r (mod n)

siy2 = 1, entoncesy3= r xA (modn)

y enva aB el valory3.

Finalmente, la verificacin la lleva a cabo el usuario B que comprueba que

siy2= 0, entoncesy23=r

2 (modn) =y1

siy2= 1, entonces y23=r

2 yA (mod n) =y1 yA (mod n)

Si no se cumple la verificacin, B rechaza la identidad de A.

Impersonacin

Un usuarioC impersonando a

Apuede enviar a B y1 = r2

yA(mod n). Entonces, podraresponder correctamentey3 = r, solo en el supuesto dequey2 = 1. Siy2 = 0nopodr efectuar los clculos.Por lo tanto, solo tiene unaprobabilidad de acierto de0,5 en cada ronda.

Este protocolo tiene que llevarse a cabo unas cuantas veces. Si se repite kveces,

la probabilidad que alguien impersone a A es 2k, y puede ser tan pequea

como queramos, dependiente del valor dek.


A B

y1 = r2

(mod n)

y2 {0,1}

y3

Ejemplo 2.5. Supongamos los valores, n = p1 p2 = 5 11 = 55; la clave secreta de A,xA = 13, y la clave pblica de A,yA = x

2A (mod n) = 13

2 (mod 55) = 4

Con estas premisas, el protocolo sigue los siguientes pasos:

A B. El usuarioA toma el valor r= 30 y calcula y1

=r2 (mod n) = 302 (mod 55) =20 y lo enva aB, junto con un mensaje diciendo que quiere probar su identidad.

B A. El verificadorB enva aA un bit, al azar: y2 {0,1}. Supongamosy2 = 1. A B. El usuarioA calculay3.

Como quey2= 1, entoncesy3= r xA (mod n) = 30 13 (mod 55) = 5 y lo enva aB.


28/60


Finalmente, la verificacin la lleva a cabo el usuarioB, que comprueba: puesto quey2= 1,siy23 = r

2 yA (mod n) = y1 yA (mod n).

Efectivamente: 20 4 (mod 55) = 25 = 52, y da por buena la identidad deA.

Protocolo de Schnorr

Este protocolo de identificacin se basa en el problema del logaritmo discreto

y hace intervenir a una tercera parte de confianza que desempea las siguien-

tes acciones:

Escoge dos primos p y q, de unos 1024 bits y 160 bits respectivamente, tales

queq | p 1. Tambin escoge un valor, tal que 1 p 1, de ordenq, y un

parmetro de seguridadt, tal que:t 40 y 2t q.

La autoridadTenva a cada participante, firmada mediante su clave privada,DT(p,q,).

Por otra parte, el usuario que se quiere identificar,A, dispone de su identifica-

cinIdA, su clave privada, que consiste en un nmeroa tal que 0 a q 1

y la correspondiente clave pblica es v = a (mod p); as como tambin del

certificado emitido porT:CertA= (IdA,v,DT(IdA,v)).

Protocolo

A B. El usuarioA escoge aleatoriamente un valorr, tal que 1 r (p 1) y

enva aB el CertAyx = r (modp)

B A. Despus de queB ha verificado la clave pblica de A, le enva el valor

etal que 1 e 2t.

A B. El usuarioA enva al verificadorB:y= (a e + r) (mod q).

El verificadorB acepta la identidad deA si y ve (mod p) =x.

Efectivamente, como es de ordenq, entonces:

y ve (mod p) = ae+r ve (mod p) =ae r ae (mod p) = r (mod p) = x


A B

CertA

,x= r (modp)

e: 1 e 2t

y= (a e + r) (mod q)


29/60


Ejemplo 2.6.

Supongamos que una tercera parte de confianzaTha escogido:

Los valores de los primosp = 103 yq = 17. Obsrvese que 10217

= 6.

Para encontrar el valor de busca un elemento primitivo en Zp; por ejemplo = 6y toma = 6 (mod 103) = 100. Efectivamente, de la construccin se deriva que elorden de es 17.

Para simplificar el ejemplo, omitiremos sin perder rigor el parmetro de seguridadt,t 40 y 2t q.

La autoridadTenva a cada participante copia autenticada de (p= 103,q= 17,= 100).

Los parmetros de A, aparte del identificador IdA, son su clave privada que suponemosa = 11 y su correspondiente clave pblica v= 10011 (mod 103) = 8. As, el certificadoemitido porTes: CertA = (IdA,8,DT(IdA,8)).

Protocolo

A B. El usuarioA escoge aleatoriamente un valorr= 5 y enva a B el CertA y x = 1005

(mod 103) = 66.

B A. Despus de queB ha verificado la clave pblica de A, le enva el valor que haescogido:e = 13.

A B. El usuarioA enva al verificador B:y= 11 13 + 5 (mod 17) = 12.

El verificador B acepta la identidad de A puesto que y ve (modp) = 10012 813

(mod 103) = 64 30 (mod 103) = 66 que coincide con el valor de x = 66 previamen-te calculado.


30/60


3. Transacciones electrnicas seguras:dinero electrnico

.

Un problema usual en el mundo de las transacciones es que un usuario A

quiera hacer una transaccin con un banco, B, de forma que, de una parte, B

debe poder autenticar a A y, por otra parte, A debe tener un certificado de B

que le asegure que este no negar la transaccin ya realizada.

El problema es fcil de resolver si utilizamos las firmas electrnicas como sus-

titutos del dinero, como propone David Chaum (a finales de los ochenta).

3.1. Protocolo de Chaum

Supongamos un comprador,A, que quiere interactuar conB, que ahora consi-

deraremos que es el banco, para pedirle poner disponer de una cierta cantidad

de dinero que, posiblemente ms tarde, querr utilizar para poder pagar algu-

na compra.

Protocolo

A B. El usuarioA genera, al azar, un nmerom grande y crea un docu-

mento personalizado,docAB, en el cual explica al banco que quiere dispo-

ner deXe. Firma el nmero escogido, calculandoDA(m) y usando la clave

pblica deB le enva: (IdA,EB(DA(m)),docAB)

B A. El banco recibe los mensajes, identificaA y leedocAB. Con la clave

pblica deA, y con su clave privada, puede recuperar el nmero m. Ahora

ya puede descontar losXe de la cuenta de A. El banco firmar el nmero

m, aadiendo un documento docBA firmado, DB(docBA). Enviar a A estasdos firmas, cifradas con la clave pblica de A: (EA(DB(m)),EA(DB(docBA))).

Al usuarioAle interesa tener (DB(docBA), y no solodocBA, para poder demostrar

ante terceros, en caso necesario, que el banco le ha descontado X e de su

cuenta y que estos corresponden a su nmero m.

Si ahora hacemos intervenir a un vendedor V, cuandoA va a comprar aV, el

correspondiente protocolo seguir los siguientes pasos:

A V. El comprador A enva a V: (IdA,DB(m),DB(docBA)). El vendedor

podr autenticar los mensajes firmados por B y conocer la identidad del

compradorA y el hecho de que dispone de un valor deXe.


31/60


Nota

El comprador A podra enviar estos valores cifrados, con EV, y firmados con DA:DA(EV(DB(m))) yDA(EV(DB(docBA))).

V B. El vendedorVenva al banco:DV(DB(m)). El banco comprueba que

el mensaje es correcto (correspondiente a un nmero firmado previamente

por el propio banco); deposita en la cuenta de V losXe y escribe en una

lista de nmeros caducados el nmero m, para evitar que le vuelva a ser

presentado otra vez.

B V. El banco enva firmado undocBVde la transaccin hecha al vende-

dorV:DB(docBV).

A partir de este momento, V ya puede dar la mercanca a A, junto con un

documento firmado,DV(docVA) de haber cobrado del banco.


A B

IdA,EB(DA(m)),docAB

EA(DB(m)),EA(DB(docBA))

A V

IdA,DB(m),DB(docBA)

B V

DV(DB(m)),DV(DB(docBA))

DB(docBV)

Ejemplo 3.1.

Utilizemos como parmetros de los criptosistemas RSA del usuario A, del banco B y delvendedorV, respectivamente:

nA= 7 17 = 119 yeA = 5; entonces (nA) = 6 16 = 96 y dA= 51 (mod 96) = 77.

Por lo tanto: clave pblica (eA,nA) = (5,119) y clave secreta(dA,nA) = (77,119).

nB = 5 11 = 55 y eB = 3; entonces(nB) = 4 10 = 40 y dB= 31 (mod 40) = 27.

Por lo tanto: clave pblica (eB,nB) = (3,55) y clave secreta (dB,nB) = (27,55).

nV= 3 19 = 57 yeV= 7; entonces (nV) = 2 18 = 36 y dV= 71 (mod 36) = 31.

Por lo tanto: clave pblica (eV,nV) = (7,57) y clave secreta (dV,nV) = (31,57).


32/60


El protocolo de Chaum seguir los siguientes pasos:

Protocolo

El usuarioA har:

Generar al azarm = 8.

CalcularDA(m) = mdA (mod nA) = 8

77 (mod 119) = 43.

Generar un documento personalizado, docAB en el que explica al banco que quiere dis-poner de 300 e.

A B. El compradorA enviar al banco: (IdA,EB(DA(m)),docAB).

Es decir: su identidad, EB(DA(m)) = EB(43) = 433 (mod 55) = 32 y el documento

docAB.

El banco,B, una vez recibido EB(DA(m)) = 32, har:

AplicarDB(EB(DA(m))) =DB(32) = 3227 (mod 55) = 43(= DA(m)).

AplicarEA(DA(m)) = EA(43) = 435 (mod 119) = 8(=m).

Descontar 300 e de la cuenta deA y firmar el nmerom:

DB(m) = DB(8) = 827 (mod 55) = 2.

Adems, el banco redacta un documento, docBAy lo enva firmado a A:DB(docBA).

B A. El banco enva aA:

EA

(DB

(m)) = EA

(2) = 25 (mod 119) = 32.

EA(DB(docBA)).

Supongamos ahora la intervencin del vendedor V, con cuentas en el mismo ban-coB.

Si A hace un pedido al vendedor por el valor de 300 e, le entrega DB(m) = 2 yDB(docBA).

V B. El vendedor entrega al banco:

DV(DB(m)) = DV(2) = 231 (mod 57) = 41 yDV(DB(docBA)).

El banco har:

Comprobar que el mensaje es correcto EV(DV(DB(m))) = DB(m) y que tambin lo esel documentodocVB.

Depositar en la cuenta del vendedor 300 e.

Escribir en una lista de nmeros caducados el nmero m para evitar que se puedavolver a usar.

B V. El banco enva firmado undocBVde la transaccin hecha al vendedor V:

DB(docBV)

A partir de este momento, Vya puede dar la mercanca a A , junto con un documentofirmado,DV(docVA) de haber cobrado del banco.


33/60


3.2. Transacciones sin rastro. Firmas digitales ciegas de Chaum

En el protocolo que acabamos de describir hay autenticidadpero noprivacidad.

El banco sabe (por el nmero m del billete) que A ha comprado a V y, en

general, podr seguir el rastro de las operaciones comerciales de A.

Para obviar este problema, D. Chaum (1992) propone una variante del proto-

colo usando firmas digitales ciegas, que consiste en hacer firmar al banco un

documento que contiene un nmero escondido.

De este modo, el usuario A sacar a la luz el nmero y lo har servir junto

con el documento firmado por el banco, cuando le convenga. Por otra parte,

el banco no sabr a quin corresponden los nmeros de los billetes que se

utilizan.

Nivel de seguridad de lasfirmas ciegas

Las firmas ciegas garantizanla integridad,confidencialidad yautenticidad de los datos, almismo tiempo que segarantiza el anonimato delcomprador.El comprador est protegidoante posibles actuacionesfraudulentas de falta de

entrega de mercancas oservicios por parte devendedores, puesto que encualquier momento elcomprador puede revelar suidentidad y, en este caso,seguir la traza del flujo deldinero.

El mtodo de Chaum es vlido para cualquier sistema criptogrfico de clave

pblica (como RSA) que cumpla: EU(xy) = EU(x)EU(y) y DU(xy) = DU(x)DU(y)

para cualquier usuarioU.

Vamos a desarrollar este protocolo suponiendo que estamos usando el cripto-

sistemaRSA.

Protocolo

A B. El usuarioA, antes de dar el nmero m al banco, selecciona otro

nmero grande,k, escogido al azar y del cual puede calcular k1 (mod nB).

El usuario A calcula EB(k) y enva: m EB(k) (modnB), firmado y secreto a

B. Es decir, enva aB:EB(DA(m EB(k)).

B A. El banco descifra y autentica el mensaje recibido y obtienem EB(k)

(modnB). A continuacin firma este mensaje calculando DB(m EB(k)) =

k DB(m) (mod nB). (Observar que el banco no conoce el nmero m que

acaba de firmar, solo conoce k DB(m) (mod nB)).

Ahora el banco devuelve, como en el caso general, un documento a A,

docBA, y tambin el nmero firmadok DB(m) (mod n).

El usuario A calcula k DB(m) k1 (modnB) = DB(m) y obtiene un nmero

firmado por el banco que, cuando el vendedor lo presente al banco, ser hecho

efectivo y, adems, el banco desconocer al propietario del nmero del billete.


A B

EB(DA(m EB(k)))

k DB(m) (mod nB),docBA


34/60


Simplificacin

Para ms claridad en lospasos del protocolo, noshemos ahorrado firmarlo ycifrarlo.

El banco no conoce elnmero que firma

Con esta operacin, el bancoha firmado el mensajeoriginalm = 65, sin conocersu valor. Observar que21 esel mismo valor que obtendrael banco si hubiera firmadocon su clave privada elmensajem = 65: Es decir:6561 (mod 851) = 21.

Ejemplo 3.2. (Firma ciega de Chaum)

Adesea que el Banco, B, le firme el mensajem = 65.

Supongamos que las claves pblica y privada de B son:nB = 851,eB = 13,dB = 61.

(Los parmetros deB son:pB = 23,qB = 37, (nB)= 792, todos ellos guardados en un lugarseguro, junto condB).

Supongamos queA escogek = 51, y calcula 511 (mod 851) = 267.

A B. El usuarioA calcula:

M= m keB (mod nB) = 65 5113 (mod 851) = 65 458 (mod 851) = 836 y envaMal

Banco.

B A. El Banco hace:

firma este mensaje recibido,M, con su clave privada:

MdB (mod n)B= 83661 (mod 851) = 220,

y lo enva a A, junto con un documentodocBA.

El usuarioA, como conocek1 (mod nB) = 267, puede calcular: 276 220 (mod 851) = 21,que es la firma del banco dem, sin que el banco conozcam.

3.3. Sistemas de pago electrnicos

Con la aparicin y generalizacin del comercio electrnico se ha hecho nece-

saria la creacin de sistemas electrnicos de pago adaptados a la situacin no

presencial de los usuarios involucrados.

Los sistemas de pago electrnico todava utilizan, mayoritariamente, dinero

asociado a una tarjeta emitida por una entidad financiera, pero hoy ya pode-

mos hablar de dinero electrnico, en el sentido que acabamos de ver, que lo

hace un sistema de pago ms adecuado, y ms seguro, en las transacciones

electrnicas.

Los sistemas de pago electrnico en la actualidad son, bsicamente:

Cheques electrnicos. Sustitutos de los cheques de papel, consisten en un

mensaje con una firma digital, representando un valor monetario, que se

hace efectivo a travs de una tercera parte de confianza y hace uso de las

redes interbancarias existentes.

Moneda electrnica. Sustituta de la moneda fsica que debe preservar el

anonimato del comprador, permitiendo realizar pagos que no queden re-

gistrados y no vinculen a los usuarios con sus compras. Cuando la transfe-

rencia se haceoff-line, se deber garantizar la que sea posible la transferen-

cia y la seguridad frente a la falsificacin o del uso de la misma moneda en

ms de un pago.


35/60


Tarjeta de crdito. Aun cuando todava es el sistema de pago ms utiliza-

do, los receptores se pueden poner en contacto con el banco para verificar

la disponibilidad de fondo, aunque, normalmente, no se realiza la verifi-

cacin de la identidad del usuario. A diferencia de la moneda electrnica,

las tarjetas de crdito identifican a su propietario y, adems, los pagos se

pueden vincular entre ellos.

Micropagagos. Diseados especialmente para reducir los costes de comu-

nicacin, almacenamiento y procesamiento relacionados con el pago cuan-

do las cantidades a transferir son pequeas. De este modo se permite un

cierto relajamiento de las medidas de seguridad, puesto que los riesgos es-

tn ms controlados, y en la mayora de casos el anonimato del usuario

que realiza el pago se sacrifica para reducir costes.

Los sistemas de pago vienen definidos por las reglas mediante las cuales los

participantes en una operacin de compra/venta (comprador, bancos emisor

y adquirente, comercio, pasarela de pago y autoridad certificadora) intercam-

bian dinero y productos o servicios.

Los procedimientos, o pasos, en los sistemas de pago con moneda electrnica

son, bsicamente:

1) Establecimiento de la cuenta. Es una operacin que se realiza una sola

vez, en la cual se vincula la identidad o el seudnimo del comprador a lanueva cuenta. El comprador dispondr de un par de claves correspondientes a

un sistema criptogrfico de clave pblica y de un certificado autenticando su

clave pblica.

2) Retirada de fondo: obtencin de la moneda electrnica . La entidad fi-

nanciera emisora carga en la cuenta del comprador el valor solicitado pre-

viamente para llevar a cabo una compra o el valor de la moneda electrnica

solicitada. La moneda electrnica puede ser de dbito si se extrae su valor de

la cuenta del usuario antes del pago (este procedimiento requiere la autenti-

cacin del usuario), o de crdito si el pago se hace posteriormente y, en estecaso, la identificacin de la cuenta del pagador se realiza durante el depsito.

3) Pago. El comprador entrega la informacin necesaria y suficiente al comer-

cio para hacer el pago de los bienes que quiere comprar. Tambin puede dar

esta informacin a la pasarela de pago.

4) Depsito. La entidad financiera adquirente recibe la informacin y cobra

de la entidad emisora, a travs de la red financiera una vez ha comprobado

que no se ha depositado dos veces la misma moneda. Finalmente, ingresa el

valor de la compra, o de las monedas electrnicas implicadas, en la cuenta del

comercio. En sistemas que permiten la transferencia de las monedas electr-

nicas tambin puede optar por transferir la moneda a un tercero.


36/60


Una primera clasificacin de los sistemas de pago puede venir marcada por

el importe a transferir. As hablaremos de micropagos, cuando el importe de

la operacin es inferior a los 10 e. Por encima de esta cantidad se hablar

de macropagos. Aunque todo sistema de pago debe satisfacer una serie de

requisitos de seguridad, es obvio que en el caso de micropagos estos sern

ms laxos para que el coste de la seguridad sea proporcionado al valor que

se transfiere. No es lo mismo proteger un pago de 10 e , que proteger uno de

100.000 e.

Una segunda clasificacin es la de sistemas on-liney sistemasoff-line. Los pro-

tocoloson-lineexigen el acceso a un servidor para cada transaccin.

Para los sistemas de pagoon-line, el concepto de dinero electrnico, propuesto

por D. Chaum, permite conjugar las prestaciones que ofrecen las redes tele-

mticas con las propiedades intrnsecas de los sistemas de pago tradicional:anonimato, privacidad y dificultad de falsificacin. La diferencia entre el di-

nero electrnico y el de curso legal actual es su soporte, que pasa de ser fsico

a una cadena de bits.

La no falsificacin, o evitar el doble uso, del dinero electrnico exige una

verificacin, contra una cierta base de datos, para asegurarse de que no haya

sido utilizado previamente. Si la verificacin se hace off-line necesita mayor

proteccin del anonimato, es decir, que no se pueda establecer ningn vnculo

entre el dinero electrnico y la identidad del propietario, que si se haceon-line.

Tal como hemos visto antes, estos sistemas se basan en firmas ciegas.

En general, el dinero electrnico est pensado para ser utilizado en Internet

o, actualmente, en sistemas basados en terminales mviles. Se trata de reem-

plazar las monedas y billetes de curso legal por un sistema informacional,

manteniendo las prestaciones de anonimato y no trazabilidad utilizando crip-

tografa de clave pblica. Los billetes y monedas electrnicas se almacenan

localmente, pero se requiere que el usuario tenga una cuenta bancaria asocia-

da, a partir de la que se descontar la cantidad que corresponda al billete o

moneda electrnica.

El funcionamiento general de este sistema es parecido al que se ha descrito en

el protocolo de Chaum:

1) El comprador solicita monedas electrnicas. Estas se identifican con un n-

mero de serie. Este nmero permite garantizar la unicidad puesto que permite

detectar duplicidades. El anonimato del propietario de las monedas electrni-

cas se protege mediante firmas ciegas.

2) Una vez el banco ha descontado el valor correspondiente de las monedas

electrnicas entregadas al comprador, estas se almacenan en el terminal del

comprador.


37/60


3) Cuando el comprador hace el pedido de bienes o servicios al vendedor, le

entrega las monedas electrnicas correspondientes al valor de la compra.

4) El vendedor, antes de servir el pedido, entrega las monedas electrnicas al

banco y le solicita su validacin.

5) El servidor del banco accede a una base de datos donde consta el nmero

de serie de todas las monedas que han sido utilizadas. Con esta operacin se

detecta si ha habido doble uso. Si no hay duplicidad, se responde al vendedor

sobre la autenticidad de las monedas electrnicas y, si se realiza la operacin

de compra, automticamente se ingresa el importe en su cuenta y se aade el

nmero de serie correspondiente a la base de datos correspondiente.

6) El vendedor entrega los productos al comprador.

A nivel de seguridad, se garantiza la integridad, confidencialidad y autenti-

cidad, al mismo tiempo que se facilita el anonimato del comprador. El com-

prador est protegido ante posibles actuaciones deshonestas de vendedores en

cuanto a no entregas de productos se refiere, puesto que en un momento da-

do el comprador puede desvelar su identidad y en este caso se podra trazar el

flujo del dinero.


Comprador Banco

solicita monedas electrnicas

descuento del valor de las monedas

Comprador Comercio

pedido de bienes o servicios

Comercio Banco

validacin de las monedas electrnicas

valda o rechaza

Comercio Comprador

si el banco valda, sirve bienes o servicios


38/60


4. Protocolos de transferencia inconsciente.

La transferencia inconsciente o transcordada (oblivius transfer) consiste en la

transferencia de un secreto entre dos usuarios A y B de forma que la proba-

bilidad de que B lo obtenga es de un 50 %, sin queA pueda saber si B lo ha

obtenido, o no.

Estos tipos de protocolos dan lugar a otros protocolos ms complejos, como

los de compromiso de bits o los de prueba de conocimiento nulo y, en

general, a los protocolos que permiten la firma electrnica de contratos.

4.1. Protocolo de Rabin

El secreto consiste en la factorizaci del valor nAde la clave pblica del sistema

RSA deA.

Protocolo

B A. El usuarioBescoge un valor x, 1 x nA 1, y enva a A:z = x2

(modnA)

A B. El usuarioA calcula las cuatro races cuadradas de:

z (mod nA) = {x,nA x,y,nA y}

y enva una de ellas a B (esto solo lo puede hacer A, porque conoce los

valorespA y qA, con los cuales ha calculadonA).

Seavla raz enviada aB.

El usuarioB comprueba sivcoincide cony, o con nAy. Si coincide, se podr

factorizarnA; de lo contrario no se podr.

Resumen de las transacciones del protocolo

A B

z= x2 (modnA)

v= z1/2 (mod nA)

Nota

Hay una equivalencia computacional entre factorizar nA = pA qA y calcular races cua-dradas en ZnA , como queda justificado en el cuadro y en el teorema siguientes.


39/60


.

Cuadrados y races cuadradas en Zp, dondep es un nmero primo

Si Zp puede pasar que exista, o no,x Zp tal quex2 =.

En el primer caso se dice que es un residuo cuadrtico En el segundo,

se dice que es un residuo no-cuadrtico.

A excepcin de 0 Zp, hay exactamente p1

2 residuos cuadrticos (QR)

y p12 residuos no cuadrticos (QNR) enZp.

Si Zp, esp1

2 =

8>>>:

1 si es QR

1 si es QNR

Es computacionalmente eficiente (hay un algoritmo determinista-

polinomial) saber si Zp es QR o QNR.

No es computacionalmente eficiente encontrar un elemento QNR.

De todos modos, s hay algoritmos no deterministas de complejidad

polinmica que resuelven el problema de manera sencilla.

Es computacionalmente eficiente calcular la raz cuadrada de un ele-

mento QR.

Cuadrados y racescuadradas en Zn, donden= p1 p2

Hay exactamente n14

elementos QR en Zn y cada

uno de ellos tiene,exactamente, cuatro racescuadradas.Ejemplo:En Z15, el elemento4 Z15es un QR y tienecuatro races, que son:{2,13,7,8}.Los QR en Zn, son aquelloselementos en los que elmdulop1y, tambin, elmdulop2, son QR.

.

Teorema 4.1. Si n = p1 p2, dondep1y p2son nmeros primos diferen-

tes e impares, y si y son races cuadradas, esencialmente diferentes,

(es decir = ), de un cierto QR, entonces:

mcd( + ,n) =p1, omcd( + ,n) = p2

Probabilidad de queB

conozca nA es 1/2

Del teorema tambin sededuce que la probabilidadde queB conozcanA = p1 p2es1/2 puesto que el espaciode muestras tiene4resultados posibles (las4races cuadradas dez), de lascuales solo2 sirven parafactorizarnA (yy nAy). As,si cada bit de un secreto setransmite mediantetransferencia inconsciente, laprobabilidad de queB pueda

conocer el secreto es de2t,sites el nmero de bits delsecreto.

Ejemplo 4.1.

SupongamosnA = 5 11 = 55.

B A. El usuarioB escoge un valorx = 13 y enva a A:z = 132 (mod 55) = 4.

A B. El usuarioA calcula las cuatro races cuadradas de 4 (mod 55) = {13,55 13,2,55 2}= {13,42,2,53}y enva una de ellas a B.Seav= 2 la raz enviada.

El usuario B comprueba si v= 2 coincide con y, o con 55 y. Como coincide, se podrfactorizarnA = 55 puesto que mcd(13 + 2,55) =mcd(15,55) = 5.

Igual hubiera pasado siv= 53, puesto que mcd(13 + 53,55) = mcd(66,55) = 11, que es unfactor denA= 55.

Si se hubiera enviado v= 42 no se hubiera podido factorizar nA, puesto que mcd(13 +42,55) =mcd(55,55) = 55.Igualmente parav= 13, puesto quemcd(13 + 13,55) =mcd(26,55) = 1.


40/60


4.2. Protocolos de compromiso de bits

En este protocolo, un usuario A se compromete frente a otro usuario B con

un valor, de tal manera queA no lo pueda cambiar y B no lo pueda descubrir

hasta que el propioA no haya abierto el compromiso.

Es un protocolo til en otros protocolos, como el de lanzamiento de monedas

o el de pruebas de conocimiento nulo, y debe cumplir las siguientes propie-

dades:

Se debe poder comprometer cualquiera de los dos valores posibles para

cada bit.

De la apertura del compromiso,B solo obtendr el valor del bit compro-

metido.

No se debe poder modificar el valor comprometido, aunque se cambie la

manera de abrir el compromiso.

El usuarioB no debe poder conocer nada sobre la manera de abrir los com-

promisos aunque haya visto abrir algunos.

Otros protocolos decompromiso de bits

En la literatura hay otrasimplementaciones deprotocolos de compromisode bits, usando sistemascriptogrficos de clavesecreta, logaritmos discretos,funciones de hash, residuoscuadrticos o, incluso, grafosno isomorfos.

1) Protocolo: Usando transferencia inconsciente

Para comprometer un bit b, el usuario A escoge n bits aleatorios b i, tales que

b1 b2 bn = b, y se siguen los tres pasos siguientes, donde es la

operacin XOR.

Protocolo

1) Compromiso: El usuarioA enva aBcada bitbipor orden, mediante trans-

ferencia inconsciente.

2) Apertura: El usuarioA enva aB todos los bitsbi.

3) Verificacin: El usuario B compara los bits bi, recibidos dentro del plazo

del compromiso, con los correspondientes de la apertura.

Nota

La probabilidad de fraude, por parte de A, es menor que 12

. Si se ejecuta el protocolo k

veces, la probabilidad de fraude ser menor que 2k.

2) Protocolo: Lanzamiento de moneda por telfono

El protocolo de Rabin puede ser utilizado para el problema de tirar una mone-

da al aire, y resolver una apuesta entre dos usuarios A y B de manera telem-

tica.


41/60


Apuesta

Cara B puede factorizarn

Cruz B no puede factorizarn

Protocolo

A B: El usuarioA construye, al azar, dos nmeros primos, diferentes y gran-

des:p1,p2 y calculan = p1 p2. Envan al usuarioB.

B A: El usuario B escoge, al azar, un elemento primitivo, Zn, calcula

= 2 (mod n) y enva al usuarioA.

A B: El usuario A calcula las cuatro races cuadradas de y enva una al

usuarioB. Sea la raz enviada.

B A: El usuarioB le dice aA si ha salido CARA o CRUZ.

Tal como hemos visto antes, si = , el usuario B podr factorizarn. De lo

contrario, si = , no podr factorizarn.


A B

n

= 2 (modn)

= 1/2 (modn)

CARA o CRUZ

Este protocolo fue propuesto por Mario Blum (1982) y se trata, tal como he-

mos visto antes, de resolver una apuesta entre dos usuarios A y B, distantes

entre s, mediante el lanzamiento de una moneda a cara o cruz. Si uno de los

dos hace trampa, sin necesidad de un tercero el otro lo puede detectar.

Puede haber dos casos posibles de trampa:

trampa de A

El usuarioA lanza la moneda y anota el resultado.


42/60


El usuarioB hace su apuesta y se la dice a A.

El usuarioA le dice aB, que justamente ha salido lo contrario.

trampa de B

El usuarioA lanza la moneda y anota el resultado.

El usuarioB hace su apuesta y se la dice a A.

El usuarioA le dice aB, que justamente no ha salido lo que l haba dicho.

El usuarioB niega su primera apuesta y replica a A dicindole que precisa-

mente lo que ha salido era lo que l haba apostado.

Cmo resolver el problema de manera que si uno hace trampa el otro lo

detecte? Las soluciones pasan por el protocolo de transferencia inconsciente

de Rabin que hemos visto, o el protocolo propuesto por Blum, basado en una

funcin unidireccional sobre un conjunto de nmeros tal que la mitad deellos son pares y la otra mitad impares.

Nmeros de Blum

Son los nmerosn = p1 p2tales que ambos primosp1 yp2 son congruentes con 3 delmdulo 4.En este caso, aparte del ceroy de p1 y p2, la mitad de losresiduos cuadrticos en Znson pares y la otra mitad son

impares. Adems, el valor dezidentificay, ya que de lascuatro races cuadradas de z,nicamente hay una que, asu vez, sea un residuocuadrtico.

El esquema general del protocolo, una vez el usuarioAha escogido un nmero

de Blum:n = p1 p2 es:

Protocolo

A B. El usuarioAescoge un valorx Zny calculay= x2 (modn) y z = y2

(modn). El usuarioA envaz a B.

B A. El usuarioB, una vez recibido z, apuesta por la paridad de y (es

decir, si es o no un nmero par).

A B. El usuarioA le informa si ha acertado o no. Adems le muestra los

valores dex y y, al mismo tiempo que le demuestra quen es un nmero de

Blum.

El usuarioB comprueba quey= x2 (modn) yz = y2 (modn).

Ambos usuariosA yB han actuado con un 50 % de probabilidad de engao en

el primero y el segundo paso del protocolo.


A B

z

paridad(y)

{S o No},x,y,p1,p2


43/60


Ejemplo 4.2.

El usuarioA escoge un nmero de Blum, por ejemplo: n = 7 11 = 77.

A B. El usuarioA escoge un valorx = 13 y calcula:y= x2 (mod n) = 132 (mod 77) = 15 y

z= y2 (mod n) = 152 (mod 77) = 71.Aenvaz a B.

B A. El usuarioB, una vez recibido z, apuesta por la paridad de y.Suponemos que apuesta porypar.

A B. El usuarioA le informa de que no ha acertado en la apuesta.Para demostrarlo, le enva los valores de x = 13,y= 15 y n = 7 11 = 77.El usuarioA le demuestra quen es un nmero de Blum y B puede verificar el valor dez, a partir de los valores de x y yrecibos.

En este caso,B comprueba que se haba equivocado en su apuesta.

4.3. Firma electrnica de contratos: Protocolo de Even

Se trata de permitir la firma electrnica de un documento entre dos usuarios

AyB, sin intermediarios, de forma que se cumplan estas dos condiciones:

Que ambos usuarios queden obligados a culminar la firma, solo a partir de

un punto del protocolo.

Que la firma no pueda falsificarse y, adems, pueda ser comprobada por elotro usuario.

1) Protocolo bsico

Suponemos que el usuario A dispone de dos claves secretas y las correspon-

dientes claves pblicas de un sistema criptogrfico de clave pblica: (EA1,DA1);

(EA2,DA2).

Suponemos que el usuarioB elige una clave secreta KB.

Transferenciainconsciente

Los pasos de este protocolose corresponden bsicamentecon una transferenciainconsciente.

A B. El usuarioA enva aB sus dos claves pblicasEA1 y EA2.

B A. El usuarioB escoge una de las dos claves y cifra su clave KB, en-

viando el resultado a A.

A B. El usuarioA escoge una de sus dos claves privadas y descifra lo que

ha recibido deB.

A B. El usuarioA cifra el primer bloque del mensaje a firmar, usando la

supuesta clave encontrada en el paso anterior, y lo enva a B.


44/60


El usuarioB descifrar con la claveKB el bloque de firma recibido.

El usuario A repetir el tercero y cuarto paso para cada bloque de firma y B

siempre descifrar con la claveKB el bloque de firma recibido.

Cuando se hayan acabado todos los bloques de firma, el usuario A repetir el

cuarto paso, utilizando ahora la otra clave privada, y B descifrar con la clave

KB el bloque de firma recibido.

.

SiA y B han escogido al azar la misma clave (con una probabilidad del

50%),B descifrar un mensaje con sentido en la primera ronda. Si no,

recibir un mensaje sin sentido y tendr que esperar hasta recibir el

ltimo bloque de la segunda ronda para obtener el texto en claro.

Sin embargo, A no tiene ninguna manera de saber cundo B ha podi-

do descifrar correctamente el criptograma, lo cual le fuerza a acabar el

protocolo.

2) Protocolo de Even

Este protocolo se basa en sistemas criptogrficos de clave privada y sigue los

siguientes pasos:

Inicialmente, tanto el usuarioA como el usuarioB escogen entre un conjunto

de 2nclaves de un sistema criptogrfico de clave privada:

El usuarioA escoge el conjunto {K1,K2, ,Kn,Kn+1, ,K2n}, tomadas en pare-

jas: {(K1,Kn+1),(K2,Kn+2), ,(Kn,K2n)}.

El usuario B escoge el conjunto {K1 ,K2 , ,K

n ,K

n+1, ,K

2n}, tomadas en pa-

rejas {(K1 ,Kn+1),(K

2 ,K

n+2), ,(K

n ,K

2n)}.

Protocolo

A B. El usuarioAcifra un mensajeMA, conocido porB, con las 2nclaves:

EK1 (MA),EK2 (MA),...,EK2n (MA) y enva los 2ncriptogramas ordenados a B.

El usuarioAse comprometer, ms adelante, a firmar el contrato siBpuede

presentarle algn par de claves (Ki,Kn+i).

B A. El usuarioBcifra un mensajeMB, conocido porA, con las 2nclaves:

EK1 (MB),EK2

(MB),...,EK2n

(MB) y enva los 2ncriptogramas ordenados a A.


45/60


El usuarioBse comprometer, ms adelante, a firmar el contrato siApuede

presentarle algn par de claves (Ki,Kn+i).

A B. El usuarioA enva aBcada par (Ki,Kn+i) ordenados mediante una

transferencia inconsciente; es decir, enviando Ki oKn+i con igual probabi-

lidad.

B A. El usuario B har lo mismo, enviando a A, ordenadamente, los

pares (Ki,Kn+i)

Nota

En este punto A y B tienen la mitad de las claves uno del otro.

Si la longitud de cada clave es de L bits, entonces los usuariosA y B realizan elsiguiente bucle, 1 i 2n, para las clavesKi y K

i que no se han usado en los

pasos anteriores:

.

Algoritmo 4.2

for 1 j L

begin

Aenva aB el bit j-simo de todas estas claves Ki

Benva aA el bit j-simo de todas estas claves Ki

end

Observar que el algoritmo es parecido al del protocolo de compromiso bit a

bit. Al realizar este bucle completo, A y B tienen las 2n claves uno del otro y

se supone que pueden firmar el contrato.


A B

EK1 (MA),EK2 (MA),...,EK2n (MA)

EK1 (MB),EK2

(MB),...,EK2n

(MB)

{Kio Kn+i}

{Ki o Kn+i}


46/60


4.4. Protocolo de correo electrnico certificado

Pese a que los sistemas actuales de correo electrnico permiten el acuse de

recibo por parte del receptor (el emisor pide al receptor que le comunique que

ha recibido el correo que le ha enviado, sin que esto implique la aceptacin

de su contenido); cuando enviamos un correo electrnico, cmo podemos

estar seguros de que el mensaje enviado ha llegado al destinatario autorizado

y solo l conoce el contenido?

La propuesta de este protocolo es la implementacin del correo electrnico

certificado.

As, si un usuario A desea enviar un mensaje electrnico como correo certi-

ficado a un usuario B, le descubrir el mensaje, es decir, le enviar la clave,

solo despus de que el usuarioB le haya enviado el acuse de recibo correspon-diente.

Esto es tal como sucede con el correo regular certificado; antes de ver el men-

saje hemos firmado que hemos recibido el sobre que lo contiene.

El protocolo que sigue es muy parecido al que hemos visto de Even para la

firma de contratos.

Protocolo

El usuario A escoge aleatoriamente n+ 1 claves {a0,a1, ,an} de un sistema

criptogrfico de clave privada. Las claves {a1, ,an} sern la parte izquierda

de la claveKEAi , y la parte derecha,KDAi ser {an+1,an+2, ,a2n}, dondean+i =

a0 ai, para 1 i n.

Los usuariosA y B se ponen de acuerdo en un mensaje de validacin V.

El usuario A, con la clave a0 cifra el documento M: C0 = Ea0 (M) y despus

cifra el mensaje de validacin Vcon las 2n claves secretas; {KEAi , KDAi } para

1 i n:

Cifrado de validacin de la parte izquierda: VEAi =EKEAi (V).

Cifrado de validacin de la parte derecha: VDAi =EKDAi (V).

A B. El usuarioA enva aB, el valor C0y los pares ordenados (VEAi ,VDAi ),

para 1 y n.

De forma similar, el usuario B genera n pares de claves KEBi y KDBi . Tambingenerar n pares de mensajes acuse de recibo de la parte izquierda: REi y

acuse de recibo de la parte derecha: RDi y cifra las parejas (REi,RDi) en el


47/60


sistema criptogrfico de clave privada, con las claves (KEBi ,KDBi ) obteniendo

(EBi ,DBi ).

B A. El usuarioB enva aA las parejas ordenadas (EBi ,DBi ).

A B. Mediante una transferencia inconsciente, el usuario A enva a B

una de las dos claves secretas:KEAi oKDAi .

B A. Mediante una transferencia inconsciente, el usuario B enva a A:

KEBi oKDBi .

Este proceso se repite hasta haber enviado los n valores de las claves de cada

usuario.


A B

C0,{VEAi ,VDAi }

{(EBi ,DBi )}

{KEAio KDAi }

{KEBio KDBi }

Comprobacin:

El usuario B usa las claves enviadas por A, KEA1 o KDA1, para comprobar

que al descifrarDKEAi (V) oDKDAi (V) obtiene el mensaje de validacinV.

El usuarioA usa las claves enviadas porB,

criptografia_avanzada_(modulo_3)

Documents