Abstract— Los nuevos dispositivos móviles son capaces de acceder a redes de datos al mismo tiempo que pueden ejecutar aplicaciones complejas. En este artículo se presenta el primer sistema de micropagos adaptado a estos dispositivos satisfaciendo las propiedades de seguridad que garantizan la privacidad del usuario y eliminan el riesgo financiero. Además, el pago se ha diseñado como un intercambio equitativo, donde el usuario U envía una serie de cupones al proveedor P y, a cambio, U recibirá el bien o la información solicitada. En este intercambio equitativo, el anonimato y la no rastreabilidad de los usuarios están asegurados. Debemos tener en cuenta que los actuales teléfonos inteligentes (smartphones), además de una gran potencia de cálculo, a menudo disponen de sistemas de localización como el GPS. La combinación de ambas capacidades puede ser útil para construir nuevas aplicaciones ubicuas basadas en la localización del usuario. En este trabajo también mostramos cómo nuestro sistema de micropagos se puede adaptar para el pago de servicios basados en localización (LBS), utilizando los teléfonos móviles y manteniendo las propiedades de seguridad.
Keywords— Micropago electrónico, privacidad, no rastreabilidad, intercambio equitativo, anonimato, seguridad en los servicios de localización
I. INTRODUCCIÓN
os micropagos pretender ser un factor clave en la evolución del comercio electrónico. Estos sistemas de pago se pueden aplicar en negocios que involucran transacciones de bajo valor (por lo general por debajo de 20$). La seguridad, la eficiencia y el coste de la transacción individual son factores críticos para el desarrollo de estos sistemas.
La introducción de estos sistemas en los servicios de telecomunicaciones va destinada a los usuarios que quieren tener el control del servicio que reciben y que no sienten como una experiencia positiva la utilización de los servicios financiados por la publicidad. Así, los micropagos son una herramienta que permite servicios orientados al usuario, en contraste con los servicios de patrocinio, y sin la necesidad de tener que cumplir cuotas de suscripción.
En los sistemas de micropago, como en cualquier sistema
1 Andreu Pere Isern-Deyà, Universitat de les Illes Balears, Palma de Mallorca, España. e-mail: [email protected]
2 Llorenç Huguet-Rotger, Universitat de les Illes Balears, Palma de Mallorca, España. e-mail: [email protected]
3 Maria Magdalena Payeras-Capellà, Universitat de les Illes Balears, Palma de Mallorca, España. e-mail: [email protected]
4 Macià Mut-Puigserver, Universitat de les Illes Balears, Palma de Mallorca, España. e-mail: [email protected]
donde se intercambian elementos monetarios por bienes o servicios, las propiedades de seguridad en las transacciones son una preocupación, principalmente para evitar riesgos financieros. Así mismo, al ser transacciones en las que el valor negociado es bajo, también se tienen que tener en cuenta los costes que acarrean las mismas. Por tanto, este tipo de sistemas tienen que llegar a un compromiso entre la seguridad proporcionada para evitar o controlar los riesgos financieros y el coste que tienen estas medidas de seguridad.
En este artículo presentamos el primer sistema de micropagos eficiente, con bajos costes por transacción y que controla los riesgos financieros, al mismo tiempo que se aseguran diferentes propiedades de seguridad como la privacidad, la imposibilidad de rastreo y vinculación de las transacciones, el anonimato y el intercambio equitativo entre los elementos intercambiados. Para mejorar la experiencia impulsada por los usuarios y aumentar la seguridad del servicio se ha incorporado, especialmente, la característica de no rastreabilidad. Esta propiedad permite la indistinción de la interacción de pasado y futuro con respecto a la identidad del usuario, de tal manera que los proveedores no podrán atentar contra la privacidad del usuario por el rastreo de las acciones del usuario, evitando así la generación de perfiles de usuarios.
Ciertamente, existen sistemas de micropago propuestos anteriormente [2, 3, 15, 21, 24, 25] que cumplen algunas de las propiedades de seguridad enumeradas anteriormente, pero ninguno de ellos cumple con todas las propiedades propuestas aquí.
Los micropagos se pueden aplicar fácilmente a la venta de bienes intangibles (por ejemplo, información). Un tipo de compra o intercambio de información se da en los nuevos servicios basados en localización (a partir de ahora LBS), donde los usuarios del sistema pueden realizar consultas a un proveedor de servicios acerca de los lugares de interés, estado del tráfico u otros servicios similares en los que interviene la localización del usuario en ese preciso momento. Por tanto, el esquema que se propone en este trabajo también puede aplicarse en los servicios LBS.
El trabajo se organiza de la siguiente manera: en la Sección 2 se presenta un resumen de los trabajos relacionados; en la Sección 3 se describen brevemente las características de los sistemas de micropago y cómo se pueden aplicar las funcionalidades de micropago para servicios basados en localización; en la Sección 4 se resumen en qué consisten la firmas parcialmente ciegas y las cadenas de hash;
en la Sección 5 se define el protocolo de micropagos; en Sección 6 se presenta un análisis informal de las propiedades A.P. Isern-Deyà1, L. Huguet-Rotger2, M. Payeras-Capellà3, M. Mut-Puigserver4
Esquema de Micropago Anónimo, Equitativo y no Rastreable: Aplicación a los Servicios LBS
L
de seguridad del protocolo presentado y finalmente, en la Sección 7, se incluyen las conclusiones y los trabajos futuros.
II. TRABAJOS RELACIONADOS
Las aplicaciones recientes de comercio electrónico han presentado el reto de diseñar sistemas de pago electrónico con requisitos especiales. Algunas de estas aplicaciones, como las compras de información a los proveedores de LBS, requieren características especiales que la mayoría de sistemas de pago no pueden satisfacer. Así, los micropagos son los sistemas de pago electrónico adecuados para las transacciones de bajo valor y algunos de ellos proporcionan la privacidad necesaria para ser utilizados en las compras que implican información privada como la ubicación del usuario.
Los sistemas convencionales de pago electrónico no son aplicables en entornos donde los costes de almacenamiento, comunicaciones y computación son escasos. Otras alternativas existentes consisten en el acceso libre a la información, financiación mediante banners publicitarios o suscripciones temporales. Ninguno de ellos son equitativos ni para los clientes ni para los proveedores (o propietarios de derechos de propiedad intelectual). Por un lado, los proveedores no quieren proporcionar acceso gratuito a su información y, por otro lado, los micropagos son mejores para los clientes que los abonos temporales ya que permiten el pago del coste exacto de la información consumida.
Los servicios LBS y algunos otros servicios similares requieren de un sistema de pago adecuado para pequeños pagos facilitando el intercambio equitativo, el anonimato y no rastreabilidad de los pagos. En [13] se presenta un protocolo de pago para servicios LBS que implementa un intercambio equitativo y el anonimato, pero no posee la propiedad de no rastreabilidad.
Los sistemas de micropago por lo general no ofrecen la propiedad de equidad en el intercambio, por lo que el cliente o el proveedor pueden engañar y obtener ventajas financieras con su mal comportamiento. En [3] no se proporciona completamente la equidad, pero el mal comportamiento resulta inútil para los clientes y proveedores con la ayuda de largas cadenas de hash. En [25] se presenta un sistema equitativo que permite la divisibilidad de las monedas. Sin embargo, este esquema sólo proporciona anonimato restringido y, además en [24] se afirma que el protocolo puede verse comprometido por la colusión de los proveedores.
Por último, en [2] se propone la mejora de un protocolo anónimo cambiando una firma ciega, utilizando criptografía de curvas elípticas, por una firma ciega basada en RSA [6].
Gracias a la utilización de esta firma el esquema es anónimo y no rastreable pero no tiene un intercambio equitativo.
No obstante, ninguno de los sistemas citados cumple los requisitos descritos anteriormente, es decir equidad, anonimato y no rastreabilidad.
III. PROPIEDADES DE LOS ESQUEMAS DE MICROPAGOS
Las características ideales de los sistemas de micropago se describen en [20,22]:
• Bajos costes transaccionales. El coste de cada transacción debe ser una pequeña fracción de la cantidad transferida en el pago.
• Límite inferior. El límite inferior del micropago debe permitir la compra de pequeñas piezas de información.
• Control de Riesgos Financieros. Las medidas de seguridad están limitadas con el fin de mantener los costes de transacción en un nivel aceptable. No obstante, los riesgos asumidos deben ser controlados.
• Intercambio Equitativo o Atómico. Los bienes o servicios de información pueden ser transferidos a través de redes. Para este tipo de bienes es deseable el intercambio atómico entre las monedas y los bienes.
• Privacidad. La privacidad es una característica clave para todos los sistemas de pago electrónico. En los sistemas de micropago, las prerrogativas de privacidad (no rastreabilidad, anonimato, e imposibilidad de vinculación) son, por lo general, opuestas a la eficiencia.
Para conseguir bajos costes en las transacciones se requiere un ajuste en las siguientes características [15]:
• Número de interacciones entre las partes durante el pago. Los pagos on-line que requieren la mediación del banco no son deseables. Los costes de comunicación son más bajos en los pagos off-line.
• Volumen de información. El volumen de información transferida relacionado con el pago tiene que ser minimizado.
• Costes computacionales. El uso de la criptografía asimétrica debe ser limitado debido a su coste de procesamiento y a los costes de gestión de certificados digitales.
• Requisitos de almacenamiento. Se debe evitar el uso de grandes bases de datos, así como de dispositivos resistentes a manipulaciones. La seguridad de los sistemas de micropagos deben ser independientes del hardware.
• Costes de mantenimiento de la privacidad y del anonimato. Por lo general, los sistemas anónimos no son eficientes y además hacen uso de la criptografía asimétrica, de modo que no es fácil implementar la propiedad de anonimato en los micropagos. Si se implementa el anonimato, debe garantizarse un alto grado de eficiencia.
• Uso de monedas. Reduciendo el número de posibles receptores de monedas (monedas específicas para un único receptor), los algoritmos de seguridad se pueden implementar más eficientemente que con monedas genéricas.
Un sistema de micropagos ideal debe ser seguro, off-line, anónimo e imposible de rastrear, con bajos costes de
almacenamiento, de cómputo y de transacción. Por otra parte, el sistema debe proporcionar una relación equitativa entre la moneda y la compra del bien o servicio.
A. Micropagos Relativos a los Servicios LBS
Los servicios LBS son un nuevo tipo de servicios ubicuos que hacen uso de los datos de localización en un entorno móvil para ofrecer a sus clientes información valiosa sobre el contexto en el que se encuentran. Por ejemplo, los usuarios pueden solicitar a los proveedores de LBS dónde está el hospital más cercano o dónde están localizados sus amigos.
Por un lado, los sistemas LBS abren nuevas amenazas de seguridad [16] relacionadas con la privacidad de los usuarios para que ni proveedores, ni observadores, puedan tener acceso a la identidad de los usuarios ni a su ubicación. Así que los mecanismos de seguridad deben ser utilizados con el fin de preservar el anonimato del usuario. Por eso, un servicio debe proteger a los clientes en contra de la rastreabilidad de sus actividades y conversaciones con los proveedores de localización. Además, si a las amenazas expuestas sobre la privacidad de los usuarios unimos la capacidad de los proveedores de cobrar a sus usuarios es evidente la necesidad de implementar los sistemas de micropago.
Por otra parte, desde el punto de vista de rendimiento y coste, los LBS se utilizan por los usuarios móviles a través de una red de comunicaciones móvil, que puede proveer recursos limitados y un ancho de banda reducido; es decir, los mensajes intercambiados entre las partes involucradas tienen que ser cortos y además la necesidad de potencia computacional tiene que ser la más baja posible. Por otra parte, el acceso a estos servicios debe proporcionado mediante tarifas bajas. Por lo tanto, el pago de LBS debe ser diseñado para evitar estos problemas. De hecho, los sistemas de micropago están diseñados para mejorar la eficiencia de las transacciones para que el coste de un micropago no sea más alto que el precio del artículo comprado.
En resumen, podemos afirmar que los micropagos se pueden utilizar en los sistemas LBS, ya que ambos esquemas tienen características en común como los requisitos de rendimiento y de privacidad.
IV. HERRAMIENTAS CRIPTOGRÁFICAS
A. Firma Parcialmente Ciega
La firma parcialmente ciega está relacionada con el concepto de firma ciega [5], jugando un papel central en los protocolos criptográficos que requieren anonimato, como en el caso del dinero electrónico o de los sistemas de votación electrónica. La firma ciega es utilizada por un solicitante que oculta algunos datos a la entidad que firma, con el fin de que éste no conozca los datos cegados. Pero la firma ciega presenta un inconveniente importante para el firmante, ya que no tiene ningún control sobre los parámetros cegados. Por
ejemplo, si la firma ciega se utiliza en un sistema de dinero electrónico, el banco que emite una moneda con una firma ciega no puede inscribir el valor de la moneda emitida en la misma. Así, el valor se debe establecer, por ejemplo, mediante el uso de una clave pública diferente para cada valor de la moneda.
La firma parcialmente ciega se introdujo en [1], y en [17]
se presentó una definición formal de seguridad y un esquema de firma parcialmente ciega segura, en el modelo del oráculo. La firma parcialmente ciega permite al firmante introducir alguna información común, previamente acordada con el solicitante. Esta es una generalización de la firma ciega, puesto que la firma ciega común es un caso especial de la firma parcialmente ciega, donde la información común es nula. De hecho, utilizando firmas parcialmente ciegas en sistemas de dinero electrónico, se puede inscribir dentro de la misma firma el valor de la moneda emitida y otra información útil, tal como una fecha de caducidad. Hay algunas propuestas de firmas parcialmente ciegas en la bibliografía usando supuestos de seguridad diferentes: [7, 19, 23] utilizan mapas bilineales; [1, 4, 6] se basan en RSA; [17]
se basa en el problema del logaritmo discreto y [10] se basa en el problema de residuos cuadráticos.
A lo largo de este trabajo utilizamos [6], porque tenemos que utilizar una firma parcialmente ciega con el fin de ocultar parcialmente la información. Por otra parte, hemos elegido este sistema porque tiene baja necesidad de computación y es fácil de implementar en dispositivos móviles. El esquema consiste en las cuatro fases siguientes: (1) inicialización, (2) petición, (3) firma y (4) extracción y verificación.
B. Cadenas de Hash
Las cadenas de hash se propusieron para el uso de contraseñas de autenticación de un solo uso en [14]. Después, esta propuesta fue redefinida como el estándar S/KEY en [11]. Las cadenas de hash han sido utilizadas en varias propuestas y esquemas: para la firma de un solo uso [9], para cadenas de certificados digitales [18], para la autenticación de las actualizaciones del estado del enlace en redes [12] y para esquemas de micropago [21].
Una cadena de hash (WN,…,W0) se define como un conjunto de valores donde cada Wi se obtiene tras la aplicación de una función unidireccional (normalmente una función de hash criptográfica) sobre el valor Wi+1, es decir, Wi = H(Wi +1) para 0 ≤ i ≤ N – 1. Para inicializar la cadena de hash, el generador de la misma elige y guarda de forma secreta un valor semilla (“seed”) aleatorio WN. Entonces, se aplica iterativamente la función de hash H sobre este valor semilla hasta obtener el valor W0, denominado raíz. Este último elemento de la cadena es revelado por el generador y está vinculado a la identidad del mismo que tiene el valor de la semilla.
Con el fin de proceder a la verificación de la cadena de hash, el verificador tiene que conocer el valor raíz
W0. Entonces, la verificación de un elemento intermedio de la cadena Wi se realiza aplicando i veces la función de hash H sobre él mismo, comprobando que Hi(Wi) = W0. El verificador puede mejorar la eficiencia del procedimiento si conoce un valor Wk donde k < i. Entonces, es suficiente aplicar (i – k) veces H sobre el valor de entrada, y comparar el resultado con Wk.
La característica clave de las cadenas de hash, derivada de la función de hash, es que dado un valor Wi, no es factible encontrar otro Wj donde j > i tal que H(j - i)(Wj) = Wi.
V. DESCRIPCIÓN DEL PROTOCOLO EQUITATIVO Y NO
RASTREABLE
A. Descripción general del protocolo
El esquema de micropago equitativo y no rastreable propuesto permite a los clientes gastar de un modo seguro y eficiente elementos monetarios a cambio de servicios electrónicos de bajo coste o bienes intangibles. La idea se basa en una moneda específica que puede ser utilizada por los usuarios para acceder y pagar a un único proveedor de servicios o bienes. La moneda se construye como una cadena de hash donde a cada elemento se le llama cupón.
Para que los usuarios puedan actuar de forma anónima, la moneda no contiene ningún dato sobre la identidad real de los mismos. Por otra parte, el sistema propuesto añade un intercambio equitativo entre un micropago y un servicio deseado. Otra de sus características es la capacidad que tiene el usuario para devolver los cupones no utilizados si ya no quiere acceder más a los servicios ofrecidos por el proveedor. El protocolo también permite gastar varios cupones si el servicio deseado cuesta más que un único cupón. Por último, el sistema implementa un algoritmo de prevención de múltiple gasto para evitar los intentos de reutilización de la moneda.
Notación General Usada
H(x) función de una vía resistente a colisiones aplicada sobre x
Hi(x) función hash H(x) aplicada i veces sobre el elemento x SKA y PKA par de claves de la entidad A de un sistema de cifrado
de clave pública
CertA certificado digital de clave pública de A SA(x) firma digital de A sobre el elemento x x ←R Zr y x ←R Zn* elemento x elegido al azar del conjunto Zr y Zn*
KS clave de un criptosistema de clave simétrica EKS[x] y DKS[x] cifrado y descifrado de x, respectivamente, usando la
clave KS
C moneda emitida por B y usada por U para pagar a P c número de cupones de pago dentro de una cadena de
cupones
v valor de cada cupón de pago
PKB = (e, n) clave pública del banco B SKB = (d,p,q) clave privada del banco B
C moneda emitida por B y usada por U para pagar a P Tabla 1. Notación usada en la descripción del protocolo.
Contenido de la Moneda de Cupones Γ información común para la firma parcial ciega Γ.c número de cupones de pago dentro de una cadena de
cupones
Γ.v valor de cada cupón de pago Γ.idservice identificador del servicio Γ.τexp tiempo de expiración de la moneda Γ.Δτop intervalo de tiempo que define τd y τr
∆ y Ω información de verificación de la firma parcial ciega Tabla 2. Notación para el contenido de la moneda de cupones.
En el protocolo participan los siguientes actores:
• U (usuario) es un cliente del sistema que adquiere un servicio.
• P (proveedor) responde a las solicitudes de servicios realizadas por U.
• B (el banco) almacena cuentas bancarias y emite, deposita y reembolsa monedas.
El esquema utiliza la notación general que se puede leer en la Tabla 1 y la notación específica para el contenido de las monedas de cupones se puede consultar en la Tabla 2. El protocolo propuesto se divide en varias fases, que se resumen a continuación:
• Configuración. B adquiere un par de claves RSA mientras U y P abren una cuenta en B e ingresan una cierta cantidad de dinero inicial.
• Solicitud de servicio. Permite a U acceder a una lista de servicios disponibles en P, y si está interesado en uno de ellos, inicia el protocolo para solicitar el servicio deseado.
• Retirada. Permite a U extraer una moneda a partir del saldo disponible en su cuenta bancaria en B.
• Transferencia. Permite el acceso de U a P para adquirir un servicio utilizando un intercambio equitativo con la moneda emitida anteriormente.
• Depósito. Permite a P depositar una lista de cupones recibidos de U haciendo un ingreso en su cuenta.
• Intercambio anónimo. Permite a U intercambiar un conjunto de cupones no utilizados de una moneda, sin revelar ningún tipo de información que podría ser utilizada por P o B (o confabulaciones de los dos) para deducir su identidad.
• Reembolso. Esta fase es similar a la del depósito, pero ahora permite a U la devolución y reembolso en su cuenta bancaria de un conjunto de cupones no utilizados, o bien devolver una moneda entera que no haya sido usada. En caso para se haga un reembolso de una moneda parcialmente usada, estos cupones se obtienen después de ejecutar la etapa de intercambio anónimo.
Hay que señalar la importancia de algunas consideraciones iniciales usadas para el diseño del protocolo subyacente y que
se especifican a continuación:
• Uso de dispositivos móviles con recursos limitados. El protocolo tiene que diseñarse para poder ser usado eficientemente en los dispositivos móviles de poca potencia de cálculo. Esto implica reducir tanto como sea posible el uso de procedimientos y métodos criptográficos costosos, como puede ser la utilización de la infraestructura de clave pública.
• Esquema a débito. El saldo de la cuenta de U se disminuirá durante la retirada de la moneda.
• Los cupones tienen un valor pequeño. Cada cupón tiene un valor lo suficientemente pequeño para que no se tenga que dividir en piezas más pequeñas.
• Gasto parcial. U puede utilizar sólo una parte de una moneda y luego solicitar un reembolso de los cupones no utilizados.
• Diagrama de tiempos del protocolo. Con el fin de fijar los intervalos de tiempo para limitar cuando puede ejecutarse cada una de las fases del protocolo, se definen algunas marcas de tiempo, como podemos ver en la escala temporal de la Fig. 1, y que se explican enseguida:
o τexp es una fecha de expiración de la moneda. Marca la fecha hasta que U puede gastar su moneda en P mediante el subprotocolo de transferencia.
o Δτop es un parámetro del sistema que define un intervalo de tiempo que se añade a τexp. Así τd = τexp + Δτop estipula la fecha hasta la que P puede depositar los cupones recibidos de U. Por otra parte, τr = τexp + 2Δτop (o un múltiplo de Δτop predefinido por el sistema) indica la fecha hasta que U puede solicitar el reembolso de cupones no gastados. Pasada esta última fecha, U no puede devolver la moneda parcialmente usada ya que no va a ser válida.
Fig. 1. Definición de diferentes rangos de tiempo.
B. Configuración
B adquiere un par de claves RSA para poder usar el esquema de la firma parcialmente ciega descrito en IV.A.
U y P deben configurar una cuenta en B, a la que vinculan su propio certificado digital. Entonces, esta relación es usada por B para autenticar a sus clientes en los subprotocolos de retirada, depósito y reembolso.
C. Solicitud de Servicio
El subprotocolo de solicitud de servicio permite a U descargar una lista de servicios disponibles en P. Entonces U puede seleccionar un servicio identificado por un identificador idservice único. Entonces P construye un identificador W0P aplicando una función hash sobre un elemento aleatorio y secreto W1P. Por otra parte, P construye una tabla de informaciones comunes que contiene los datos de cada servicio ofrecido.
Las comunicaciones entre U y P están protegidas por el uso de un criptosistema simétrico seguro. En nuestra propuesta, usamos el criptosistema ElGamal [8].
El subprotocolo de solicitud de servicio se define de la siguiente forma:
makeRequest. U ejecuta los siguientes pasos:
1. U elige el servicio deseado de la lista previamente obtenida.
2. U → P: idservice
processRequest. P sigue los siguientes pasos:
1. construye un par de claves ElGamal [8]:
a. g es un generador del grupo cíclico G de orden r b. elige al azar x ←R Zr y construye h= gx mod r c. devuelve PKElgamal = (h, r, g) y SKElgamal = (x) 2. elige un identificador aleatorio y secreto W1P ←R Zr 3. aplica la función hash al identificador secreto W0P = H(W1P) 4. construye Γ = (idservice, 2c, v, τexp, Δτop) como información
común
5. vincula y firma Γ con el identificador generado: SP (W0P, Γ) 6. almacena la relación [Γ, W1P, W0P, x] en su base de datos 7. P → U: W0P, Γ, SP (W0P, Γ), CertP, PKElgamal
storesData. U sigue los siguientes pasos:
1. comprueba si Γ es correcto
2. prepara el intercambio de clave simétrica utilizando el criptosistema ElGamal:
a. elige KS ←R Zr y y ←R Zr
b. calcula Z1=gy y Z2 = KS hy
3. almacena [Γ, W0P, SP (W0P, Γ), KS, Z2, Z1] en su base de datos
D. Retirada: Generación de la Moneda y su Verificación El subprotocolo de retirada implica a U y a B, y permite al primero retirar cupones no rastreables de su cuenta en B.
Cuando B recibe una solicitud de un cliente, crea una moneda específica que se utiliza para acceder y pagar a un único P.
La característica clave del subprotocolo es que permite a U extraer una moneda que será imposible de rastrear por B, cuando el proveedor P ejecute el subprotocolo de depósito (ver apartado 5.F) gracias a la utilización del esquema de la firma parcialmente ciega. Es decir, B no puede saber quién es el usuario que ha gastado una moneda cuando esta moneda es depositada por P, porque no sabe nada de la pareja de identificadores cegada (W0U, W0P), por lo que B no puede relacionarlo con la identidad de U. En la Fig. 2 se compara el mismo esquema sin el uso de la firma parcialmente ciega o cuando se utiliza. Está claro viendo la Fig. 2(a) que B tiene la capacidad de rastrear las actividades de U después que P haya
ejecutado la fase de depósito. Por el contrario, en la Fig. 2(b) B no puede rastrear las acciones de U, porque no conoce nada de la pareja de identificadores cegados.
Figura 2. (a) sistema rastreable sin el uso de la firma parcialmente ciega. (b) esquema no rastreable gracias al uso de la firma parcialmente ciega.
Así pues, B firma dos fragmentos de datos: un dato común previamente acordado entre U y P, en el subprotocolo solicitud de servicio, y otra información que está cegada por U, gracias a la utilización del esquema de firma parcialmente ciega. Una vez que el subprotocolo finaliza, U ha obtenido una moneda firmada por B para su uso en P. Por su parte, B no sabe nada acerca del identificador de la moneda. El subprotocolo de retirada se define como sigue:
requestCoin. U solicita una moneda a B:
1. elige WMU ←R Zr donde M = 2c
2. construye la cadena de cupones aplicando la cadena de hash WiU = H(W(i + 1)U), 0 ≤ i ≤ 2c – 1
3. une los identificadores m = (W0U║ W0P) para ser cegados 4. calcula Γ = (idservice, 2c, v, τexp, Δτop) para la transacción
actual
5. elige η, µ ←R Zn*
6. genera α = ηe H(m) (µ2 + 1) mod n
7. genera la firma sobre el par (Γ, α): SU (Γ, α) 8. U → B: (Γ, α), SU (Γ, α), CertU
sendRandomChallenge. B sigue los siguientes pasos:
1. la cuenta de U debe cumplir (saldo ≥ v·c), de lo contrario B se detiene
2. verificar si Γ·2c, Γ·v y Γ·τexp son válidos 3. elige λ ←R Zn*
4. B → U: λ
sendChallengeResponse. U sigue los siguientes pasos:
1. elige ρ ←R Zn* 2. calcula b = ηρ
3. calcula β = be (µ – λ) mod n. Nota: En el caso improbable que mcd (β, n) ≠ 1 habría que empezar de nuevo porque β no tendría inverso módulo n.
4. U → B: β
signCoin. B sigue los siguientes pasos:
1. construye φ = β-1 mod n
2. firma los datos cegados δ = H (Γ)d (α ( λ2 + 1 ) β-2)2d mod n 3. disminuye el saldo de la cuenta de U: saldo = saldo – (c · v) 4. B→U: (φ, δ)
unblindingCoin. U sigue los siguientes pasos para desenmascarar y componer la moneda:
1. calcula ∆ = (µλ + 1)β-1be = (µλ + 1)/(µ − λ) mod n 2. construye el elemento Ω = δη2ρ4 mod n
3. obtiene la firma parcialmente ciega para m = (W0U, W0P) y los datos comunes Γ = (idservice, 2c, v, τexp, Δτop)
4. la moneda se compone de C = [(Γ, ∆, Ω), (W0U, W0P)]
La verificación de la firma parcialmente ciega de la moneda, necesaria en los siguientes pasos, se puede realizar aplicando el siguiente proceso:
Inputs: la moneda C = [(Γ, ∆, Ω), (W0U, W0P)] y la clave pública de B, PKB = (e, n)
CheckCoin: la firma parcialmente ciega se verifica computando:
Ωe Η(Γ) Η(W0U║W0P)2 (∆2 + 1)2 mod n (1)
E. Transferencia
El subprotocolo de transferencia es un protocolo offline entre U y P ya que B no está involucrado. U puede ejecutar la transferencia mientras la moneda sea válida, es decir, mientras τnow ≤ τexp, como podemos ver en la Fig. 1. El protocolo de transferencia define un esquema de intercambio equitativo que consta de tres pasos U y P, donde un servicio o bien electrónico se intercambia por un micropago. Con el fin de asegurar la equidad del intercambio, la cadena de cupones se divide en dos grupos de cupones como muestra la Fig.
3. De hecho, los cupones con índice impar se llamarán cupones de pago mientras que los cupones con índice par se llamarán cupones de prueba. Sólo los primeros tienen valor monetario mientras que los segundos se utilizan junto con un cupón de pago con el fin de validarlo.
Figura 3. La cadena de cupones: sentido de creación y sentido de gasto.
La privacidad del protocolo se logra mediante el uso de un criptosistema simétrico seguro. En el caso concreto de la propuesta presentada, se utiliza el criptosistema ElGamal [8], aunque se puede usar cualquier otro de similar. Entonces, la primera vez que U accede a P, debe enviarle la clave simétrica ElGamal que habrá generado en el subprotocolo de solicitud de servicio. Así pues, U envía el par (Z1, Z2) a P, para que éste pueda regenerar la clave simétrica calculando KS = Z2·Z1-x. Esta clave puede ser utilizada para más de un acceso a P, por ejemplo hasta que expire la fecha de caducidad predefinida de la moneda o hasta un número máximo de usos.
Cuando U envía un cupón WiU, P lo comprueba verificando que el cupón recibido pertenece a una moneda válida y no expirada. Además también verifica si el cupón recibido no se ha utilizado antes. Para ello, P compara el índice del cupón precedente (j) con el índice del que recibe ahora (i). Si i ≤ j, P detecta un intento de reutilización y niega la ejecución de la transacción actual. En caso de detección de un evento de reutilización, P negará el servicio a U hasta que U envíe el cupón de prueba correspondiente o hasta que envíe un cupón de pago sin usar, es decir con un índice superior al recibido anteriormente. Si todas las verificaciones son satisfactorias, P envía el servicio o bien electrónico solicitado a U. Entonces, U envía el cupón de prueba W(i+1)U a P. Si no es correcto, P niega el servicio a U en la misma forma que antes.
El subprotocolo transferencia se representa como sigue:
makeRequest. U sigue los siguientes pasos:
1. extrae KS de su base de datos
2. extrae el cupón de pago WiU y lo cifra: m1 = EKS [WiU] 3. U → P: m1, C
verifyRequest. P sigue los siguientes pasos:
1. descifra la solicitud recibida: el DKS [m1] = WiU
2. verifica que τnow ≤ τexp
3. verifica la firma de C (como en la ecuación (1))
4. controla la reutilización: si i ≤ j entonces P detiene la operación
5. verifica si WiU pertenece a C realizando H(i - j)(WiU) WjU
6. guarda en la base de datos tupla (C, WiU, i)
7. rellena res con el servicio que desea y lo cifra: m2 = EKS [res]
8. P → U: m2
sendProof. U sigue los siguientes pasos:
1. descifra res = DKS [m2]
2. extrae el cupón de prueba W(i +1)U
3. cifra el cupón de prueba y el cupón de pago previo m3 = EKS [W(i +1)U, WiU]
4. U → P: m3
verifyProof. P sigue los siguientes pasos:
1. descifra DKS [m3] = (W(i +1)U, WiU)
2. verifica si W(i+1)U pertenece a C calculando H(W(i+1)U) WiU
3. actualiza la relación almacenada (C, W(i+1)U, i + 1) F. Depósito
El subprotocolo de depósito permite a P depositar los cupones recibidos de los usuarios e intercambiarlos por un incremento de saldo en su cuenta en B. P puede depositar cupones si la hora actual cumple que τexp < τnow ≤ τd (ver Fig.
1.) aunque no haya recibido toda la cadena. Con el fin de hacer un depósito, P debe mostrar su prueba secreta W1P que demuestra que P es el receptor previsto de C. Entonces, B ejecuta una serie de verificaciones sobre los cupones y la moneda, comprobando si P trata de hacer un depósito múltiple, es decir, que intente depositar cupones que ya habían sido depositados previamente. Finalmente, hacer notar que sólo la mitad de los cupones recibidos tienen valor monetario, por lo que se divide el número total entre 2.
El subprotocolo de depósito es representado de la
siguiente forma:
requestDeposit. P sigue los siguientes pasos:
1. construye la solicitud r = (C, W1P, WkU, k) 2. cifra la solicitud m1 = EPKB [r]
3. P → B: m1, CertP
doDeposit. B sigue los siguientes pasos:
1. descifra la petición r = DSKB [m1] = (C, W1P, WkU, k) 2. verifica la firma de C (como en la ecuación (1)) 3. verifica si τexp < τnow ≤ τd
4. comprueba la prueba secreta de P como W0P H(W1P) 5. verifica la reutilización: si k ≤ j entonces P niega y detiene la
operación
6. verifica si WkU pertenece a C calculando H(k - j)(WkU) WjU
7. deposita en la cuenta de P el valor de los cupones, dependiendo de si (k – j) es:
a. par, entonces B deposita (k – j)/2 cupones b. impar, entonces B deposita (k – j – 1)/2 cupones G. Intercambio Anónimo
El subprotocolo de intercambio anónimo puede ser ejecutado por U durante τd < τnow ≤ τr (ver Fig. 1) y permite a U el intercambio, a través de B, de una moneda parcialmente usada por otra sin ningún vínculo con la anterior. Este proceso es anónimo ya que U no necesita autenticarse a B con su identidad. Al final de esta etapa, U ha obtenido una moneda nueva C’. Es importante señalar que esta moneda no puede ser utilizada por U para acceder a cualquier P, está especialmente destinada a su uso posterior en el subprotocolo de reembolso, para solicitar a B la devolución del dinero correspondiente a los cupones no usados.
El subprotocolo de intercambio anónimo es muy similar a la etapa de retirada de moneda (ver el apartado 5.D), por lo que no es necesario explicitarlo aquí. El subprotocolo exige inicialmente a U enviar la antigua moneda C parcialmente usada a B, junto con un nuevo y aleatorio W0P autogenerado como si él mismo fuera P. Por otra parte, B tiene que comprobar si la moneda antigua ha sido totalmente depositada por P o si realmente existen cupones que no han sido gastados, con el fin de evitar un fraude de doble gasto. Si C no está totalmente gastada, entonces B comprueba el número de cupones no utilizados con el fin de crear una nueva moneda C’, con la longitud correspondiente al número de cupones no usados de C.
H. Reembolso
Si la moneda ya había sido parcialmente utilizada, U habrá ejecutado la etapa de intercambio anónimo antes de solicitar el reembolso. Así pues, U dispone de una nueva moneda C’
sin relación con la antigua C. Entonces, puede devolver C’ y su valor será reembolsado al saldo de U en B. P no tiene ningún conocimiento sobre la existencia de C’ por lo que nunca puede ser depositada por él. Por otra parte, ni B ni P son capaces de rastrear C y por lo tanto no pueden deducir
ningún tipo de identificación del usuario U que usó esta moneda. Notar que si no se ha usado ningún cupón de la moneda C, U puede pasar a ejecutar el subprotocolo de reembolso sin pasar por el intercambio anónimo.
El subprotocolo de reembolso es muy similar a la subprotocolo de depósito porque tienen la misma finalidad:
incrementar el saldo de las cuentas en función del número y el valor de los cupones de pago. Las dos diferencias entre ambos subprotocolos son: la primera es que la solicitud de U está compuesta por el mensaje r = (C, WiU, i), es decir, sin el elemento W0P; la segunda es el intervalo de tiempo durante el que puede ejecutarse el reembolso que ahora debe cumplir que τd < τnow ≤ τr (ver Fig. 1.).
El subprotocolo de reembolso se describe a continuación:
requestRefund. U sigue los siguientes pasos:
1. construye la solicitud r = (C, WiU, i) 2. cifra la solicitud m1 = EPKB [r]
3. U → B: m1, CertU
doRefund. B sigue los siguientes pasos:
1. descifra la petición r = DSKB [m1] = (C, WiU, i) 2. verifica la firma de C (como en la ecuación (1)) 3. verifica si τd < τnow ≤ τr
4. comprueba la reutilización: si i ≤ j entonces B niega y detiene la operación
5. verifica si WiU pertenece a C calculando H(i - j)(WiU) WjU
6. deposita en la cuenta de U el valor de los cupones, dependiendo de si (i – j) es:
a. par, entonces B deposita (i – j)/2 cupones b. impar,entonces B deposita (i – j – 1)/2 cupones
I. Aplicación a los Servicios Basados en Localización Tal como se ha señalado en la Sección III.A, los micropagos pueden aplicarse al acceso a los servicios LBS que requieran de un pago para obtener la información deseada. Las propiedades de los micropagos en general, y las del esquema presentado en este trabajo en particular, se amoldan a los requerimientos necesarios de seguridad para los servicios LBS, esto es: anonimato de los usuarios, imposibilidad de rastreo (no poder generar perfiles de usuario) y no vinculación entre localizaciones del mismo usuario.
En el caso del protocolo presentado, para ser adaptado al acceso a servicios LBS tan solo habría que modificar ligeramente el protocolo de transferencia. En este protocolo, el primer mensaje que envía U a P, contendría la pregunta que quiere realizar el usuario a su proveedor de servicio referente a su posición actual, tal como determinar donde está el cine o el hospital más cercano, o el estado del tráfico.
Entonces, en el segundo mensaje de P a U, se enviaría la respuesta, de la misma forma como se hace en el protocolo original.
Con esta simple adaptación, el micropago genérico se convierte en un esquema de acceso a servicios LBS de pago, donde además se protegen los datos de localización del usuario.
VI. ANÁLISIS INFORMAL DE LAS PROPIEDADES DE SEGURIDAD En esta sección vamos a dar cuenta de las propiedades de seguridad del esquema propuesto. La primera proposición aborda el anonimato, la no vinculación y la no rastreabilidad. El anonimato se refiere a la confidencialidad de la identidad del usuario en el sistema de tal manera que el usuario es capaz de utilizar el servicio sin la necesidad de ser identificado. La propiedad de no vinculación considera que si diferentes comunicaciones no pueden ser atribuidas al mismo agente, entonces no se pueden establecer relaciones entre los remitentes de las diferentes transacciones. La no rastreabilidad es la indistinción de las interacciones pasadas y futuras de la identidad del usuario con el conocimiento de la transacción actual. Por lo tanto, el adversario no ha de ser capaz de identificar al usuario. En general, la no rastreabilidad implica anonimato.
PROPOSICIÓN 1. El sistema propuesto preserva la privacidad del usuario. Así, el sistema proporciona el anonimato para el usuario frente al proveedor de servicios y sólo es n- vinculable además de no rastreable.
Observación 1. El sistema protege la identidad de U cuando utiliza el servicio.
Demostración. La comunicación entre U y B no puede ser anónima ya que los clientes tienen que autenticarse con el fin de tener acceso a la cuenta de su banco y entonces se le permite retirar las monedas que se utilizarán en el sistema. Sin embargo, el usuario U es anónimo frente al proveedor P. U tiene que interactuar con P para utilizar el servicio solicitado mediante el uso del subprotocolo de transferencia y así utilizar una serie de cupones de la moneda extraída para pagar a P. Entonces, P puede verificar la moneda y prestar el servicio, pero no es capaz de identificar a U. Por tanto, no hay intercambio de información sobre la identidad del usuario.
Observación 2. El proveedor sólo puede vincular los pagos realizados con la misma moneda.
Demostración. El esquema propuesto es sólo c- vinculable. Los pagos efectuados con la misma moneda son vinculables porque utilizan la misma cadena de hash con W0U
como elemento raíz de la misma. En tanto que cada moneda emitida contiene 2c cupones, el proveedor puede vincular las c transacciones que como máximo se pueden realizar con esta moneda. Sin embargo, P no puede vincular los pagos de monedas diferentes y no es capaz de vincular una moneda a una identidad de usuario. Por tanto, la vinculación del sistema puede ser controlada por la longitud de la cadena de 2c cupones.
Observación 3. El sistema es imposible de rastrear, es decir, no es posible vincular la identidad de un usuario con el servicio solicitado.
Demostración. A pesar de la autenticación que los usuarios realizan en el momento de ejecutar el subprotocolo de retirada, no es posible vincular la moneda emitida con la identidad del usuario, debido al uso de un esquema de firma parcialmente ciega. Gracias a esta técnica criptográfica, el par de elementos que identifican una moneda (W0U,W0P) está oculto para B. Además, P no es capaz de identificar a U como hemos dicho más arriba. Por lo tanto, no es posible rastrear las actividades de un usuario en el sistema, puesto que para cada actividad (es decir, todas las solicitudes de un mismo usuario al proveedor), el conjunto de cupones gastados no puede ser asociado a ninguna identidad, incluso ante una confabulación entre B y P.
Observación 4. Se logra la privacidad del usuario.
Demostración. La privacidad de los mensajes intercambiados entre U y P se asegura mediante el uso de una clave compartida KS que sólo es conocida por U y P, ya que esta clave se ha intercambiado de forma segura usando un protocolo de intercambio de claves. P podría construir un historial de las peticiones de U, pero esté siempre estará limitado ya que el sistema es n-vinculable. Por tanto, no puede vincular el perfil con una identidad.
RESULTADO DE LA PROPOSICIÓN 1. De acuerdo con las observaciones 1, 2, 3 y 4, la identidad del usuario está oculta en todas las transacciones, por lo que la privacidad de los usuarios se conserva. Podemos asegurar que el protocolo alcanza los requisitos de seguridad de anonimato, la no rastreabilidad y es solo n-vinculable.
PROPOSICIÓN 2. Una compra es un caso particular de intercambio equitativo donde una parte envía una moneda (o una parte) y a cambio de recibir el bien solicitado.
El micropago propuesto presenta la característica de equidad.
Observación 5. El intercambio entre un micropago y el servicio requerido es equitativo.
Demostración. En el subprotocolo de transferencia, un cupón (o un grupo de cupones) es intercambiado por un servicio. En este punto, pueden surgir algunos casos conflictivos que pueden afectar la equidad del intercambio:
• Caso 1: P, maliciosamente, no envía la respuesta del servicio en el segundo paso. P se daña a sí mismo porque no puede hacer un depósito en B ya que sólo tiene el cupón de pago. U no enviará el cupón de prueba si no recibe lo requerido de P.
• Caso 2: U no envía el cupón de prueba en el tercer paso. U tiene el bien requerido y P no tiene el cupón de prueba, por lo que P está en desventaja frente a U.
En este caso, P rechazará el servicio para las siguientes solicitudes hechas por U hasta que éste no le envíe el cupón de prueba o un cupón de pago nuevo con
un identificador de orden superior. P sólo puede perder un cupón en la peor situación (el último cupón). Este hecho es asumible, ya que cada cupón tiene un valor bajo. Aunque P pierda un cupón, podrá depositar los cupones restantes de la moneda hasta el último cupón recibido.
RESULTADO DE LA PROPOSICIÓN 2. De acuerdo con la observación 5, el sistema de micropago propuesto es equitativo. En la peor situación, P solo puede perder un cupón si U no es equitativo en la última transacción disponible o antes de abandonar el servicio y no volver a acceder a él.
PROPOSICIÓN 3. Las especificaciones del protocolo aseguran que no es posible cometer fraude con las monedas.
Observación 6. No es posible robar monedas o cupones.
Demostración. Las monedas y los cupones no pueden ser robados, ya que la transferencia de cada cupón está protegida con una clave simétrica segura y además, se revelan solamente uno por uno. Si el robo es de toda la moneda, el atacante no puede depositarla sin el conocimiento de la prueba W1P, que solo conoce P.
Observación 7. El esquema impide el gasto doble.
Demostración. Tanto P como B mantienen una tripla (i ,Wi U, C) para todas las monedas válidas y que aún no han expirado. Cuando P recibe un nuevo cupón de U en el subprotocolo de transferencia, P almacena y aumenta el índice i. Entonces, P detecta y evita la reutilización de un cupón al recibir de U un cupón con un índice menor o igual que el índice almacenado en la base de datos de P. Si esto sucede, P negará el servicio a U. Además, este proceso no revela la identidad del usuario, por lo que sigue siendo anónimo.
En el subprotocolo de depósito y en el de devolución, la prevención de la reutilización es similar, puesto que B también mantiene una lista de monedas válidas juntamente con el índice del último cupón depositado correctamente. La comparación entre el índice actual y el anterior permite a B evitar el gasto doble tal como lo hace P. En el subprotocolo de depósito la identificación del usuario es automática, ya que sólo P es capaz de depositar la moneda con el conocimiento de su prueba secreta.
Observación 8. El sistema protege de la falsificación.
Demostración. La falsificación de una moneda no es posible porque la creación de la misma requiere el conocimiento de la clave privada de B. Para la emisión de una moneda válida se necesita realizar una firma parcialmente ciega. Para ello es necesario conocer los parámetros privados (d, p, q) de B, pertenecientes a su clave privada. Por tanto, sólo B es capaz de construir una
moneda válida.
Observación 9. El sistema evita el exceso de gasto.
Demostración. Cuando se ejecuta el subprotocolo de retirada, debido al hecho que el sistema está basado en un sistema de débito, B disminuye la cantidad de dinero de la cuenta de U en el mismo instante. Por lo tanto, no es posible que un cliente pueda gastar más dinero del que refleja el saldo de su cuenta bancaria.
Observación 10. El esquema permite a U solicitar un reembolso para los cupones no usados.
Demostración. La definición de tres períodos temporales para los subprotocolos de transferencia, depósito y reembolso, permite a los usuarios gastar parcialmente las monedas de cupones. También evita a U la pérdida de los cupones no utilizados. La separación entre el reembolso y el depósito no permite que U pueda pedir el reembolso de un conjunto de cupones que aún no estén depositados por P.
RESULTADO DE LA PROPOSICIÓN 3. De acuerdo con las observaciones 6, 7, 8, 9 y 10 del sistema de micropagos, se puede asegurar que se preserva la seguridad de las monedas:
las monedas robadas no tienen ningún uso, son imposibles de falsificar y el sistema protege de la reutilización y del gasto excesivo. Finalmente, los cupones no utilizados pueden ser reembolsados.
VII. CONCLUSIONES Y TRABAJOS FUTUROS
En este trabajo hemos propuesto un sistema de micropagos que asegura la privacidad de los usuarios. El esquema de micropago es anónimo, ya que la moneda emitida no contiene ningún tipo de identificación del usuario y además es imposible rastrearla, gracias a la utilización de una moneda construida a partir del uso del concepto de firma parcialmente ciega. Por otra parte, el protocolo conserva la equidad de los intercambios, ya que varios de los cupones se intercambian por un bien electrónico. Además, el esquema es eficiente y es adecuado para el uso en dispositivos móviles con recursos limitados. Desde nuestro conocimiento, este esquema es el único que satisface todas estas características.
El análisis de la seguridad del protocolo muestra que el sistema de micropagos asegura que no es posible cometer fraude con las monedas. Así, el sistema es seguro contra la falsificación, el doble gasto y el gasto excesivo.
El trabajo futuro se centrará en la implementación y la evaluación del rendimiento del protocolo presentado sobre una plataforma móvil, como Android o IOS. Mediante la implementación del esquema esperamos poder verificar la aplicabilidad y el desempeño del esquema propuesto sobre diferentes tipos de dispositivos con distintas capacidades de cálculo. También se evaluará su uso sobre la tecnología Near- Field Communications (NFC) para realizar las comunicaciones entre las partes involucradas. La
implementación será muy útil para probar la eficiencia del protocolo teniendo en cuenta las restricciones que presentan los dispositivos móviles, y demostrar así como el esquema es adecuado para este entorno. Por otra parte, queremos aplicar el esquema propuesto para la etapa de pago de otros servicios con similares medidas de seguridad y requisitos de rendimiento en servicios basados en localización (LBS).
REFERENCIAS
[1] M. Abe and E. Fujisaki. How to date blind signatures. In K. Kim and T.
Matsumoto, editors, Advances in Cryptology | ASIACRYPT '96, volume 1163 of Lecture Notes in Computer Science, pages 244-251. Springer Berlin / Heidelberg, 1996. 10.1007/BFb0034851.
[2] P. R. Bayyapu and M. L. Das. An Improved and Efficient Micro-payment Scheme. Journal of Theoretical and Applied Electronic Commerce Research, 4(1):91-100, April 2009.
[3] L. Butty_an. Removing the financial incentive to cheat in micropayment schemes. Electronic Letters, 36(2), 2000.
[4] T. Cao, D. Lin, and R. Xue. A randomized RSA-based partially blind signature scheme for electronic cash. Computers & Security, 24(1):44-49, 2005.
[5] D. Chaum. Blind Signatures for Untraceable Payments. Advances in Cryptology: Proceedings or Crypto, 1983.
[6] H. Chien, J. Jan, and Y. Tseng. RSA-based Partially Blind Signature with Low Computation. International Conference on Parallel and Distributed Systems IC-PADS 2001, pages 385-389, 2001.
[7] S. S. Chow, L. C. Hui, S. Yiu, and K. Chow. Two Improved Partially Blind Signature Schemes from Bilinear Pairings. ACISP 2005, LNCS 3574:316-328, 2005.
[8] T. Elgamal. A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms. IEEE Transactions on Information Theory, Vol. 31, No. 4, 1985.
[9] S. Even, O. Goldreich, and S. Micali. On-line/offline digital signatures.
Advances in Cryptology CRYPTO '89, LNCS 435, p. 263-277, 1989.
[10] C. Fan. Improved low-computation partially blind signatures. Applied Mathematics and Computation, 145(2-3):853-867, 2003.
[11] N. Haller. The s/key one-time password system. RFC 1760, 1995.
[12] R. Hauser, A. Przygienda, and G. Tsudik. Reducing the cost of security in link state routing. In Proceedings of the Symposium on Network and Distributed Systems Security (NDSS '97), pages 93{99, 1997.
[13] A. P. Isern Dey_a, M. Payeras-Capell_a, M. Mut-Puigserver, and J. L.
Ferrer-Gomila. Anonymous, Secure and Fair Protocol to Access Location- Based Services Subject to Payment. Advances in Mobile Computing and Multimedia, MoMM 2010, pages 444-449, 2010.
[14] L. Lamport. Password authentication with insecure communication.
Communica-tions of the ACM 24, 1981.
[15] R. Lipton and R. Ostrovsky. Micro-payments via e_cient coin-ipping. In R.
Hirchfeld, editor, Financial Cryptography, volume 1465 of Lecture Notes in Computer Science, pages 1-15. Springer Berlin / Heidelberg, 1998.
10.1007/BFb0055469.
[16] L. Liu. Privacy and location anonymization in location-based services.
SIGSPATIAL Special, Volume 1, Issue 2 (July 2009), pp. 15-22, 2009.
[17] A. M. and O. T. Provably secure partially blind signatures. Advances in Cryptology, CRYPTO 2000, LNCS 1880:271-286, 2000.
[18] S. Micali. E_cient certi_cate revocation. Technical Report MIT/LCS/TM- 542b, Massachusetts Institute of Technology, Laboratory for Computer Science, 1996.
[19] T. Okamoto. Efficient blind and partially blind signatures without random oracles. Theory of Cryptography, pages 80-99, 2006.
[20] T. Poutanen, H. Hinton, and M. Stumm. NetCents: A lightweight protocol for secure micropayments. In USENIX Workshop on Electronic Commerce, pages 25-36, 1998.
[21] R. L. Rivest and A. Shamir. PayWord and MicroMint: Two Simple Micropayment Schemes. LNCS 1189, pp. 69-87, 1996.
[22] C. Schmidt and R. M uller. A framework for micropayment evaluation.
NETNOMICS, pages 187-200, 1999.
[23] Q. Wu, W. Susilo, Y. Mu, and F. Zhang. E_cient partially blind signatures with provable security. Computational Science and Its Applications, ICCSA 2007, LNCS 4707:1096-1105, 2007.
[24] C. N. Yang, T. Lin, and T. S. Chen. Enhanced fair micropayment scheme based on hash chain to avoid merchant collusion. In Consumer Electronics ISCE 2005, pages 39-42, 2005.
[25] Y. Zongkay, L. Weimin, and T. Ynmeng. Fair Micropayment System Based on Hash Chain. Tsinghua Science and Technology, 10(3):328-333, June 2005.
