ES2425618A1 - Método para realizar transacciones con billetes digitales - Google Patents

Método para realizar transacciones con billetes digitales Download PDF

Info

Publication number
ES2425618A1
ES2425618A1 ES201230268A ES201230268A ES2425618A1 ES 2425618 A1 ES2425618 A1 ES 2425618A1 ES 201230268 A ES201230268 A ES 201230268A ES 201230268 A ES201230268 A ES 201230268A ES 2425618 A1 ES2425618 A1 ES 2425618A1
Authority
ES
Spain
Prior art keywords
digital
ticket
digital ticket
user
signature
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
ES201230268A
Other languages
English (en)
Other versions
ES2425618B1 (es
Inventor
Josep DOMINGO FERRER
Jordi CASTELLÀ ROCA
Arnau VIVES GUASCH
Jordi ARAGONÉS VILELLA
Llorenç HUGUET ROTGER
Josep Lluís FERRER GOMILA
Macià MUT PUIGSERVER
M. Magdalena PAYERAS CAPELLA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Universitat de les Illes Balears
Universitat Rovira i Virgili URV
Original Assignee
Universitat de les Illes Balears
Universitat Rovira i Virgili URV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Universitat de les Illes Balears, Universitat Rovira i Virgili URV filed Critical Universitat de les Illes Balears
Priority to ES201230268A priority Critical patent/ES2425618B1/es
Priority to PCT/ES2013/000045 priority patent/WO2013124499A1/es
Publication of ES2425618A1 publication Critical patent/ES2425618A1/es
Application granted granted Critical
Publication of ES2425618B1 publication Critical patent/ES2425618B1/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Facsimile Transmission Control (AREA)

Abstract

Método para realizar transacciones con billetes digitales. El método es aplicable a billetes digitales provistos de un identificador, una prueba de validez y una información relativa a un derecho de uso asociado a dicho billete digital, comprendiendo las etapas de: a. envío por un usuario propietario UP de una oferta de transacción del billete digital; b. verificación de la prueba de validez de dicho billete digital por parte de un usuario receptor UR; c. generación de una petición de transferencia de dicho UR a dicho UP; d. verificación por dicho UP de dicha petición de transferencia y generación por dicho UP de una aceptación de transferencia; e. verificación por dicho UR de dicha aceptación de transferencia; y f. transferencia del billete digital a UR que adquiere el derecho de uso.

Description

Método para realizar transacciones con billetes digitales
Sector de la técnica
La presente invención concierne en general, a un método para transacciones con billetes digitales/electrónicos y en particular, a un método que comprende la obtención y uso de un billete digital entre usuarios.
La presente invención contiene partes tales como las explicaciones detalladas acerca de los protocolos empleados, yen particular el protocolo de transferencia de un billete digital, susceptibles de protección bajo Copyright y los inventores se reservan los derechos de autoría sobre las mismas.
Antecedentes de la invención
La evolución de los dispositivos móviles, y sobre todo el aumento del uso de Internet en estos dispositivos, ha permitido que ciertas actividades comunes, como por ejemplo comprar, buscar información, o jugar se puedan realizar remotamente. La presente invención concierne a la compra del derecho de uso de un servicio mediante la obtención y uso de un billete digital. Por ejemplo y sin que deba entenderse como limitativo contratar un servicio como una entrada para un evento o medio de transporte.
El billete digital es una representación digital de un billete físico, ya sea un billete de un medio de transporte o bien, una entrada de acceso a un evento determinado. Una vez realizada la compra o el pago, el billete digital existe sólo como un registro digital. El comprador recibe en su dispositivo móvil el equivalente al billete real, y este será usado para garantizar el acceso al servicio contratado.
Ejemplos del uso de un billete digital se encuentran en el transporte aéreo. En Mayo de 2007 Vodafone y Spanair realizaron un test de billete digital en España. Los pasajeros recibían una tarjeta de embarque digital en su dispositivo móvil, esto daba derecho al pasajero a acceder directamente a la zona de control y, seguidamente, al avión.
La lATA (International Air Transport Association) empezó en 2004 un programa para potenciar el uso de los billetes digitales. Se realizó una estimación de que el uso de dichos billetes digitales ahorraría a las compañías aéreas una cantidad muy significativa de dinero.
Otro ejemplo del uso de los billetes digitales se da en la República Checa donde AMSBUS permite la reserva de transporte mediante mensajes SMS.
El equipo de futbol Leeds United, puso a disposición de sus seguidores la reserva de entradas para sus partidos. Dichos seguidores recibían en sus dispositivos móviles un SMS con la confirmación de la reserva además de información adicional, como por ejemplo, el asiento reservado.
Por la W02009/141614 se conoce un método para transacciones con billetes digitales en el cual una imagen se muestra en un dispositivo móvil para facilitar una inspección. El método comprende recibir datos específicos del billete digital en un dispositivo móvil. Los datos se presentan en la forma de un código leíble por una máquina que define al menos un único número de billete y unos medidos de autenticación. El método comprende también ejecutar una aplicación en el dispositivo móvil de manera que proporcione información textual y gráfica en la pantalla del dispositivo móvil para permitir una autenticación de la información textual.
Estos ejemplos muestran la introducción del billete digital en distintos servicios y el aumento del uso de los dispositivos móviles como unidad de almacenamiento. Uno de los puntos clave para su implantación definitiva recae en la seguridad que estos puedan ofrecer, esto es debido a la facilidad de copia de la información digital. Los billetes digitales deben ofrecer la misma seguridad que la proporcionada por los billetes en papel.
En un billete real, normalmente de soporte papel, el propietario de dicho billete puede comprobar su veracidad por distintos medios. El billete puede incorporar medidas antifraude, como por ejemplo, un tipo determinado de papel, uso de tinta específica, zonas con hologramas, etc ... En cambio, en el caso del billete digital el comprador necesita que el billete contenga distintas características que garanticen su seguridad que normalmente no se pueden comprobar por inspección visual.
Las características básicas que un billete digital debe ofrecer son las siguientes:
No repudio: el ente que ha emitido el billete digital no puede negar su autenticidad.
Integridad: el billete digital no puede ser modificado sin que dicha modificación sea detectada.
Anonimato y revocabilidad: el billete digital es anónimo aunque, si el usuario hace un uso indebido,
dicho usuario puede ser identificado. La característica de anonimato puede no ser posible, según el
servicio.
5 Reusabilidad: dependiendo de las necesidades y características del servicio el billete digital puede ser usado una o múltiples veces. Cada servicio tendrá unos u otros requisitos.
Fecha de validez: el billete digital puede ser válido durante un intervalo definido de tiempo.
Online/Offline: la verificación del billete digital puede requerir (o no) una conexión a una red de ordenadores para su validación.
Exculpabilidad: el proveedor del servicio no puede acusar falsamente al usuario del billete digital de no haberlo validado antes de usarlo.
Transferibilidad: el billete digital puede ser transferido a otros usuarios conservando todas las características mencionadas anteriormente.
Existe un amplio abanico de medidas de seguridad digital genéricas que pueden ser empleadas para aportar
15 seguridad a un sistema de billete digital. Dependiendo del sistema utilizado la aplicación variará. Un ejemplo de tales medidas serían las basadas en Smart-cards. Dichas Smart-cards verifican cada operación, de modo que el usuario no puede realizar ninguna acción no permitida. La seguridad de estos sistema está basada en la propia seguridad de la propia Smart-card, si esta falla, el sistema se ve comprometido como es el caso de "A practical attack on the mifare classic" de Gerhard Koning Gans, Jaap-Henk Hoepman y Flavio D. Garcia, donde comprometen la seguridad de las tarjetas Mifare. En la literatura científica se encuentran distintas medidas de seguridad implementadas en las Smart-cards, como por ejemplo, Electronic ticket scheme for its de S. Matsuo y
W. Ogata, Application of electronic ticket to online trading with smartcard technology de W.I. Siu y Z.S. Guo, The secure communication protocol for electronic ticket management system de W.I. Siu y Z.S. Guo.
Para sistemas no basados en Smart-cards, como es el caso de esta invención, se propone el uso de distintas
25 técnicas criptográficas, que requieren cálculos avanzados y, por lo tanto, el uso de dispositivos móviles con capacidad avanzada de cálculo, como los teléfonos móviles, PDAs, etc. Estos sistemas pueden ser de dos tipos: 1) No anónimos, hay servicios que el anonimato no es una opción, en estos casos la firma digital es la técnica criptográfica más común, un ejemplo es Oigital-ticket-controlled digital ticket circulation de K. Fujimura, H. Kuno,
M. Terada, K. Matsuyama, Y. Mizuno y J. Sekine. 2) No-repudiación-anonimato, una técnica habitual para proporcionar el anonimato es mediante el uso de seudónimos, y nuevamente, la técnica más común es la firma digital, esta técnica proporciona al billete digital las propiedades de autenticidad, no repudiación e integridad. Algunas propuestas de interés aparecen en Ticket based service Access for the mobile user de B. Patel y J. Crowcroft, Motet: Mobile transactions using electronic tickets de D. Ouercia y S. Hailes. En el caso de la propuesta realiza por Patel y Crowfort los billetes pueden ser reutilizados; Ouercia y Hailes considera que la
35 reusabilidad depende del servicio. Otras propuestas proponen una solución para la propiedad de online/offline, es el caso de Privacy for Public Transportation de T.S. Heydt-Benjamin, H.J. Chae, B. Defend y K. Fu (online) y Electronic-onboard-ticketing: Software challenges of an state-of-the-art m-commerce application de F. Hanenberg, K. Stenzel y W. Reif.
Algunas invenciones previas presentan sistemas y/o métodos de billete digital que garantizan alguna de las propiedades anteriores pero no todas a la vez. Los ejemplos más remarcables son las invenciones descritas en US7809593 Method and system for automatically keeping travel data consistent between passenger reservation records and corresponding electronic tickets de Douck et al. US7907896 Mobile commerce method and de vice de Chitti, US7685020 Mobile commerce receipt system de Do et al. US7520427 Method of operating a ticketing system de Boyd, US2010170947 System and method for electronic ticket verification, identification, and
45 authorization with a wireless communication device de C. Bruce, PCT/IB2005/000948 Methods and systems to purchase bookings de A. Rangnekar et al. Todas estas invenciones únicamente describen la operatividad del método de comunicación y verificación de los billetes digitales, pero no hacen hincapié en los problemas de seguridad y privacidad mencionados anteriormente.
Un segundo grupo, siendo ejemplos representativos CN1987903 Non-contact paper base electronic passenger ticket based on electronic label technology de K. K. Hu et al., EP1752936 Method of downloading ticketing keys de R. Denis et al., W02005111953 Improved ticketing scheme de H. B. SIM et al., KR20050057563 Wireless communication de vice providing a contactless interface for a Smart card reader de P. Lau ri, E P2081140 Method and system for protecting a transaction de S. Spitz et al. contemplan tan sólo la seguridad a nivel de hardware. Dichas invenciones cifran las comunicaciones y el almacenaje del billete digital para asegurar su privacidad, sin importar la seguridad y/o privacidad del propio billete digital. Estos métodos no garantizan las propiedades equivalentes en un billete real.
Las invenciones descritas en US6725376 Method of using an electronic ticket and distributed server computer architecture for the same de S. Levent, US2010005304 Security and ticketing system control and management 5 de M. Hiroshi, W003048892 Access, identity, and ticketing system for providing multiple access methods for Smart devices de S.M. Myra, contemplan la seguridad en el billete digital proporcionando algunas características como el anonimato o la integridad. Las anteriores invenciones utilizan un sistema de criptografía basada en hash. Un ejemplo del uso de criptografía basada en hash aparece en Method of using an electronic ticket and distributed server computer architecture for the same donde la información que contiene el billete digital es 10 utilizada para obtener un valor hash. Este valor hash es cifrado utilizando un servidor de autenticación y una clave privada, y se concatena el valor resultante con la información del billete digital. De esta manera al hacer la validación del billete digital se asegura la integridad de dicho billete y puede ser transmitido por medios no seguros. Esta invención no asegura el anonimato del billete digital, tan sólo su integridad. El problema de la solución propuesta en dicha invención es que no incluye características como revocabilidad, exculpabilidad,
15 anonimato, etc.
La US 7188358 describe un billete digital de acceso personalizado y período de validez prefijado, que contiene unas identificaciones anónimas de un remitente y de un receptor en una correspondencia por e-mail, así como un esquema para una comunicación en red con un mecanismo de ocultación.
En la US 7630927 se describe un método de pago anónimo y seguro, en línea, y un método basado un una firma 20 criptográfica ciega parcial, con anonimato revocable.
Se consideran también de interés por la forma de construir el billete digital o por las propuestas relativas a la transacción de los billetes los documentos US 7630927 y US 2011/0119098.
Breve descripción de la invención
De lo anteriormente expuesto se desprende que es necesaria una alternativa al estado de la técnica que permita
25 la obtención y uso de un billete digital ofreciendo las características básicas que este tipo de billetes requieren, antes citadas en lo que se refiere por lo menos a la: seguridad, privacidad, anonimato, revocabilidad y exculpabilidad, y que posibilite ser transferido conservando todas estas propiedades que son trasladadas al nuevo propietario.
Para ello la presente invención concierne a un método para realizar transacciones con billetes digitales, en donde 30 dicho billete digital contiene al menos:
un identificador enlazado directa o indirectamente a unas condiciones de contrato;
una prueba de validez creada por el emisor de dicho billete digital, y
una información relativa al derecho de uso de un usuario propietario (UP) que ha adquirido dicho billete digital.
35 El citado identificador en una primera realización contiene la fecha de emisión del billete digital y dicha prueba de validez contiene una firma digital de dicho emisor que garantiza autenticidad, no repudio e integridad de dicho billete digital.
Por su parte dicho derecho de uso comprende al menos una vinculación entre dicho identificador del billete digital y dicho UP realizada mediante una firma digital de dicho UP o un certificado digital de dicho UP.
40 En una realización alternativa dicho derecho de uso comprende una vinculación entre dicho identificador del billete digital y dicho UP realizada mediante una primera firma digital de grupo que proporciona un anonimato revocable a dicho UP.
La información relativa al derecho de uso de un usuario receptor (UR) que ha adquirido el billete digital contiene además datos acerca de transferencias anteriores y comprende una etapa adicional de verificación de dichas
45 transferencias anteriores por parte de dicho URo
Por otro lado el referido billete digital de acuerdo con una realización de esta invención ha sido obtenido mediante las siguientes etapas:
generar un precontrato (compromiso efectivo entre un emisor y un UP) a partir de una petición de billete digital por parte de dicho UP mediante una firma digital de dicho emisor;
verificar dicho precontrato por parte de dicho UP;
aceptar dicho precontrato creando una vinculación UP billete digital; y
emitir el billete digital mediante una firma digital del emisor.
El método de la presente invención comprende, de acuerdo con lo anteriormente indicado, una transmisión segura de dicho billete digital entre usuarios: usuario propietario UP y usuario receptor UR, con transferencia segura de dicho derecho de uso, y las restantes propiedades indicadas.
El método, en relación con dicha transferencia segura, comprende las siguientes etapas:
a) envío por parte de dicho UP de una oferta de transacción; a dicho UR;
b) verificación de dicha prueba de validez por parte de dicho UR (esta verificación puede realizarse por medios diversos);
c) generación de una petición de transferencia de dicho UR a dicho UP;
d) verificación de dicha petición de transferencia por parte de dicho UP (igualmente llevada a cabo por medios diversos), y generación por dicho UP de una aceptación de transferencia; y
e) verificación por dicho UR de dicha aceptación de transferencia; y f) transferencia del billete digital adquiriendo dicho UR el citado derecho de uso de dicho UP.
La citada verificación de dicha prueba de validez consiste en la verificación de dicha firma digital de dicho emisor UP.
Para dicha transmisión se ha previsto en un ejemplo de ejecución (en el caso de vinculación entre dicho identificador del billete digital y dicho UP realizada mediante una firma digital de grupo) realizar una segunda firma digital de grupo por parte de dicho UP que se enlaza con dicha primera firma digital de grupo proporcionando una garantía de que UP es el que transfiere preservando su anonimato.
El método incluye para reforzar la estrategia de protección una etapa adicional consistente en proporcionar a dicho UP una prueba de su derecho de uso del billete digital a dicho UR, que prueba dicha vinculación entre identificador y UP.
Breve descripción de las figuras
Las anteriores y otras ventajas y características se comprenderán más plenamente a partir de la siguiente descripción detallada de unos ejemplos de realización con referencia a los dibujos adjuntos, que deben tomarse a título ilustrativo y no limitativo, en los que:
La Fig. 1 muestra la arquitectura utilizada para la emisión del billete digital. La nomenclatura utilizada en la figura es la que se detalla a continuación:
100: usuario, 105: relación de interacción física usuario-dispositivo, 110: terminal portátil del usuario,
120: aplicación del terminal de usuario, 125: sistema de almacenamiento del terminal de usuario, 130: terminal del emisor, 140: aplicación del terminal del emisor, 145: sistema de almacenamiento del terminal del emisor, 150: sistema de comunicación terminales usuario-emisor, 160: terminal bancaria,
170: sistema de comunicación terminales usuario-banco, 180: sistema de comunicación terminales emisor-banco.
La Fig. 2 muestra la arquitectura utilizada para la transferencia del billete digital. La nomenclatura utilizada en la figura es la que se detalla a continuación:
200: usuario emisor, 201: usuario receptor, 205: relación de interacción física usuario emisor-dispositivo,
206: relación de interacción física usuario receptor-dispositivo, 210: terminal portátil del usuario emisor,
220: aplicación del terminal del usuario emisor, 225: sistema de almacenamiento del terminal del usuario emisor, 230: terminal portátil del usuario receptor, 240: aplicación del terminal del usuario receptor, 245:
sistema de almacenamiento del terminal del usuario receptor, 250: sistema de comunicación de terminales usuarios emisor-receptor, 260: terminal bancaria, 270: sistema de comunicación de terminales usuario emisor-banco, 280: sistema de comunicación de terminales usuario receptor-banco.
La Fig. 3 muestra la arquitectura utilizada para la utilización del billete digital. La nomenclatura utilizada en la figura es la que se detalla a continuación:
300: usuario, 305: relación de interacción física usuario-dispositivo, 310: terminal portátil del usuario,
320: aplicación del terminal de usuario, 325: sistema de almacenamiento del terminal de usuario, 330: terminal del proveedor de servicios, 340: aplicación del terminal del proveedor de servicios; 345: sistema de almacenamiento del terminal del proveedor de servicios, 350: comunicación usuario-proveedor.
Las Figs. 4, 5 Y 6 muestran unos diagramas de secuencia utilizados para la emisión, transferencia y utilización del billete digital, respectivamente.
Exposición en detalle de la invención
Para las firmas en el sistema hechas por el usuario, la presente invención utiliza las propiedades de las firmas digitales y de grupo. Aunque existen diferentes propuestas en la presente invención se utiliza el esquema propuesto en SDH (Strong Oiffie-Hellman), [88S04]. Por esta razón, se presentan a continuación las principales definiciones. La notación en la parte que sigue es específica para la explicación de estas definiciones.
En el esquema [8804]) se consideran grupos cíclicos (multiplicativos) GI y G2 de orden primo p con sus respectivos generadores gl y g2., además de una aplicación bilineal e: GI x G2--+ GTY una función hash H: (O,l{ --+ Zp·. Los parámetros públicos son gl, u, V, hE GI Y g2, W E G2. Aquí w = gl para un valor secreto V E Zp.
• KeyGenG(n). En este algoritmo se toma como entrada un parámetro n, que corresponde al número de miembros que formaran el grupo. Se selecciona h {!:.. G¡\{lGIJ Y ';1, .;¿{!:.. Zp', y se calcula u, v E GI tal que Ut;1 = .J2 = h. Se selecciona V {!:.. Zp' y se calcula w = gl. A continuación, se genera después para cada usuario Vi, 1 :5 i:5 n, una tupla SDH (A;, Xi) de este modo: se selecciona Xi {!:.. Zp' y se calcula A;<
g/I(V+XI. La clave privada del creador del grupo (la entidad que puede descubrir la identidad de los firmantes) es gmsk=(';I,';2). Cada clave privada de usuario es su tupla gsk[i] = (A;, Xi). Ninguna entidad puede conocer el parámetro secreto V aparte del creador del grupo.
• SignG(M). Dada una clave pública de grupo gpk =(gl, g2, h, U, v, w), una clave privada de grupo específica de un usuario gsk[iJ = (Ai, Xi) Y un mensaje de entrada M E {O, 1{, un usuario calcula y genera M =(M, a) donde a es la firma de conocimiento a = (T¡, h h e, Sa, sf3, Sx, Sól, SÓ2). Desde el punto de vista del usuario, él conoce su clave privada de grupo gsk = (A, x) y así se refleja en la siguiente notación.
1.
selecciona a, f3 {!:.. Zp y calcula el cifrado lineal de A: (T¡, h T3)+-(ua,,J,Aha+f3) conjuntamente con los valores ól+-xa y ó~xf3;
2.
selecciona (a, (f3, (x,ról, (Ó2 {!:.. Zp y calcula los valores:
3.
obtiene el reto (challenge):
4. calcula los valores:
Scr-ra+ca
s~rx+cx
• VerifyG(M). Dada una clave pública de grupo gpk =(gl,g2,h,u,v,w) y un mensaje firmado con la correspondiente clave privada de un miembro del grupo M=(M, a) como entrada, donde M es el mensaje y a su firma de manera que a =(TI, T2, T3,C,Sa,S/3,Sx,SÓI,SÓ2), un usuario cualquiera puede verificar que a es una firma de conocimiento válida mediante los siguientes pasos.
? ----
10 1. comprueba que C ~ H(M, h h h R 1, R 2, R 3, R 4, R 5).
• OpenG(M). Este algoritmo es utilizado para asignar una firma digital a su concreto firmante del grupo con la finalidad de conocer su identidad. Esta operación únicamente es posible para el creador del grupo, ya que es el único que conoce la clave maestra gmsk, y conoce todos los pares (A;,x¡). Dada la
15 clave pública de grupo gpk =(gl,g2,h,u,v,w), la clave privada maestra de grupo gmsk =(~1,~2), yel mensaje firmado M=(M,a) como entrada, siendo M el mensaje y a =(TI,h T3,C,Sa,Sf3,Sx,SÓI,SÓ2) la firma, se procede como sigue. En primer lugar, recuperar el usuario A¡ ejecutando A¡<---Ty(TP .T/2). Si el gestor del grupo tiene los elementos {Aí} de las claves privadas del usuario, puede buscar el índice del usuario correspondiente a la identidad A¡ recuperada de la firma.
5 Enlazabilidad entre firmas de grupo
En el sistema de la invención, todos los usuarios tienen que ser anónimos, además, sus firmas no pueden ser enlazables una con otra. En algunos casos, por seguridad, determinadas firmas de un mismo usuario podrían ser enlazables entre ellas para garantizar que se trata del mismo usuario.
Procedimiento SignLínkableG
10 Se define un procedimiento de firma enlazable llamada SignLínkableG(M',M) para ser utilizada en el protocolo. Dada una clave pública de grupo gpk, una clave privada de usuario gsk[í] Y un mensaje M', computa y genera la salida M(=(M',a') que puede ser enlazable con el mensaje firmado M. Para utilizar dicho procedimiento correctamente, se sigue el siguiente protocolo:
• Primer uso: firmar de manera normal SignG(M):
15 o generar un cifrado lineal de A: (h h T3)~(Ua,.J,Aha+f3) para a,{3 /!:-Zp;
o dado un m e n s a j e M, f i r m a r e I m e n s a j e y gen e r a r I a salida a~(TI,T2, T3,C,Sa,Sf3,Sx,SÓI,SÓ2) donde c~H(M,TI, T2,T3,RI,R2,R3,R4,R5) E Zp;
• Siguientes usos: SignLínkableG(M',M}' equivale a realizar el procedimiento SignG(M) sin realizar el
1 r paso de la generación de (h h T3). De este modo, se reutiliza la pareja (a,{3) y su resultado 20 (h h T3)=(ua,II,Aha+f3) y se sigue con el 2º paso del procedimiento SignG(M).
o utilizar la misma pareja (a,{3) con el mismo cifrado lineal de A que en la primera firma: (h h T3)=(Ua,.J,Aha+f3);
o dado un mensaje M', firmar el mensaje y generar la salida a'~(TI, T2, T3,C',Sa',Sf3 ',Sx',Sól ',SÓ2} donde:
Se puede demostrar que diferentes firmas son producidas por el mismo usuario, ya que la información (h h T3) es pública en la misma firma. Además, los valores aleatorios (ra',rf3 ',rx',rÓI',rÓ2) deben de ser diferentes que en previos usos, eso es: (ra' f:. ra,{f3' f:. rf3,rx' f:. rx,{ól' f:. ról,ró2' f:. rÓ2) para no revelar información acerca de la identidad del usuario. Nótese también que los valores (RI',R2',R3',R4',R5) se establecen en el 2º paso del procedimiento SignG(M), y dependen de los valores aleatorios (ra',rf3 ',rx',rÓI ',rÓ2) generados.
El procedimiento entonces es:
1.
reutilizar (a, {3) que se generó en el procedimiento de SignG(M) como también el cifrado lineal de A: (h h T3)=(ua,.J,Aha+f3), y los valores ól=xa y Ó2=X{3;
2.
seleccionar ra', rf3 "rx', ról ',ró2 /!:-Zp y calcular los valores:
3. obtener el reto (challenge):
4. calcular los valores:
Procedimiento VerifvLinkableG
Se define también el procedimiento: VerifyLinkableG(M',M''y. Este algoritmo toma como entrada (M'=(M,a),M(=(M',a')) con las 2 firmas a=(h h hC,Sa,S/3,Sx,SÓI,SÓ2) y a'=(TI', T2', T3 ',c',Sa',S/3 ',S/,Sól',Só2'), y genera la salida 'verdadero' o 'falso' dependiendo de si las firmas han sido producidas por el mismo seudónimo del usuario (h h T3):
Prueba de conocimiento nulo (Zero-Knowledge Proof) del esguema de firma de grupo (Group Signaturel
En el sistema se utilizan tanto las firmas digitales de grupo estándar como las enlazables, de modo que se pueda verificar la información interna del mensaje, como también verificar que algunas firmas concretas están relacionadas con el mismo evento/billete digital y pertenecen al mismo usuario. A pesar de estas ventajas, estas 15 firmas son generadas por el mismo usuario, y su verificación se realiza offline o no directamente con el verificador. En algunas situaciones, aparece la necesidad de realizar pruebas interactivas de conocimiento para verificar que un cierto mensaje pertenece a la persona que está queriendo verificar el mensaje firmado/billete digital: es equivalente entonces a decir que el usuario conoce los parámetros secretos (a,{3,x,ól,Ó2) con los cuales se ha generado la firma digital de grupo. Se detallan entonces los protocolos ZKPGCommit,
20 ZKPGResponse y ZKPGVerifyde la siguiente forma:
Procedimiento ZKPGCommit(MI
Este procedimiento es realizado por la entidad que quiere demostrar el conocimiento de un cierto valor. Dada
una clave pública de grupo gpk =(gl,g2,h,u,v,w), una clave privada de grupo de un determinado usuario gsk[iJ
=(A;,x¡) y un mensaje auto-firmado M=(M,a) donde a es la firma de conocimiento a =(hT2, hC,Sa,S/3, Sx,Sól,Só2),
se genera una nueva información de compromiso (commitment) para ser verificada de manera activa:
m'={TI, T2, T3,RI',R2',R3',R4',R5').
1.
se tiene que demostrar el conocimiento de (a,f3,x,ól,Ó2), que ha sido generado para la firma de M, guardando entonces los valores resultantes como el cifrado lineal de A: (T¡, h T3)={ua,.J,Aha+f3);
2.
seleccionar ra',rf3',rx',ról ',ró2 f!:-Zp y computar los valores:
Procedimiento ZKPGResponse(m',c')
Dado un compromiso m'={T¡, h hRI',R2',R3',R/,R5} y un reto (challenge) c' elegido por el verificador, el 10 demostrador genera una respuesta a la ZKP como sigue:
1.
calcular los valores:
2.
generar como salida la respuesta S '={Sa',Sf3 ',Sx',SÓI ',SÓ2}.
Procedimiento ZKPGVerifv(m',c',s')
15 Dado un compromiso m'={T¡, h T3,RI',R2',R3',R4',R5}, un reto c' elegido por el verificador, y su respuesta S '={Sa ',Sf3 ',Sx',Sól ',SÓ2} generada por el demostrador, el verificador prosigue con estos pasos:
1. comprobar que:
Enlazabilidad entre firmas digitales
Dos firmas digitales convencionales estarán enlazadas si han sido emitidas por el mismo emisor que dispone de la clave privada.
En relación con las citadas Figs. 1 a 3, la nomenclatura utilizada y una posible implementación son las que se detallan a continuación:
En una implementación preferida, pero que no limita la invención, el terminal de usuario (110, 210, 230, 310) puede ser un dispositivo portátil (p.ej. teléfono móvil, _smartphone, PDA, Tablet, etc.), la aplicación del terminal de usuario (120, 220, 240, 320) puede ser una aplicación para el dispositivo portátil (p.ej. aplicación J2ME, Android, iPhone, etc.) o incluso una aplicación en modo tarjeta (p.ej. JavaCard), utilizando una unidad de almacenamiento (125, 225, 245, 325) (p.ej. Secure Element del móvil, tarjetas SD, microSD, SIM, UICC, memoria interna del dispositivo, disco duro, base de datos, etc.)
En la parte del emisor del billete, el terminal (130) puede ser una máquina o servidor que tenga una aplicación
(140) (con lenguajes de programación diversos, como p.ej. Java, C#, C++, etc.) y con una unidad de almacenamiento (145) (como p.ej. base de datos, etc.).
En la parte del proveedor de servicios, su terminal (330) puede ser una máquina o servidor que tenga una aplicación (340) (con lenguajes de programación diversos, como p.ej. Java, C#, C++, etc.) y con una unidad de almacenamiento (345) (como p.ej. base de datos, etc.).
La comunicación entre las aplicaciones de emisor/proveedor de servicios y usuario (150, 250, 350) puede estar basada en la tecnología de corto alcance Near Field Communication (NFC), tanto en los modos peer-to-peer (IS018092) como en modo tarjeta (IS014443, etc.) o Read/Write, pero no excluye otros modos de comunicación como por ejemplo: el acceso a Internet, mediante la pila de protocolos TCP/IP, WAN (Wide Area Network), o WWAN (Wireless Wide Area Network, que incluye 3G, UMTS, HSPA, etc.), RFID o Bluetooth entre otros.
La terminal bancaria (160, 260) puede ser también un entramado de terminales bancarias interrelacionadas entre sí, comunicando las entidades bancarias tanto del usuario como del emisor del billete digital. Así pues, la comunicación (170, 270) entre el terminal de usuario (110, 210, 230) Y la entidad bancaria (160, 260) puede ser una conexión de largo alcance, como por ejemplo, a través del acceso a Internet, mediante la pila de protocolos TCP/IP, o a través de una WAN, o WWAN, entre otros. Por otro lado, la comunicación (180, 280) entre la máquina del emisor del billete digital (130) o la máquina del receptor del billete digital ( 230) Y la entidad bancaria (160, 260), se realizará, en una implementación preferida sin que sea limitante, mediante la pila de protocolos TCP/IP, pero no está restringido únicamente a éste. En ambos casos, no se limita a que tenga que ser la propia aplicación la que se conecte a la terminal bancaria, ya que también se considera que puedan usarse otras aplicaciones en el mismo dispositivo que conecten independientemente con el terminal bancario, y la aplicación en sí esté indirectamente conectada con el terminal bancario.
La presente invención propone un método para transacciones de billetes digitales el cual se puede desglosar en 3 fases o protocolos diferentes:
•
Emisión del billete digital (Figs. 1 y 4): El usuario recibe un billete digital original de parte de su correcto emisor. El usuario puede utilizarlo para obtener un servicio.
•
Transferencia del billete digital (Figs. 2 y 5): El usuario que ha recibido un billete digital, puede transferirlo a otro usuario para que este otro usuario pueda utilizarlo en su lugar. El nuevo usuario que ha recibido el billete digital transferido, puede retransferir otra vez el billete digital a otro usuario.
•
Utilización del billete digital (Figs. 3 y 6): El usuario que tiene un billete digital, sea original o transferido, puede utilizar dicho billete para obtener el servicio asociado.
Emisión del billete digital:
La Fig. 1 muestra la arquitectura correspondiente a la parte de emisión del billete digital. La Fig. 4 muestra su diagrama de secuencia.
El protocolo de emisión del billete digital consta de varios pasos:
•
En el paso 8101, el usuario realiza una petición al emisor para obtener un billete digital, pudiendo especificar el servicio (y/o los términos y condiciones) que se desea recibir posteriormente.
•
En el paso 8102, el emisor del billete digital genera un primer precontrato donde, en caso de especificar un servicio y/o términos/condiciones, dichos datos queden reflejados. En una implementación preferida, el emisor del billete digital genera un número de serie único, un valor aleatorio, y el servicio y/o términos/condiciones que se desean recibir; estos datos se firman digitalmente con la clave privada que posee el emisor del billete digital. Finalmente, el emisor envía el precontrato al usuario.
•
En el paso 8103, el usuario verifica los datos del precontrato. En una implementación preferida, el usuario verifica la firma electrónica del precontrato.
•
En el paso 8104, en caso que la verificación sea correcta, el usuario crea la aceptación del contrato, que comprende la firma digital o de grupo con el número de serie, servicio asociado (si existe) y el número aleatorio del precontrato, y se envía esta aceptación del contrato al emisor del billete digital. En caso que la verificación no sea correcta, se aborta la operación (8111). La utilización de las firmas de grupo garantiza el anonimato en este paso.
•
En el paso 8105, el emisor del billete digital verifica la aceptación del precontrato. Una implementación preferida, consiste en verificar la firma, ya sea electrónica o convencional, de dicho contrato.
•
En la horquilla 8106, en caso que la verificación de la aceptación del precontrato sea correcta, se genera el billete digital electrónico (8107). En una implementación preferida, el billete digital contiene el número de serie, el servicio asociado, la aceptación del precontrato creada por el usuario, además de otros parámetros opcionales como los términos y condiciones, etc.; este billete digital se firma electrónicamente con la clave privada del emisor y se envía al usuario. En caso de que la verificación no sea correcta, se aborta la operación (8111).
•
En el paso 8108, el usuario verifica el billete digital recibido. En una implementación preferida, se verifica la firma electrónica del billete digital.
•
En la horquilla 8109, en caso de que la verificación sea correcta, se da por concluida la emisión del billete digital de manera satisfactoria (8110); en caso que no sea correcta, se aborta la operación (8111).
Transferencia del billete digital:
La Fig.2 muestra la arquitectura en la parte de transferencia del billete digital. La Fig.5 muestra su diagrama de secuencia.
El protocolo de transferencia del billete digital consta de varios pasos:
•
En el paso 8201, el usuario emisor envía el billete digital que se dispone a transferir. Dicho billete digital da permiso de utilización únicamente al usuario emisor. En una implementación preferida, en la parte de la transmisión del billete digital, también se puede calcular y enviar un compromiso para verificar que es el correcto usuario del billete digital mediante firma digitales o de grupo enlazables (*) (esta verificación se lleva a cabo en el paso 8206 pero puede prepararse en pasos previos para reducir el tiempo de respuesta del protocolo).
•
En el paso 8202, el usuario receptor verifica el billete digital recibido. En una implementación preferida, se verifica la información y su firma digital o de grupo.
•
En el paso 8203, se evalúa si se verifica correctamente o no el billete digital. 8i es correcto, se continúa en el paso 8204; si no es correcto, se aborta la operación de transferencia (8216).
•
En el paso 8204, se verifican las transferencias previas que el billete digital pueda tener. En una implementación preferida, estas verificaciones consisten en verificar las firma digitales o de grupo y que todas las firma digitales o de grupo estén correctamente enlazadas (*). Es decir, existe un billete digital adaptado para cada usuario que ha tenido en propiedad el billete digital, donde se le dan permisos para que pueda utilizarlo, y si desea retransferir el billete digital, puede hacerlo demostrando que es el correcto usuario y firmando con una firma digital o de grupo enlazable con su anterior generada en la obtención del billete digital. También se genera el reto acorde con el compromiso de emisión enviado por el usuario emisor en el paso 8201.
•
En la horquilla 8205, se evalúa si se verifican correctamente o no las firmas digitales o de grupo y si las mismas enlazan correctamente. 8i es correcto, se continúa en el paso 8206; si no es correcto, se aborta la operación de transferencia (8216).
•
En el paso 8207, el usuario emisor demuestra la propiedad del billete digital dando la prueba al usuario receptor. En una implementación preferida, se calcula la respuesta al reto recibido por el usuario receptor (paso 8204) teniendo en cuenta el compromiso enviado en el paso 8201.
•
En la horquilla 8208, se evalúa si se verifica correctamente o no la propiedad del billete digital. 8i es correcto, se continúa en el paso 8209; si no es correcto, se aborta la operación de transferencia (8216).
•
En el paso 8209, el usuario receptor genera la petición de transferencia. En una implementación preferida, ello consiste en la generación de la firma digital o de grupo con el contenido del billete digital que se desea obtener.
•
En el paso 8210, el usuario emisor verifica la petición de transferencia. En una implementación preferida, ello consiste en la verificación de la firma digital o de grupo de la petición de transferencia.
•
En la horquilla 8211, se evalúa si se verifica correctamente o no la petición de transferencia. 8i es correcta, se continúa en el paso 8212; si no es correcta, se aborta la operación de transferencia (8216).
•
En el paso 8212, el usuario emisor genera la aceptación de transferencia, que consiste, en una implementación preferida, en firmar la petición del usuario receptor con una firma digital o de grupo enlazada con la firma que se utilizó para la obtención del billete digital anteriormente.
•
En el paso 8213, el usuario receptor verifica la aceptación de transferencia. Esta aceptación de transferencia incluye entonces el billete digital y los permisos para que el usuario receptor lo pueda utilizar posteriormente. En una implementación preferida, esta verificación incluye la verificación de la firma digital o de grupo, además de comprobar si esta firma coincide con la que utilizó el usuario emisor para obtener el billete digital.
•
En la horquilla 8214, se evalúa si se verifica correctamente o no la aceptación de transferencia. 8i es correcta, se continúa y se llega al estado 8215 de transferencia satisfactoria; si no es correcta, se aborta la operación de transferencia (8216).
Utilización del billete digital:
La Fig. 3 muestra la arquitectura en la parte de utilización del billete digital. La Fig. 6 muestra su diagrama de secuencia.
El protocolo de utilización del billete digital consta de varios pasos:
•
En el paso 8301, el usuario envía el billete digital que se dispone a utilizar.
•
En el paso 8302, el proveedor de servicios verifica el billete digital. En una implementación preferida, ello consiste en verificar la firma digital o de grupo del billete digital.
5 • En la horquilla 8303, se evalúa la verificación del billete digital. 8i es correcta, se continúa en el paso 8304; si no es correcta, se aborta la operación (estado 8310).
• En el paso 8304, se verifican las transferencias previas (si las hay). En una implementación preferida, ello consiste en verificar todas las firma digitales o de grupo de los billetes digitales transferidos, y además verificar que enlazan, para cada usuario, la obtención del billete digital con su
10 posterior transferencia.
•
En la horquilla 8305, se evalúan las verificaciones de las transferencias previas. 8i son correctas, se continúa en el paso 8306; si no son correctas, se aborta la operación (estado 8310).
•
En el paso 8306, se demuestra la propiedad del billete digital. En una implementación preferida, ello consiste en realizar una firma digital o de grupo (que sea enlazable con el billete digital obtenido) de
15 un valor enviado por el proveedor de servicios "al mismo momento". De este modo, el usuario no puede conocer el contenido a firmar y lo debe calcular en ese instante.
• En el paso 8307, se verifica la propiedad del billete digital. En una implementación preferida, ello consiste en verificar la firma digital o de grupo, y también verificar que dicha firma es enlazable con el billete digital que obtuvo el usuario y ha sido presentado.
20 • En la horquilla 8308, se evalúa la verificación de la propiedad del billete digital. 8i es correcta, se llega al estado de utilización satisfactoria 8309 y el usuario puede recibir el servicio; si no es correcta, se aborta la operación (estado 8310).
La utilización explicada contempla el poder tener billetes digitales reutilizables durante un tiempo limitado, o para un número de usos autorizados.
25 Referencias
[BBS04]
D. Boneh, X. Boyen, and H. 8hacham. 8hort group signatures. In M. K. Franklin, editor, CRYPTO, volume 3152 of Lecture Notes in Computer Science, pages 41-55. 8pringer, 2004.
30 D. Boneh and X. Boyen. 8hort signatures without random oracles. In Advances in Cryptology EUROCRYPT 2004, volume 3027 of Lecture Notes in Computer Science, pages 56-73. 8pringer, 2004.

Claims (11)

  1. REIVINDICACIONES
    1.-Método para realizar transacciones con billetes digitales, conteniendo dicho billete digital:
    un identificador enlazado directa o indirectamente a unas condiciones de contrato;
    una prueba de validez creada por el emisor de dicho billete digital, y
    una información relativa al derecho de uso de un usuario que ha adquirido dicho billete digital, estando caracterizado el método por comprender al menos una transmisión de dicho billete digital entre usuarios: usuario propietario UP y usuario receptor UR, con una transferencia segura de dicho derecho de uso, mediante las siguientes etapas:
    a.
    envío por parte de dicho UP de una oferta de transacción relativa a un billete digital;
    b.
    verificación de la prueba de validez de dicho billete digital por parte de dicho UR;
    c.
    generación por dicho UR de una petición de transferencia del billete digital a dicho UP;
    d.
    verificación de dicha petición de transferencia del billete digital por parte de dicho UP y generación por dicho UP de una aceptación de transferencia;
    e.
    verificación por dicho UR de dicha aceptación de transferencia; y
    f.
    transferencia por dicho UP del billete digital adquiriendo dicho UR el citado derecho de uso de dicho UP.
  2. 2.-Método según la reivindicación 1, en donde dicho identificador contiene la fecha de emisión del billete digital y dicha prueba de validez consiste en una firma digital de dicho emisor que garantiza autenticidad, no repudio e integridad de dicho billete digital.
  3. 3.-Método según la reivindicación 1, en donde dicho derecho de uso es una vinculación entre dicho identificador del billete digital y dicho UP realizada mediante una firma digital de dicho UP o un certificado digital de dicho UP.
  4. 4.-Método según la reivindicación 1, en donde dicho derecho de uso es una vinculación entre dicho identificador del billete digital y dicho UP realizada mediante una primera firma digital de grupo que proporciona un anonimato revocable a dicho UP.
  5. 5.-Método según la reivindicación 4, en donde en dicha transmisión se realiza una segunda firma digital de grupo por parte de dicho UP que se enlaza con dicha primera firma digital de grupo proporcionando una garantía acerca de que UP es el que transfiere dicho billete digital preservando su anonimato.
  6. 6.-Método según la reivindicación 2, en donde dicha verificación de dicha prueba de validez consiste en la verificación de dicha firma digital de dicho emisor.
  7. 7.-Método según la reivindicación 3, el cual incluye una etapa adicional consistente en proporcionar por parte de dicho UP una prueba de su derecho de uso del billete digital a dicho UR, que prueba dicha vinculación entre identificador y UP.
  8. 8.-Método según la reivindicación 1, caracterizado porque dicha información relativa al derecho de uso de un usuario que ha adquirido dicho billete digital contiene datos acerca de transferencias anteriores y porque comprende una etapa adicional de verificación de dichas transferencias anteriores por parte de dicho U R.
  9. 9.-Método según la reivindicación 1, caracterizado porque dicho billete digital ha sido obtenido mediante las siguientes etapas:
    g.
    generar un precontrato a partir de una petición de billete digital por parte de dicho UP mediante una firma digital de dicho emisor;
    h.
    verificar dicho precontrato por parte de dicho UP;
    i.
    aceptar dicho precontrato creando una vinculación entre UP y dicho billete digital; y
    j. emitir dicho billete digital mediante una firma digital del emisor. 10.-Método según la reivindicación 9, caracterizado porque la vinculación de la citada etapa i) se realiza mediante una firma digital de UP.
    5 11.-Método según la reivindicación 9, caracterizado porque la vinculación de la citada etapa i) se realiza mediante una firma de grupo de UP. 12.-Método según la reivindicación 9, caracterizado porque la vinculación de la citada etapa i) se realiza
    mediante la inclusión de un certificado digital de UP.
  10. 13.-Método según la reivindicación 11 o 12, caracterizado porque comprende una etapa adicional de verificación 10 de dicha firma digital.
  11. 14.-Método según la reivindicación 2, caracterizado porque dicho billete digital susceptible de ser transferido es
    verificado por un proveedor de servicio mediante las siguientes etapas: k) dicho UR presenta o envía dicho billete digital transferido a dicho proveedor; 1) dicho proveedor verifica dicha prueba de validez mediante la comprobación de la firma digital de
    15 dicho emisor. 15.-Método según la reivindicación 8, caracterizado porque dicho billete digital susceptible de ser transferido es
    verificado por un proveedor de servicio mediante las siguientes etapas: m) dicho UR presenta o envía dicho billete digital transferido a dicho proveedor; n) dicho proveedor verifica dicha prueba de validez mediante la comprobación de la firma digital de
    20 dicho emisor; y o) dicho proveedor verifica dichas transferencias anteriores. 16.-Método según una cualquiera de las reivindicaciones 14 o 15, caracterizado por incluir una etapa adicional consistente en proporcionar dicho UR una prueba de su derecho de uso del billete digital a dicho proveedor, que prueba dicha vinculación entre identificador enlazado a unas condiciones de contrato y URo
    
    
    
    
    
    
    
ES201230268A 2012-02-22 2012-02-22 Método para realizar transacciones con billetes digitales Active ES2425618B1 (es)

Priority Applications (2)

Application Number Priority Date Filing Date Title
ES201230268A ES2425618B1 (es) 2012-02-22 2012-02-22 Método para realizar transacciones con billetes digitales
PCT/ES2013/000045 WO2013124499A1 (es) 2012-02-22 2013-02-22 Método para realizar transacciones con billetes digitales

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES201230268A ES2425618B1 (es) 2012-02-22 2012-02-22 Método para realizar transacciones con billetes digitales

Publications (2)

Publication Number Publication Date
ES2425618A1 true ES2425618A1 (es) 2013-10-16
ES2425618B1 ES2425618B1 (es) 2014-08-05

Family

ID=49255471

Family Applications (1)

Application Number Title Priority Date Filing Date
ES201230268A Active ES2425618B1 (es) 2012-02-22 2012-02-22 Método para realizar transacciones con billetes digitales

Country Status (2)

Country Link
ES (1) ES2425618B1 (es)
WO (1) WO2013124499A1 (es)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013019870B4 (de) 2013-11-28 2019-08-08 Friedrich Kisters Authentifizierungs- und/oder Identifikationsverfahren in einem Kommunikationsnetzwerk

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5557518A (en) * 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
EP1439495B1 (en) * 2003-01-17 2019-04-17 QUALCOMM Incorporated Device for ordering and validating an electronic ticket

Also Published As

Publication number Publication date
ES2425618B1 (es) 2014-08-05
WO2013124499A1 (es) 2013-08-29
WO2013124499A8 (es) 2013-11-07

Similar Documents

Publication Publication Date Title
JP7728059B2 (ja) ブロックチェーンにおけるコンピュータ実行方法、システム及び記憶媒体
US11900368B2 (en) Method and system for zero-knowledge and identity based key management for decentralized applications
US10931461B2 (en) Systems and methods for creating a digital ID record and methods of using thereof
US12014338B2 (en) Device for directly transmitting electronic coin data records to another device, and payment system
ES2875391T3 (es) Expedición de documentos virtuales en una cadena de bloques
US20230093581A1 (en) Method for directly transferring electronic coin data sets between terminals, payment system, currency system and monitoring unit
US20190280861A1 (en) Methods and apparatus for providing attestation of information using a centralized or distributed ledger
TWI497336B (zh) 用於資料安全之裝置及電腦程式
CN109756485A (zh) 电子合同签署方法、装置、计算机设备及存储介质
US9722792B2 (en) Reading of an attribute from an ID token
US11985125B2 (en) Biometrically-enhanced verifiable credentials
CN117769707A (zh) 用于在电子交易系统中传输令牌的方法和交易系统
WO2012014231A4 (en) System and method for generating a strong multi factor personalized server key from a simple user password
US20150170144A1 (en) System and method for signing and authenticating secure transactions through a communications network
US20160226837A1 (en) Server for authenticating smart chip and method thereof
US20220005039A1 (en) Delegation method and delegation request managing method
WO2008132248A1 (es) Método y sistema de notarización de transacciones electrónicas
JP7659760B2 (ja) ブロックチェーン基盤の認証及び取り引きシステム
KR20230020735A (ko) 스마트 컨트랙트 지갑 기반 탈중앙화 신원 키 복구 시스템 및 방법
CN107609878A (zh) 一种共享汽车的安全认证方法及系统
CN112101935A (zh) 区块链充值卡的处理方法和装置
ES2425618A1 (es) Método para realizar transacciones con billetes digitales
JP6515080B2 (ja) 情報処理システム、情報処理方法、及びプログラム
Hong et al. A solution for the offline double-spending issue of digital currencies
CN117057798A (zh) 一种量子安全的数字货币钱包开通方法及其装置

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2425618

Country of ref document: ES

Kind code of ref document: B1

Effective date: 20140805