Análisis de los sistemas de dinero electrónico. Mejoras al esquemade 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àticaUniversitat de les Illes Balears

Carretera de Valldemossa km 7.5, 07071 Palma, Españae-mail: macia.mut@uib.es, Tlf.: +34-971173246

Resumen. El comercio electrónico no está exento de reticencias por parte de sus usuarios respectoa la seguridad de sus transacciones en Internet. Uno de los apartados que requieren mayor atenciónen el aspecto de seguridad son los sistemas electrónicos de pago. Han aparecido bastantespropuestas de esquemas de dinero electrónico que, sin embargo, no han tenido un gran impacto enel mercado. En el artículo demostramos como un esquema cualquiera de dinero electrónico puedemejorar 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 avencer la reticencias de los usuarios para utilizar la red para sus transacciones comerciales condinero electrónico, ya que dispondrán de evidencias que les permitirán acudir a una autoridadlegalmente establecida en caso de que surjan disputas a resultas de eventos o acciones rechazadaspor parte de Banco. Estas mejoras se hacen sin tener que cambiar el formato de la moneda, estosignifica que no perdemos ninguna de las propiedades que ofrece el esquema original y queañ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 realizasus transacciones comerciales en la red. Este auge del comercio electrónico no está exento dereticencias por parte de sus usuarios respecto a la seguridad de sus transacciones en Internet. Laseguridad en el comercio electrónico es exigida por múltiples motivos, pero uno de los apartados querequieren 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 dineroelectrónico cuyas características básicas de seguridad sean similares al esquema convencional deldinero en efectivo. Han aparecido bastantes propuestas de esquemas de dinero electrónico que, sinembargo, no han tenido un gran impacto en el mercado.

Normalmente el aumento de la eficiencia en estos esquemas, con el objetivo de parecerse a losesquemas 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 yanálisis de los servicios que prestan las terceras partes de confianza (TTP – Trusted Third Party) en losprotocolos de seguridad y de la necesidad de reducir la confianza que deben depositar los usuarios enellas para aumentar la seguridad del sistema y además de que su intervención sea off-line para mejorarla eficiencia del protocolo. También se apunta la importancia de la creación de métodos apropiadospara resolver las disputas que puedan aparecer. Con todo esto se pretende que los usuarios adquieranuna 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 elartículo clasificaremos cada uno de los servicios que ofrece el Banco en un esquema de dineroelectró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 consideramosque un servicio es verificable si el usuario puede demostrar el incumplimiento del servicio (si se da elcaso) 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 deincrementar su seguridad. Para ver su aplicación práctica sobre cómo podemos realizar estas mejoras,

hemos aplicado el análisis al modelo básico desarrollado por Brands en [1]. Este modelo es utilizadocomo referencia bibliográfica en muchos artículos referentes a esquemas de dinero electrónico y hasido usado como modelo básico por otros investigadores [6, 7, 8, 9, 10]. Analizaremos cada uno de losservicios que ofrece el Banco en este esquema de dinero electrónico y, para los servicios “noverificables”, propondremos nuevas soluciones para convertirlos en “verificables”, mejorando, portanto, la seguridad global del sistema para sus usuarios. Esta mejora se hace sin tener que cambiar elformato de la moneda propuesto en [1], esto significa que no sólo no perdemos ninguna de laspropiedades que ofrece el esquema original sino que añadimos nuevas características de seguridad alsistema.

En la segunda sección de este articulo revisaremos el esquema de Brands e identificaremos losservicios que presta el Banco en su modelo de dinero electrónico. En la tercera sección clasificaremosestos servicios de seguridad y veremos qué alternativas podemos ofrecer para mejorar su calidad encaso 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. Inicialización del sistema. El Banco(B) inicializa los parámetros del sistema y define susprimitivas criptográficas: B genera el vector generador (g, g1, g2) de Gq (Gq⊂ Ζp

*) y eligesu secreto x ∈R Ζp

*. B también elige H y H0 funciones de hash libres de colisiones. Bgenera la base de datos de cuentas de usuarios y la base de datos de depósitos de monedasgastadas. La clave pública de B es h = gx.

2. Obertura de una cuenta. El usuario(U) presenta sus credenciales a B y crea una cuenta asu nombre: B asocia U con I = g1

u1 donde u1 es elegido por U tal que g1

u1g2 ≠ 1. B calcula z= (Ig2)

x y lo transmite a U.3. 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.2- B genera de forma aleatoria w ∈R Ζp, y envía a = gw, b = (Ig2)

w a U.3- U selecciona: x1, x2, u, v, s ∈ Ζp; calcula A = (Ig2)

s, B = g1

x1g2

x2, z′ = zs, a′ = augv, b′= bsuAv, 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.5- U calcula r′ = ru + v mod q y verifica que: gr = hca, (Ig2)

s = zcb,4. Pago. U paga a la tienda(S) una cierta cantidad de dinero:

1- U envía a S: A, B, sign(A, B) = (gr′ = hH(A, B, z′, a′, b′)· a′, Ar′ = z′H(A, B, z′, a′, b′)· 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:

g1

r1g2

r2 = AdB5. 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

verifica que g1

r1g2

r2 = AdB y que sign(A, B) es una firma sobre A, B. B busca enla 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 latransacció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 copiade la transacción guardada indica que quien hizo el depósito fue S ydate/time son los mismos que la copia de la nueva transacción,entonces S está depositando la misma moneda por segunda vez. Encaso contrario la moneda se ha reutilizado (gastado dos veces), sisuponemos 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

calcular: g1

(r1- r′1)/ (r2- r′2); que identifica el número de cuenta del usuarioque reutilizó la moneda.

2.2 Servicios

En el sistema de dinero electrónico descrito anteriormente el autor presenta tres partes distintasinvolucradas en el protocolo: el usuario o cliente, el banco y la tienda. Veamos ahora que serviciosofrece el Banco a los usuarios U y S en cada uno de los protocolos:

1. Inicialización del sistema. El banco inicializa los parámetros del sistema de dinero ydefine sus primitivas criptográficas. No ofrece ningún servicio de forma directa a losusuarios.

2. Obertura de una cuenta. El usuario presenta sus credenciales al banco y crea una cuenta asu nombre. El Banco ofrece el servicio:

• Abrir: U abre una nueva cuenta en el Banco.3. 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.

4. Pago. El usuario paga a la tienda una cierta cantidad de dinero que tiene guardado en sudispositivo. 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 porU.

5. Depósito. La tienda ingresa una moneda electrónica en el Banco y éste aumenta el saldode 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 lamoneda 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 aproceder a su clasificación. En el caso de un sistema de dinero electrónico el Banco actúa como TTP yaque se define como una autoridad de seguridad de confianza para otras entidades con respecto aactividades relativas a la seguridad [2, 3, 5]. Se entiende que una entidad confía en otra cuando estaentidad 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 usuariosdeben depositar en él tiene que ser un objetivo importante en el diseño de protocolos de seguridad parareducir las reticencias de sus posibles usuarios, cosa que viene ya referenciada en distintaspublicaciones [3, 5, 10, 11, 13, 15].

En las siguientes secciones exponemos de forma esquemática los resultados de la clasificación delos servicios de seguridad del Banco en [1] desde el punto de vista de su verificabilidad. Cuando elservicio en el protocolo original sea calificado “no verificable” propondremos el protocolo alternativopara mejorar esta calificación. Así, el servicio será calificado de “verificable” dando más seguridad alsistema.

Para describir nuestras propuestas suponemos que cada usuario involucrado en el protocolo posee unpar de claves asimétricas. La clave privada es usada por cada usuario para la creación de firmas; de estamanera KsU (M) representa el mensaje M junto con la firma realizada por el usuario U con su clave

privada sobre este mensaje. En las figuras que describen los protocolos, la transferencia de un mensajeM entre dos usuarios U1 y U2 se representa mediante U1 → U2: M.

3.1 Análisis de servicio: Abrir

Servicio: Abrir — Clasificación: verificableComentario: 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 ingresardinero electrónico. Entendemos aquí que el incumplimiento del servicio es la negación por parte delBanco de efectuar operaciones con la cuenta, es decir negar la existencia de la cuenta. En la obertura dela cuenta el usuario recibe del Banco z = (Ig2)

x, donde hay la clave secreta del Banco junto con laidentidad del usuario. Por tanto, si una autoridad legitimada puede tener acceso a la clave secreta delBanco, el usuario estaría en disposición de demostrar que tiene una cuenta abierta, en caso de que elBanco negase su existencia. Los mensajes firmados por el Banco en los protocolos de reintegro odeposito de monedas sobre esta cuenta, también serían una prueba de la existencia de la misma. Portanto, el servicio es verificable. No contemplamos aquí, como en el resto de los servicios, que el Bancono 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 verificableComentario: 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 usuariocorrectamente. Es decir, el servicio es no verificable porque el usuario no dispone de ninguna evidenciasobre la correcta actualización de su saldo.

Propuesta para servicio verificable. El protocolo de reintegro quedaría de la siguiente manera:

1. U → B: KsU (Id. Petición, I, ‘petición reintegro’)2. B → U: KsB (Id. Petición, I, saldo, a, b)3. U → B: KsU (Id. Petición, I, saldo, c)4. 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 elusuario tiene una prueba de la actuación del Banco sobre el saldo de su cuenta (servicio verificable). Elprotocolo 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 unsaldo inicial y, por otro, una moneda electrónica y la actualización del saldo. En los intercambios 1 y 2se produce la primera parte del intercambio: el primer mensaje de petición y la confirmación por partedel Banco de realizar el reintegro dando testimonio de la existencia de la cuenta con un saldo quepermite la operación. Los pasos 3 y 4 sirven para completar los compromisos adquiridos en losprimeros intercambios; es decir, el usuario confirma su saldo al Banco y emite el ítem para que elBanco pueda firmar la moneda, finalmente el Banco entrega el mensaje que permitirá al usuariocompletar la moneda y tener evidencia [17] de la actualización del saldo. El hecho de que el protocolosea optimista hace que no sea necesaria la intervención de ninguna autoridad legal (TTP) en elprotocolo básico. Pero si el usuario cree que el Banco no cumple con el servicio de reintegro, puedeacudir a una TTP (por ejemplo, delante de un juez) para que su saldo sea actualizado correctamente, yaque 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 verificableComentario: 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énequivocados el usuario no puede demostrar a un tercero que el banco ha emitido estos parámetroserróneos.

Propuesta para servicio verificable. Con la propuesta introducida en §3.2 para que el servicio dereintegro sea verificable, el servicio de creación de moneda también lo será, ya que las evidenciasemitidas por el Banco en los pasos 2 y 4 también incluyen los ítems que conforman la moneda. Portanto, si un usuario ve actualizado su saldo (disminución de su saldo) pero los parámetros emitidos porel banco (a, b, r) no son válidos para crear una moneda, puede acudir a una autoridad legal (e.g. unjuez) para conseguir la equidad del intercambio.

3.4 Análisis del servicio: Validación

Servicio: Validación — Clasificación: verificableComentario: 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 cualquierapuede comprobar que:

gr′ = hH(A, B, z′, a′, b′)· a′, Ar′ = z′H(A, B, z′, a′, b′)· b′, g1

r1g2

r2 = AdB.

3.5 Análisis del servicio: Detección del fraude. Formato

Servicio: Formato — Clasificación: verificableComentario: 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 puedeverificar el formato y la firma de la moneda, por tanto S tiene elementos suficientes para demostrar queel 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 verificableComentario: 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 ensu base de datos de monedas utilizadas, sin que el usuario S, que quiere ingresar la moneda en sucuenta, tenga alguna evidencia para poder rebatirlo. Además el Banco no tiene que aportar ningunaprueba.

Propuesta para servicio verificable. Para que el servicio sea verificable el Banco tiene quedemostrar que la moneda ya ha sido ingresada previamente, antes de que S revele todos los datosreferente a este depósito. Así pues, para que el servicio de doble depósito sea verificable, el protocolode deposito tiene que modificarse de la siguiente manera:

1. S → B: KsS (Id. Petición, I, ‘petición depósito’, A)2. 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 mismousuario que la ingresó por primera vez. Con estas modificaciones, la información que debeguardar 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 latienda S no intenta depositar la misma moneda por segunda vez. Aunque, en el caso de que lacondición no se cumpla, podría pasar que la moneda ya hubiese sido depositada por otrousuario o por el mismo pero con distinta fecha de transacción. En ambos casos estaríamos

delante de un caso de ‘doble gasto’ y no de ‘doble depósito’, lo que significa que el Bancopodrí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 lamoneda 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 elBanco emite el mensaje especificado en el paso 2.b de este protocolo quiere decir que la moneda ya hasido ingresada, indicando con el parámetro user_id si el depósito lo hace el mismo usuario o uno dedistinto al del primer depósito. Si user_id indica que se trata del mismo usuario y el Banco revela a S lamisma fecha de transacción y el mismo valor del parámetro r1, entendemos que le está demostrandoque la moneda ya ha sido usada. De todas formas, S puede continuar con el protocolo para que el bancopueda 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: verificableComentario: 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íainstar al Banco a demostrarlo delante de alguna autoridad legal. El protocolo especificado en [1] ponelas herramientas necesarias para que el Banco pueda hacerlo. El Banco tiene que calcular:

g1

(r1- r′1)/ (r2- r′2) = g1

u1 = I

el valor (r1- r′1)/(r2- r′2) mod q le sirve como prueba de reutilización, ya que suponiendo lairresolubilidad del problema del logaritmo discreto el banco sólo puede llegar a esta conclusión cuandoun usuario gasta una misma moneda más de una vez. De hecho, el Banco tendría que iniciar accioneslegales 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 verificableComentario: 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 noincrementado 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 dosintercambios iniciales, los pasos 3 y 4 completan la transacción de forma que si el Banco no realiza suservicio de forma correcta el usuario S tendrá las evidencias necesarias para equilibrar la situación conla ayuda de una TTP para que su saldo sea actualizado correctamente. Por tanto, con la propuesta hechaen §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 dineroelectrónico. La clasificación de los servicios se ha hecho en base a su verificabilidad, considerando queun servicio es verificable si la entidad que lo ofrece lo incumple y el usuario afectado puede demostrarla falta delante de una tercera parte. En este trabajo no sólo hemos analizado cada servicio sino que, encaso de que el servicio no fuese verificable, hemos propuesto un protocolo alternativo para corregireste problema y hacer que el servicio sea verificable sin que el sistema pierda ninguna de suscaracterísticas de seguridad originales.

Esto nos ha llevado a proponer un nuevo protocolo de reintegro definido en §3.2 y un nuevoprotocolo de depósito de monedas electrónicas cuya versión definitiva está en §3.6. Para conseguir quelos servicios sean verificables, ambos protocolos utilizan conceptos usados en protocolos para elintercambio equitativo de valores:

- evidencia: información que, bien por sí misma o bien cuando se utiliza con otrainformación, puede utilizarse para resolver una disputa.

- no rechazo con prueba de origen: que consiste en la generación de evidencias que puedanutilizarse para probar que ha tenido lugar algún tipo de evento o acción, en este caso lafalsa 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ículotienen 4 pasos, en los dos primeros intercambios se produce un compromiso por parte del emisor yreceptor de llevar a cabo una determinada transacción, y en los dos intercambios siguientes se produceel desenlace de la transacción. El protocolo finaliza con la obtención por parte del usuario de unaevidencia generada por el Banco de no rechazo con prueba de origen, que convierte el servicio delBanco en verificable.

En el artículo demostramos cómo un esquema cualquiera de dinero electrónico puede mejorar suscaracterísticas de seguridad sin necesidad de modificar el formato de la moneda. Damos a los serviciosdel Banco el carácter de verificable a través de la definición de protocolos optimistas para elintercambio equitativo [16], lo cual debe ayudar a vencer la reticencias de los usuarios a utilizar la redpara sus transacciones comerciales con dinero electrónico, ya que dispondrán de evidencias que lespermitirán acudir a una autoridad legalmente establecida en caso de que surjan disputas a resultas deeventos 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 seguridaddonde intervienen TTPs para que los servicios que prestan sean verificables. Por tanto los trabajosfuturos tienen que ir encaminados a conseguir unos protocolos genéricos que permitan convertir losservicios de una TTP en servicios verificables sin que por eso el protocolo original pierda ninguna desus 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 – Securityframeworks in open systems – Part 1: Overview of open systems security framework”; ISO/IECJTC1/SC21 N8509, Abril 1994.

[3] ITU-T: “Recommendation X.842: Information technology – Security techniques – Guidelineson 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 anEfficient 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 eIndetectable”, 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. AndCommun. 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 aMinority of Malicious Third Parties,” Proceedings of IEEE INFOCOM 2000, Tel Aviv, Israel,Marzo 2000.

[12] European Commission DGXIII: “ETS preparatory actions. Project OPARATE (OPerationaland ARchitectural Aspects of TTPs for Europe),” Marzo 1998.

[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; SecondEdition, Ed. John Wiley & Sons, Inc. 1996.

[15] M. Mut, J.L. Ferrer y Ll. Huguet: “Terceras partes de confianza. Clasificación de los serviciosde 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.