Este documento analiza los sistemas de dinero electrónico y propone mejoras al esquema de Brands. Resume que 1) identifica los servicios que ofrece el banco emisor en el esquema de Brands, 2) clasifica estos servicios como verificables o no verificables dependiendo de si el usuario puede demostrar incumplimientos, y 3) propone nuevos protocolos para los servicios no verificables de modo que también sean verificables, mejorando la seguridad general del sistema sin cambiar el formato de la moneda.

1. Análisis de los sistemas de dinero electrónico. Mejoras al esquema
de dinero electrónico de Brands
Macià Mut Puigserver, Josep Lluís Ferrer Gomila
Llorenç Huguet i Rotger y Magdalena Payeras Capellà
Departament de Ciències Matemàtiques i Informàtica
Universitat de les Illes Balears
Carretera de Valldemossa km 7.5, 07071 Palma, España
e-mail: macia.mut@uib.es, Tlf.: +34-971173246
Resumen. El comercio electrónico no está exento de reticencias por parte de sus usuarios respecto
a la seguridad de sus transacciones en Internet. Uno de los apartados que requieren mayor atención
en el aspecto de seguridad son los sistemas electrónicos de pago. Han aparecido bastantes
propuestas de esquemas de dinero electrónico que, sin embargo, no han tenido un gran impacto en
el mercado. En el artículo demostramos como un esquema cualquiera de dinero electrónico puede
mejorar sus características de seguridad sin necesidad de modificar el formato de la moneda.
Damos a los servicios ofrecidos por el Banco el carácter de verificable, lo cual debe ayudar a
vencer la reticencias de los usuarios para utilizar la red para sus transacciones comerciales con
dinero electrónico, ya que dispondrán de evidencias que les permitirán acudir a una autoridad
legalmente establecida en caso de que surjan disputas a resultas de eventos o acciones rechazadas
por parte de Banco. Estas mejoras se hacen sin tener que cambiar el formato de la moneda, esto
significa que no perdemos ninguna de las propiedades que ofrece el esquema original y que
añadimos nuevas características de seguridad al sistema.
1 Introducción
Internet está en camino de convertirse en un lugar donde se dan cita gran cantidad de gente que realiza
sus transacciones comerciales en la red. Este auge del comercio electrónico no está exento de
reticencias por parte de sus usuarios respecto a la seguridad de sus transacciones en Internet. La
seguridad en el comercio electrónico es exigida por múltiples motivos, pero uno de los apartados que
requieren mayor atención en el aspecto de seguridad son los sistemas electrónicos de pago.
Tanto los clientes como los comerciantes están esperando algún tipo de sistema de pago con dinero
electrónico cuyas características básicas de seguridad sean similares al esquema convencional del
dinero en efectivo. Han aparecido bastantes propuestas de esquemas de dinero electrónico que, sin
embargo, no han tenido un gran impacto en el mercado.
Normalmente el aumento de la eficiencia en estos esquemas, con el objetivo de parecerse a los
esquemas convencionales de dinero en efectivo, implica una disminución de la seguridad del sistema
[1, 6, 7, 8, 9, 10]. En este artículo vamos a aumentar la seguridad de un sistema de dinero electrónico.
En distintos documentos y publicaciones se hace referencia a la importancia de una clara definición y
análisis de los servicios que prestan las terceras partes de confianza (TTP – Trusted Third Party) en los
protocolos de seguridad y de la necesidad de reducir la confianza que deben depositar los usuarios en
ellas para aumentar la seguridad del sistema y además de que su intervención sea off-line para mejorar
la eficiencia del protocolo. También se apunta la importancia de la creación de métodos apropiados
para resolver las disputas que puedan aparecer. Con todo esto se pretende que los usuarios adquieran
una mayor confianza en sus transacciones electrónicas [3, 5, 11, 12, 13].
En el caso de los esquemas de dinero electrónico, el Banco emisor actúa como una TTP. En el
artículo clasificaremos cada uno de los servicios que ofrece el Banco en un esquema de dinero
electrónico. El análisis se hará desde el siguiente punto de vista: un servicio calificado como
“verificable” implica un menor depósito de confianza que uno de “no verificable” ya que consideramos
que un servicio es verificable si el usuario puede demostrar el incumplimiento del servicio (si se da el
caso) por parte del Banco delante de a otra TTP (por ejemplo, delante de un juez) [2, 3, 5, 13, 14, 15].
El objetivo de este análisis es obtener una mejora de las características del sistema, con la intención de
incrementar su seguridad. Para ver su aplicación práctica sobre cómo podemos realizar estas mejoras,

2. hemos aplicado el análisis al modelo básico desarrollado por Brands en [1]. Este modelo es utilizado
como referencia bibliográfica en muchos artículos referentes a esquemas de dinero electrónico y ha
sido usado como modelo básico por otros investigadores [6, 7, 8, 9, 10]. Analizaremos cada uno de los
servicios que ofrece el Banco en este esquema de dinero electrónico y, para los servicios “no
verificables”, propondremos nuevas soluciones para convertirlos en “verificables”, mejorando, por
tanto, la seguridad global del sistema para sus usuarios. Esta mejora se hace sin tener que cambiar el
formato de la moneda propuesto en [1], esto significa que no sólo no perdemos ninguna de las
propiedades que ofrece el esquema original sino que añadimos nuevas características de seguridad al
sistema.
En la segunda sección de este articulo revisaremos el esquema de Brands e identificaremos los
servicios que presta el Banco en su modelo de dinero electrónico. En la tercera sección clasificaremos
estos servicios de seguridad y veremos qué alternativas podemos ofrecer para mejorar su calidad en
caso de que sean clasificados como “no verificables”.
2 Servicios del Banco emisor en el esquema de dinero electrónico
2.1 El esquema de Brands
En el protocolo básico original definido en [1] es:
1.
2.
3.
4.
5.
Inicialización del sistema. El Banco(B) inicializa los parámetros del sistema y define sus
*
primitivas criptográficas: B genera el vector generador (g, g1, g2) de Gq (Gq⊂ Ζp ) y elige
*
su secreto x ∈R Ζp . B también elige H y H0 funciones de hash libres de colisiones. B
genera la base de datos de cuentas de usuarios y la base de datos de depósitos de monedas
x
gastadas. La clave pública de B es h = g .
Obertura de una cuenta. El usuario(U) presenta sus credenciales a B y crea una cuenta a
u1
u1
su nombre: B asocia U con I = g1 donde u1 es elegido por U tal que g1 g2 ≠ 1. B calcula z
x
= (Ig2) y lo transmite a U.
Reintegro. U saca de su cuenta una cierta cantidad de dinero y lo guarda en su dispositivo:
1- U prueba a B que es el propietario de una cuenta.
w
w
2- B genera de forma aleatoria w ∈R Ζp, y envía a = g , b = (Ig2) a U.
x1 x2
s
s
u v
3- U selecciona: x1, x2, u, v, s ∈ Ζp; calcula A = (Ig2) , B = g1 g2 , z′ = z , a′ = a g , b′
su v
= b A , c′ = H(A, B, z′, a′, b′); y envía c = c′/u mod q a B.
4- B responde r = cx + w mod q a U y decrementa el saldo de su cuenta.
r
c
s
c
5- U calcula r′ = ru + v mod q y verifica que: g = h a, (Ig2) = z b,
Pago. U paga a la tienda(S) una cierta cantidad de dinero:
r
r
H(A, B, z′, a′, b′)
H(A, B, z′, a′, b′)
1- U envía a S: A, B, sign(A, B) = (g ′ = h
· a′, A ′ = z′
· b′,
(z′, a′, b′, r′)).
2- Si A ≠ 1, S envía d = H0(A, B, IS, date/time) a U.
3- U envía r1 = d(u1s) + x1 mod q, r2 = ds + x2 mod q a S.
4- S verifica la firma de B sobre la moneda: sign(A, B); y acepta el pago si:
r1
r2
d
g1 g2 = A B
Depósito. S ingresa una moneda electrónica en su cuenta y B aumenta el saldo de su
cuenta:
1- S envía a B una copia del pago: A, B, sign(A, B), (r1, r2) y (date/time).
2- Si A = 1, entonces B no acepta la transacción. En caso contrario, B calcula d y
r1 r2
d
verifica que g1 g2 = A B y que sign(A, B) es una firma sobre A, B. B busca en
la base de datos de depósitos para ver si está A. Hay dos posibilidades:
a) A no está en la base de datos; entonces B guarda los datos de la
transacción y aumenta el saldo de la cuenta de S.
b) A ya está en la base de datos; luego ha ocurrido un fraude. Si la copia
de la transacción guardada indica que quien hizo el depósito fue S y
date/time son los mismos que la copia de la nueva transacción,
entonces S está depositando la misma moneda por segunda vez. En
caso contrario la moneda se ha reutilizado (gastado dos veces), si
suponemos que (d, r1, r2) son datos de la transacción en curso y (d′,
r′1, r′2) de la transacción guardada en la base de datos, B puede

3. ′
calcular: g1 ′
; que identifica el número de cuenta del usuario
que reutilizó la moneda.
(r1- r 1)/ (r2- r 2)
2.2 Servicios
En el sistema de dinero electrónico descrito anteriormente el autor presenta tres partes distintas
involucradas en el protocolo: el usuario o cliente, el banco y la tienda. Veamos ahora que servicios
ofrece el Banco a los usuarios U y S en cada uno de los protocolos:
1.
2.
3.
4.
5.
Inicialización del sistema. El banco inicializa los parámetros del sistema de dinero y
define sus primitivas criptográficas. No ofrece ningún servicio de forma directa a los
usuarios.
Obertura de una cuenta. El usuario presenta sus credenciales al banco y crea una cuenta a
su nombre. El Banco ofrece el servicio:
• Abrir: U abre una nueva cuenta en el Banco.
Reintegro. El usuario saca de su cuenta una cierta cantidad de dinero y lo guarda en su
dispositivo. El Banco ofrece los servicios:
• Reintegro: donde decrementa el saldo de la cuenta de U.
• Crear: genera una moneda electrónica y U debe validar su formato.
Pago. El usuario paga a la tienda una cierta cantidad de dinero que tiene guardado en su
dispositivo. Aunque sea un esquema de pago off-line, el Banco de forma indirecta [15]
ofrece a S el servicio:
• Validación: permite a S verificar el correcto formato de la moneda enviada por
U.
Depósito. La tienda ingresa una moneda electrónica en el Banco y éste aumenta el saldo
de su cuenta. En este protocolo el Banco ofrece los servicios:
• Detección del Fraude, que se divide en tres subservicios:
• Formato: detección de monedas de formato no válido.
• Doble Depósito: detección del ingreso de la misma moneda por parte
del mismo usuario.
• Reutilitzación: detección del ingreso de la misma moneda por parte
de usuarios distintos y la identificación del usuario que ha gastado la
moneda más de una vez.
• Depósito: implica el incremento del saldo de la cuenta del usuario.
3 Clasificación de los servicios de seguridad
Una vez definidos los servicios prestados por el Banco en el sistema de dinero electrónico vamos a
proceder a su clasificación. En el caso de un sistema de dinero electrónico el Banco actúa como TTP ya
que se define como una autoridad de seguridad de confianza para otras entidades con respecto a
actividades relativas a la seguridad [2, 3, 5]. Se entiende que una entidad confía en otra cuando esta
entidad asume que la segunda entidad se comportará exactamente como ella espera [4].
Aunque el Banco se defina como una entidad de confianza, reducir la confianza que los usuarios
deben depositar en él tiene que ser un objetivo importante en el diseño de protocolos de seguridad para
reducir las reticencias de sus posibles usuarios, cosa que viene ya referenciada en distintas
publicaciones [3, 5, 10, 11, 13, 15].
En las siguientes secciones exponemos de forma esquemática los resultados de la clasificación de
los servicios de seguridad del Banco en [1] desde el punto de vista de su verificabilidad. Cuando el
servicio en el protocolo original sea calificado “no verificable” propondremos el protocolo alternativo
para mejorar esta calificación. Así, el servicio será calificado de “verificable” dando más seguridad al
sistema.
Para describir nuestras propuestas suponemos que cada usuario involucrado en el protocolo posee un
par de claves asimétricas. La clave privada es usada por cada usuario para la creación de firmas; de esta
manera KsU (M) representa el mensaje M junto con la firma realizada por el usuario U con su clave

4. privada sobre este mensaje. En las figuras que describen los protocolos, la transferencia de un mensaje
M entre dos usuarios U1 y U2 se representa mediante U1 → U2: M.
3.1 Análisis de servicio: Abrir
Servicio: Abrir — Clasificación: verificable
Comentario: Como está descrito en §2.2 este servicio consiste en que el Banco permite abrir una
cuenta al usuario para que la pueda utilizar en sus transacciones comerciales para depositar o ingresar
dinero electrónico. Entendemos aquí que el incumplimiento del servicio es la negación por parte del
Banco de efectuar operaciones con la cuenta, es decir negar la existencia de la cuenta. En la obertura de
x
la cuenta el usuario recibe del Banco z = (Ig2) , donde hay la clave secreta del Banco junto con la
identidad del usuario. Por tanto, si una autoridad legitimada puede tener acceso a la clave secreta del
Banco, el usuario estaría en disposición de demostrar que tiene una cuenta abierta, en caso de que el
Banco negase su existencia. Los mensajes firmados por el Banco en los protocolos de reintegro o
deposito de monedas sobre esta cuenta, también serían una prueba de la existencia de la misma. Por
tanto, el servicio es verificable. No contemplamos aquí, como en el resto de los servicios, que el Banco
no quiera abrir la cuenta, ya que entonces el problema a resolver sería otro: la negación del servicio.
3.2 Análisis del servicio: Reintegro
Servicio: Reintegro — Clasificación: no verificable
Comentario: En el protocolo de reintegro el Banco recibe una petición firmada del usuario. Pero, en
cambio, él sólo firma la moneda y no da ninguna prueba sobre si ha decrementado el saldo del usuario
correctamente. Es decir, el servicio es no verificable porque el usuario no dispone de ninguna evidencia
sobre la correcta actualización de su saldo.
Propuesta para servicio verificable. El protocolo de reintegro quedaría de la siguiente manera:
1.
2.
3.
4.
U → B: KsU (Id. Petición, I, ‘petición reintegro’)
B → U: KsB (Id. Petición, I, saldo, a, b)
U → B: KsU (Id. Petición, I, saldo, c)
B → U: KsB (Id. Petición, I, saldo actualizado, r)
Los parámetros I, a, b, c y r tienen el mismo significado que en §2.1. Con este protocolo básico el
usuario tiene una prueba de la actuación del Banco sobre el saldo de su cuenta (servicio verificable). El
protocolo puede ser entendido como un protocolo optimista para el intercambio equitativo de valores
[16], donde se intercambia, de un lado, una petición de reintegro sobre una cuenta de usuario con un
saldo inicial y, por otro, una moneda electrónica y la actualización del saldo. En los intercambios 1 y 2
se produce la primera parte del intercambio: el primer mensaje de petición y la confirmación por parte
del Banco de realizar el reintegro dando testimonio de la existencia de la cuenta con un saldo que
permite la operación. Los pasos 3 y 4 sirven para completar los compromisos adquiridos en los
primeros intercambios; es decir, el usuario confirma su saldo al Banco y emite el ítem para que el
Banco pueda firmar la moneda, finalmente el Banco entrega el mensaje que permitirá al usuario
completar la moneda y tener evidencia [17] de la actualización del saldo. El hecho de que el protocolo
sea optimista hace que no sea necesaria la intervención de ninguna autoridad legal (TTP) en el
protocolo básico. Pero si el usuario cree que el Banco no cumple con el servicio de reintegro, puede
acudir a una TTP (por ejemplo, delante de un juez) para que su saldo sea actualizado correctamente, ya
que el servicio es verificable porque tiene evidencia de la operación del Banco.
3.3 Análisis del servicio: Crear
Servicio: Crear — Clasificación: no verificable
Comentario: Cuando un usuario ejecuta el protocolo de reintegro puede verificar la corrección en la
creación de la moneda por parte del Banco (ver §2.1). Pero en caso de que los parámetros estén
equivocados el usuario no puede demostrar a un tercero que el banco ha emitido estos parámetros
erróneos.

5. Propuesta para servicio verificable. Con la propuesta introducida en §3.2 para que el servicio de
reintegro sea verificable, el servicio de creación de moneda también lo será, ya que las evidencias
emitidas por el Banco en los pasos 2 y 4 también incluyen los ítems que conforman la moneda. Por
tanto, si un usuario ve actualizado su saldo (disminución de su saldo) pero los parámetros emitidos por
el banco (a, b, r) no son válidos para crear una moneda, puede acudir a una autoridad legal (e.g. un
juez) para conseguir la equidad del intercambio.
3.4 Análisis del servicio: Validación
Servicio: Validación — Clasificación: verificable
Comentario: Durante el protocolo de pago, el usuario S puede verificar la firma del Banco y
también que U conoce una representación de la moneda; es decir que U es el propietario de la misma.
Por tanto S puede demostrar si una moneda lleva la firma correcta del Banco o no, ya que cualquiera
puede comprobar que:
g ′ = hH(A, B,
r
z′, a′, b′)
· a′, A ′ = z′
r
H(A, B, z′, a′, b′)
r1
r2
d
· b′, g1 g2 = A B.
3.5 Análisis del servicio: Detección del fraude. Formato
Servicio: Formato — Clasificación: verificable
Comentario: Cuando S ingresa una moneda, el Banco verifica el formato de la moneda y su firma.
Si no fuesen correctas no incrementaría el saldo del usuario. Como ya hemos visto cualquiera puede
verificar el formato y la firma de la moneda, por tanto S tiene elementos suficientes para demostrar que
el Banco tiene que reconocer como válida la moneda que quiere ingresar.
3.6 Análisis del servicio: Detección del fraude. Doble depósito
Servicio: Doble depósito — Clasificación: no verificable
Comentario: En el protocolo de depósito el Banco recibe los datos referentes a una moneda para
ingresarla en una cuenta de usuario, entonces puede alegar que ya tenía todos esos datos guardados en
su base de datos de monedas utilizadas, sin que el usuario S, que quiere ingresar la moneda en su
cuenta, tenga alguna evidencia para poder rebatirlo. Además el Banco no tiene que aportar ninguna
prueba.
Propuesta para servicio verificable. Para que el servicio sea verificable el Banco tiene que
demostrar que la moneda ya ha sido ingresada previamente, antes de que S revele todos los datos
referente a este depósito. Así pues, para que el servicio de doble depósito sea verificable, el protocolo
de deposito tiene que modificarse de la siguiente manera:
S → B: KsS (Id. Petición, I, ‘petición depósito’, A)
a) Si A no se encuentra en la base de datos de monedas utilizadas:
B → S: KsB (Id. Petición, I, saldo, ‘depósito aceptado’)
b) En caso contrario:
B → S: KsB (Id. Petición, I, saldo, ‘moneda usada’, user_id, fecha/hora
de la transacción, r′1)
Donde user_id es un parámetro que indica si el usuario que ingresa la moneda es el mismo
usuario que la ingresó por primera vez. Con estas modificaciones, la información que debe
guardar el Banco por cada moneda gastada es: [A, r1, r2, fecha/hora de la transacción, I].
3. Si (user_id ≠ I) or ((user_id = I) and (fecha/hora de la moneda ≠ fecha/hora emitido por B)
and (r′1 ≠ r′1))
S → B: KsS (Id. Petición, I, [A, B, sign(A,B), (r1, r2), fecha/hora de la
transacción])
Si no se cumple la condición quiere decir que el Banco acaba de demostrar que S está
ingresando la misma moneda por segunda vez. Si esta condición se cumple indica que la
tienda S no intenta depositar la misma moneda por segunda vez. Aunque, en el caso de que la
condición no se cumpla, podría pasar que la moneda ya hubiese sido depositada por otro
usuario o por el mismo pero con distinta fecha de transacción. En ambos casos estaríamos
1.
2.

6. delante de un caso de ‘doble gasto’ y no de ‘doble depósito’, lo que significa que el Banco
podría detectar al usuario infractor (el que ha gastado dos veces la misma moneda).
4. B -> S: KsB (Id. Petición, I, saldo actualizado, ‘moneda aceptada’)
Como es natural, este mensaje solo se emitirá si no se ha cometido ninguna infracción y la
moneda puede admitirse como válida, después de haber hecho las pertinentes verificaciones.
Los parámetros I, A, B, sign(A,B), r1, r2 y r′1 tienen el mismo significado que en §2.1. Cuando el
Banco emite el mensaje especificado en el paso 2.b de este protocolo quiere decir que la moneda ya ha
sido ingresada, indicando con el parámetro user_id si el depósito lo hace el mismo usuario o uno de
distinto al del primer depósito. Si user_id indica que se trata del mismo usuario y el Banco revela a S la
misma fecha de transacción y el mismo valor del parámetro r1, entendemos que le está demostrando
que la moneda ya ha sido usada. De todas formas, S puede continuar con el protocolo para que el banco
pueda encontrar la identidad del usuario que ha usado dos veces la misma moneda.
3.7 Análisis del servicio: Detección del fraude. Reutilización
Servicio: Reutilización — Clasificación: verificable
Comentario: Aunque el usuario no dispone de ninguna prueba de que ha existido un ‘doble gasto’
cuando finaliza el protocolo de depósito, entendemos que este servicio es verificable porque podría
instar al Banco a demostrarlo delante de alguna autoridad legal. El protocolo especificado en [1] pone
las herramientas necesarias para que el Banco pueda hacerlo. El Banco tiene que calcular:
g1
(r1- r′1)/ (r2- r′2)
u1
= g1 = I
el valor (r1- r′1)/(r2- r′2) mod q le sirve como prueba de reutilización, ya que suponiendo la
irresolubilidad del problema del logaritmo discreto el banco sólo puede llegar a esta conclusión cuando
un usuario gasta una misma moneda más de una vez. De hecho, el Banco tendría que iniciar acciones
legales contra el usuario infractor sin la necesidad de que otro usuario se lo pida.
3.8 Análisis del servicio: Depósito
Servicio: Depósito — Clasificación: no verificable
Comentario: En [1] no se especifica que el banco comunique al usuario su saldo después de
ingresar una moneda en su cuenta para comprobar que se ha incrementado de forma correcta. Por tanto,
el usuario no sólo no tiene ninguna prueba para poder demostrar que su saldo ha sido o no
incrementado correctamente, sino que sencillamente no se le informa de este hecho.
Propuesta para servicio verificable. Con el protocolo propuesto en §3.6, después de los dos
intercambios iniciales, los pasos 3 y 4 completan la transacción de forma que si el Banco no realiza su
servicio de forma correcta el usuario S tendrá las evidencias necesarias para equilibrar la situación con
la ayuda de una TTP para que su saldo sea actualizado correctamente. Por tanto, con la propuesta hecha
en §3.6 el servicio de depósito es verificable.
4 Conclusiones y futuros trabajos
En este artículo hemos analizado los servicios que ofrece el Banco en un conocido sistema de dinero
electrónico. La clasificación de los servicios se ha hecho en base a su verificabilidad, considerando que
un servicio es verificable si la entidad que lo ofrece lo incumple y el usuario afectado puede demostrar
la falta delante de una tercera parte. En este trabajo no sólo hemos analizado cada servicio sino que, en
caso de que el servicio no fuese verificable, hemos propuesto un protocolo alternativo para corregir
este problema y hacer que el servicio sea verificable sin que el sistema pierda ninguna de sus
características de seguridad originales.
Esto nos ha llevado a proponer un nuevo protocolo de reintegro definido en §3.2 y un nuevo
protocolo de depósito de monedas electrónicas cuya versión definitiva está en §3.6. Para conseguir que
los servicios sean verificables, ambos protocolos utilizan conceptos usados en protocolos para el
intercambio equitativo de valores:

7. -
evidencia: información que, bien por sí misma o bien cuando se utiliza con otra
información, puede utilizarse para resolver una disputa.
no rechazo con prueba de origen: que consiste en la generación de evidencias que puedan
utilizarse para probar que ha tenido lugar algún tipo de evento o acción, en este caso la
falsa negación o envío de datos o sus contenidos por parte del emisor.
Esto dos conceptos están definidos formalmente en [17]. Los protocolos definidos en este artículo
tienen 4 pasos, en los dos primeros intercambios se produce un compromiso por parte del emisor y
receptor de llevar a cabo una determinada transacción, y en los dos intercambios siguientes se produce
el desenlace de la transacción. El protocolo finaliza con la obtención por parte del usuario de una
evidencia generada por el Banco de no rechazo con prueba de origen, que convierte el servicio del
Banco en verificable.
En el artículo demostramos cómo un esquema cualquiera de dinero electrónico puede mejorar sus
características de seguridad sin necesidad de modificar el formato de la moneda. Damos a los servicios
del Banco el carácter de verificable a través de la definición de protocolos optimistas para el
intercambio equitativo [16], lo cual debe ayudar a vencer la reticencias de los usuarios a utilizar la red
para sus transacciones comerciales con dinero electrónico, ya que dispondrán de evidencias que les
permitirán acudir a una autoridad legalmente establecida en caso de que surjan disputas a resultas de
eventos o acciones rechazadas por parte de Banco; es decir, la equidad del intercambio está
garantizada.
Creemos que este tipo de trabajo puede ser exportable a otros tipos de protocolos de seguridad
donde intervienen TTPs para que los servicios que prestan sean verificables. Por tanto los trabajos
futuros tienen que ir encaminados a conseguir unos protocolos genéricos que permitan convertir los
servicios de una TTP en servicios verificables sin que por eso el protocolo original pierda ninguna de
sus características de seguridad.
5 Referencias
[1]
Brands, S.: “Untraceable off-line cash in wallet with observers”; Crypto’93, LNCS 773, pp.
302-318, Springer Verlag, 1994.
[2]
ISO/IEC DIS 10181-1: “Information technology – Open systems interconnection – Security
frameworks in open systems – Part 1: Overview of open systems security framework”; ISO/IEC
JTC1/SC21 N8509, Abril 1994.
[3]
ITU-T: “Recommendation X.842: Information technology – Security techniques – Guidelines
on the use and management of trusted third party services”; Octubre 2000.
[4]
ITU-T: “Recommendation X.509: Information technology - Open Systems Interconnection The directory: Authentication framework”; Noviembre 1993.
[5]
European Telecommunications Standard Intitute (ETSI): “Telecommunications Security;
Trusted Third Parties (TTP); Requirements for TTP Services”; ETSI Guide EG 2001 057 v1.1.2
(1997-07).
[6]
M. Lee, G. Ahn, J. Kim, J. Park, B. Lee, K. Kim and H. Lee: “Design and Implementation of an
Efficient Fair Off-line E-Cash System based on Elliptic Curve Discrete Logarithm Problem”;
Journal of Communication and Networks, Vol. 4, No. 2, June 2002.
[7]
M. Payeras, J.L. Ferrer y Ll. Huguet: “Moneda Electrónica Totalmente Anónima e
Indetectable”, Actas de la VII Reunión Española sobre Criptología y Seguridad de la Información,
Oviedo 2002.
[8]
G. Davida, Y. Frankel, Y. Tsiounis, M. Yung : “Anonymity Control in e-cash Systems”;
Financial Cryptography’97, LNCS 1318, pp. 1-16, Springer Verlag, 1997.
[9]
J. Camenish, J.M. Piveteau and M. Stadler: “An Efficient Fair Payment System”; in Proc. Of 3rd
ACM Conference on Computer and Communications Security, ACM Press, pp. 88-94, 1996.
[10]
H. Petersen and G. Poupard: “Efficient scalable fair cash with off-line extortion prevention”;
(Technical Report, ENS, 33 pp., 1997), short version in Proc. Of Int. Conf. On Inform. And
Commun. Security (ICICS’97) LNCS 1334, pp. 463-477, Springer Verlag, 1997.
[11]
M. Mut, J. Ll. Ferrer and Ll. Huguet: “Certified Electronic Mail Protocol Resistant to a
Minority of Malicious Third Parties,” Proceedings of IEEE INFOCOM 2000, Tel Aviv, Israel,
Marzo 2000.
[12]
European Commission DGXIII: “ETS preparatory actions. Project OPARATE (OPerational
and ARchitectural Aspects of TTPs for Europe),” Marzo 1998.

8. [13]
J. Zhou, R. H. Deng and F. Bao: “Evolution of Fair Non-repudiation with TTP,” ACISP’99,
LNCS 1587, pp. 258-269, Springer Verlag, 1999.
[14]
Bruce Schneier: Applied Cryptography: Protocols, Algorithms, and Source Code in C; Second
Edition, Ed. John Wiley & Sons, Inc. 1996.
[15]
M. Mut, J.L. Ferrer y Ll. Huguet: “Terceras partes de confianza. Clasificación de los servicios
de seguridad”, Actas de la VII Reunión Española sobre Criptología y Seguridad de la Información,
Oviedo 2002.
[16]
N. Asokan, Matthias Schunter and Michael Waidner: “Optimistic protocols for fair exchange,”
4th ACM Conference on Computer and Communications Security, Zurich, 1997.
[17]
ITU-T: “Recommendation X.813: Information technology - Open systems interconnection Security frameworks in open systems: Non-repudiation framework”, October 1996.