ES2425618A1 - Method for carrying out transactions with digital banknotes - Google Patents

Abstract

Method for carrying out transactions with digital banknotes. The method is applicable to digital banknotes provided with an identifier, a validity test and an item of information relating to a usage right associated with said digital banknote, comprising the following steps: a. a proprietary user UP sends a transaction offer for the digital banknote b. a receiving user UR verifies the validity test of said digital banknote c. a transfer request from said UR to said UP is generated d. said UP verifies said transfer request and said UP generates a transfer acceptance e. said UR verifies said transfer acceptance and f. the digital banknote is transferred to the UR who acquires the usage right.

Description

  Method for conducting transactions with digital tickets

Technical sector

The present invention concerns in general, a method for transactions with digital / electronic tickets and in particular, a method comprising obtaining and using a digital ticket between users.

The present invention contains parts such as detailed explanations about the protocols used, and in particular the protocol for transferring a digital ticket, subject to protection under Copyright and the inventors reserve the copyright on them.

Background of the invention

The evolution of mobile devices, and especially the increased use of the Internet on these devices, has allowed certain common activities, such as buying, searching for information, or playing, to be carried out remotely. The present invention concerns the purchase of the right to use a service by obtaining and using a digital ticket. For example, and without limiting the need to hire a service as an entry for an event or means of transportation.

The digital ticket is a digital representation of a physical ticket, either a ticket from a means of transport or an access ticket to a given event. Once the purchase or payment is made, the digital ticket exists only as a digital record. The buyer receives on his mobile device the equivalent of the real ticket, and this will be used to guarantee access to the contracted service.

Examples of the use of a digital ticket are found in air transport. In May 2007, Vodafone and Spanair conducted a digital ticket test in Spain. Passengers received a digital boarding pass on their mobile device, this gave the passenger the right to directly access the control area and then the plane.

The lATA (International Air Transport Association) started in 2004 a program to promote the use of digital tickets. An estimate was made that the use of such digital tickets would save the airlines a very significant amount of money.

Another example of the use of digital tickets is in the Czech Republic where AMSBUS allows the reservation of transport via SMS messages.

The Leeds United football team made available to its fans the reservation of tickets for their matches. These followers received an SMS on their mobile devices with the reservation confirmation as well as additional information, such as the reserved seat.

By W02009 / 141614 a method for transactions with digital tickets is known in which an image is displayed on a mobile device to facilitate an inspection. The method comprises receiving specific data from the digital ticket on a mobile device. The data is presented in the form of a code readable by a machine that defines at least a single ticket number and authentication measures. The method also comprises executing an application on the mobile device so as to provide textual and graphic information on the screen of the mobile device to allow authentication of the textual information.

These examples show the introduction of the digital ticket in different services and the increase in the use of mobile devices as a storage unit. One of the key points for its definitive implementation lies in the security they can offer, this is due to the ease of copying the digital information. Digital tickets must offer the same security as that provided by paper tickets.

In a real ticket, usually of paper support, the owner of said ticket can verify its veracity by different means. The ticket can incorporate anti-fraud measures, such as a specific type of paper, use of specific ink, areas with holograms, etc ... On the other hand, in the case of the digital ticket the buyer needs the ticket to contain different characteristics that guarantee Your safety that normally cannot be checked by visual inspection.

The basic features that a digital ticket must offer are the following:

Non-repudiation: the entity that issued the digital ticket cannot deny its authenticity.

Integrity: the digital ticket cannot be modified without such modification being detected.

Anonymity and revocability: the digital ticket is anonymous although, if the user makes improper use,

This user can be identified. The anonymity feature may not be possible, depending on the

service.

5 Reusability: depending on the needs and characteristics of the service the digital ticket can be used once or multiple times. Each service will have one or other requirements.

Validity date: the digital ticket can be valid for a defined period of time.

Online / Offline: digital ticket verification may or may not require a connection to a computer network for validation.

Exculpability: the service provider cannot falsely accuse the user of the digital ticket of not having validated it before using it.

Transferability: the digital ticket can be transferred to other users while retaining all the features mentioned above.

There is a wide range of generic digital security measures that can be used to provide

15 security to a digital ticket system. Depending on the system used the application will vary. An example of such measures would be those based on Smart-cards. These Smart-cards verify each operation, so that the user cannot perform any action not allowed. The security of these systems is based on the security of the Smart-card itself, if this fails, the system is compromised as is the case of "A practical attack on the mifare classic" by Gerhard Koning Gans, Jaap-Henk Hoepman and Flavio D. Garcia, where they compromise the security of Mifare cards. In the scientific literature there are different security measures implemented in Smart-cards, such as, for example, Electronic ticket scheme for its by S. Matsuo and

W. Ogata, Application of electronic ticket to online trading with smartcard technology by W.I. Siu and Z.S. Guo, The secure communication protocol for electronic ticket management system by W.I. Siu and Z.S. Guo

For systems not based on Smart-cards, as is the case with this invention, the use of different

25 cryptographic techniques, which require advanced calculations and, therefore, the use of mobile devices with advanced computing capacity, such as mobile phones, PDAs, etc. These systems can be of two types: 1) Non-anonymous, there are services that anonymity is not an option, in these cases the digital signature is the most common cryptographic technique, an example is K. Oigital-ticket-controlled digital ticket circulation by K. Fujimura, H. Kuno,

M. Terada, K. Matsuyama, Y. Mizuno and J. Sekine. 2) Non-repudiation-anonymity, a common technique to provide anonymity is through the use of pseudonyms, and again, the most common technique is the digital signature, this technique provides the digital ticket with the properties of authenticity, non-repudiation and integrity. Some proposals of interest appear in Ticket based service Access for the mobile user of B. Patel and J. Crowcroft, Motet: Mobile transactions using electronic tickets of D. Ouercia and S. Hailes. In the case of the proposal made by Patel and Crowfort the tickets can be reused; Ouercia and Hailes believes that the

35 reusability depends on the service. Other proposals propose a solution for online / offline ownership, in the case of T.S. Privacy for Public Transportation Heydt-Benjamin, H.J. Chae, B. Defend and K. Fu (online) and Electronic-onboard-ticketing: Software challenges of an state-of-the-art m-commerce application by F. Hanenberg, K. Stenzel and W. Reif.

Some previous inventions have digital ticket systems and / or methods that guarantee some of the above properties but not all at once. The most notable examples are the inventions described in US7809593 Method and system for automatically keeping travel data consistent between passenger reservation records and corresponding electronic tickets from Douck et al. US7907896 Mobile commerce method and de vice de Chitti, US7685020 Mobile commerce receipt system from Do et al. US7520427 Method of operating a ticketing system by Boyd, US2010170947 System and method for electronic ticket verification, identification, and

45 authorization with a wireless communication device by C. Bruce, PCT / IB2005 / 000948 Methods and systems to purchase bookings by A. Rangnekar et al. All these inventions only describe the operability of the method of communication and verification of digital tickets, but do not emphasize the security and privacy issues mentioned above.

A second group, being representative examples CN1987903 Non-contact paper base electronic passenger ticket based on electronic label technology of KK Hu et al., EP1752936 Method of downloading ticketing keys of R. Denis et al., W02005111953 Improved ticketing scheme of HB SIM et al., KR20050057563 Wireless communication from vice providing a contactless interface for a Smart card reader by P. Lau ri, E P2081140 Method and system for protecting a transaction by S. Spitz et al. contemplate only security at the hardware level. These inventions encrypt the communications and storage of the digital ticket to ensure your privacy, regardless of the security and / or privacy of the digital ticket itself. These methods do not guarantee equivalent properties on a real ticket.

The inventions described in US6725376 Method of using an electronic ticket and distributed server computer architecture for the same by S. Levent, US2010005304 Security and ticketing system control and management 5 by M. Hiroshi, W003048892 Access, identity, and ticketing system for providing multiple access SM methods for Smart devices Myra, contemplate the security on the digital ticket providing some features such as anonymity or integrity. Previous inventions use a hash-based cryptography system. An example of the use of hash-based cryptography appears in Method of using an electronic ticket and distributed server computer architecture for the same where the information contained in the digital ticket is used to obtain a hash value. This hash value is encrypted using an authentication server and a private key, and the resulting value is concatenated with the digital ticket information. In this way, the validation of the digital ticket ensures the integrity of said ticket and can be transmitted by unsafe means. This invention does not ensure the anonymity of the digital ticket, only its integrity. The problem with the solution proposed in said invention is that it does not include features such as revocability, exculpability,

15 anonymity, etc.

US 7188358 describes a personalized digital access ticket and preset validity period, which contains anonymous identifications of a sender and a receiver in an e-mail correspondence, as well as a scheme for network communication with a concealment mechanism. .

In US 7630927 an anonymous and secure online payment method is described, and a method based on a partial blind cryptographic signature 20, with revocable anonymity.

Documents US 7630927 and US 2011/0119098 are also considered of interest in the way of constructing the digital ticket or in the proposals relating to the transaction of the tickets.

Brief Description of the Invention

From the foregoing it follows that an alternative to the state of the art is necessary to allow

25 the obtaining and use of a digital ticket offering the basic characteristics that this type of ticket requires, as mentioned above in regard to at least: security, privacy, anonymity, revocability and exculpability, and that makes it possible to be transferred keeping all these properties that are transferred to the new owner.

For this purpose, the present invention concerns a method for carrying out transactions with digital tickets, wherein said digital ticket contains at least:

an identifier linked directly or indirectly to contract conditions;

a proof of validity created by the issuer of said digital ticket, and

information relating to the right of use of a proprietary user (UP) who has acquired said digital ticket.

The said identifier in a first embodiment contains the date of issuance of the digital ticket and said proof of validity contains a digital signature of said issuer that guarantees authenticity, non-repudiation and integrity of said digital ticket.

On the other hand, said right of use comprises at least one link between said digital ticket identifier and said UP made by means of a digital signature of said UP or a digital certificate of said UP.

In an alternative embodiment said right of use comprises a link between said digital ticket identifier and said UP made by means of a first group digital signature that provides a revocable anonymity to said UP.

The information related to the right of use of a receiving user (UR) who has acquired the digital ticket also contains data about previous transfers and includes an additional step of verifying said

45 previous transfers by said URo

On the other hand, said digital ticket according to an embodiment of this invention has been obtained by the following steps:

generate a pre-contract (effective commitment between an issuer and a UP) from a request for digital ticket by said UP through a digital signature of said issuer;

verify said pre-contract by said UP;

accept said pre-contract by creating a link UP digital ticket; Y

issue the digital ticket through a digital signature of the issuer.

The method of the present invention comprises, in accordance with the foregoing, a secure transmission of said digital ticket between users: UP owner user and UR receiving user, with secure transfer of said right of use, and the remaining properties indicated.

The method, in relation to said secure transfer, comprises the following steps:

a) sending by said UP of a transaction offer; to said UR;

b) verification of said proof of validity by said UR (this verification can be carried out by various means);

c) generation of a request to transfer said UR to said UP;

d) verification of said transfer request by said UP (also carried out by various means), and generation by said UP of a transfer acceptance; Y

e) verification by said UR of said transfer acceptance; and f) transfer of the digital ticket acquiring said UR the said right of use of said UP.

The aforementioned verification of said validity test consists of the verification of said digital signature of said UP issuer.

For said transmission, an execution example is provided (in the case of linking between said digital ticket identifier and said UP carried out by means of a digital group signature) to carry out a second digital group signature by said UP that is linked to said first digital group signature providing a guarantee that UP is the one that transfers preserving its anonymity.

The method includes to reinforce the protection strategy an additional stage consisting in providing said UP with proof of its right to use the digital ticket to said UR, which proves said linkage between identifier and UP.

Brief description of the figures

The foregoing and other advantages and features will be more fully understood from the following detailed description of some embodiments with reference to the attached drawings, which should be taken by way of illustration and not limitation, in which:

Fig. 1 shows the architecture used for issuing the digital ticket. The nomenclature used in the figure is as detailed below:

100: user, 105: user-device physical interaction ratio, 110: portable user terminal,

120: application of the user terminal, 125: storage system of the user terminal, 130: transmitter terminal, 140: application of the transmitter terminal, 145: storage system of the transmitter terminal, 150: communication system user terminals- issuer, 160: bank terminal,

170: user-bank terminal communication system, 180: issuer-bank terminal communication system.

Fig. 2 shows the architecture used to transfer the digital ticket. The nomenclature used in the figure is as detailed below:

200: sender user, 201: receiver user, 205: physical interaction relationship sender-device user,

206: physical interaction ratio of receiver-device user, 210: portable terminal of the sending user,

220: application of the sending user terminal, 225: storage system of the sending user terminal, 230: portable terminal of the receiving user, 240: application of the receiving user terminal, 245:

receiver user terminal storage system, 250: sender-receiver user terminal communication system, 260: bank terminal, 270: sender-bank user terminal communication system, 280: receiver-bank user terminal communication system.

Fig. 3 shows the architecture used for the use of the digital ticket. The nomenclature used in the figure is as detailed below:

300: user, 305: user-device physical interaction ratio, 310: user's portable terminal,

320: user terminal application, 325: user terminal storage system, 330: service provider terminal, 340: service provider terminal application; 345: storage system of the service provider terminal, 350: user-provider communication.

Figs. 4, 5, and 6 show sequence diagrams used for the issuance, transfer and use of the digital ticket, respectively.

Detailed exposition of the invention

For user-made signatures in the system, the present invention uses the properties of digital and group signatures. Although there are different proposals in the present invention, the scheme proposed in SDH (Strong Oiffie-Hellman), [88S04] is used. For this reason, the main definitions are presented below. The notation in the part that follows is specific to the explanation of these definitions.

In the scheme [8804]), cyclic (multiplicative) groups GI and G2 of prime order p with their respective gl and g2 generators are considered, in addition to a bilinear application e: GI x G2 - + GTY a hash function H: ( O, l {- + Zp · The public parameters are gl, u, V, hE GI and g2, WE G2 Here w = gl for a secret value VE Zp.

• KeyGenG (n). In this algorithm a parameter n is taken as input, which corresponds to the number of members that will form the group. Select h {!: .. G¡ \ {lGIJ Y '; 1,.; ¿{!: .. Zp', and calculate u, v E GI such that Ut; 1 = .J2 = h. V {!: .. Zp 'is selected and w = gl is calculated. Then, for each user Vi, 1: 5 i: 5 n, an SDH tuple (A ;, Xi) is generated in this way: Xi {!: .. Zp 'is selected and A; <

g / I (V + XI. The private key of the creator of the group (the entity that can discover the identity of the signers) is gmsk = ('; I,'; 2). Each private user key is its tupla gsk [ i] = (A ;, Xi) No entity can know the secret parameter V apart from the creator of the group.

• SignG (M). Given a public group key gpk = (gl, g2, h, U, v, w), a user-specific group private key gsk [iJ = (Ai, Xi) and an input message ME {O, 1 {, a user calculates and generates M = (M, a) where a is the knowledge signature a = (T¡, hhe, Sa, sf3, Sx, Sól, SÓ2). From the user's point of view, he knows his private group key gsk = (A, x) and this is reflected in the following notation.

one.

select a, f3 {!: .. Zp and calculate the linear encryption of A: (T¡, h T3) + - (ua ,, J, Aha + f3) together with the values Ó + -xa and or ~ xf3;

2.

select (a, (f3, (x, ról, (Ó2 {!: .. Zp and calculate the values:

3.

get the challenge:

4. Calculate the values:

Scr-ra + ca

s ~ rx + cx

• VerifyG (M). Given a group public key gpk = (gl, g2, h, u, v, w) and a message signed with the corresponding private key of a member of the group M = (M, a) as input, where M is the message and its signature so that a = (TI, T2, T3, C, Sa, S / 3, Sx, SÓI, SÓ2), any user can verify that a is a valid knowledge signature through the following steps.

? ----

10 1. Check that C ~ H (M, h h h R 1, R 2, R 3, R 4, R 5).

• OpenG (M). This algorithm is used to assign a digital signature to your specific signer of the group in order to know your identity. This operation is only possible for the creator of the group, since it is the only one that knows the gmsk master key, and knows all the pairs (A;, x¡). Given the

15 group public key gpk = (gl, g2, h, u, v, w), the group master private key gmsk = (~ 1, ~ 2), and the signed message M = (M, a) as input, M being the message ya = (TI, h T3, C, Sa, Sf3, Sx, SÓI, SÓ2) the signature, proceed as follows. First, retrieve user A¡ by running A¡ <--- Ty (TP .T / 2). If the group manager has the {Aí} elements of the user's private keys, you can search for the user index corresponding to the A¡ identity retrieved from the signature.

5 Linkage between group signatures

In the system of the invention, all users have to be anonymous, in addition, their signatures cannot be linkable to each other. In some cases, for security, certain signatures of the same user could be linked to each other to ensure that it is the same user.

SignLínkableG procedure

10 A linkable signature procedure called SignLínkableG (M ', M) is defined to be used in the protocol. Given a public key of group gpk, a private user key gsk [í] and a message M ', computes and generates the output M (= (M', a ') that can be linked to the signed message M. To use said procedure correctly, the following protocol is followed:

• First use: sign in a normal way SignG (M):

15 or generate a linear encryption of A: (h h T3) ~ (Ua, .J, Aha + f3) for a, {3 /!: - Zp;

or given a message M, I will sign I message and I will leave at ~ (TI, T2, T3, C, Sa, Sf3, Sx, SÓI, SÓ2) where c ~ H (M, TI, T2, T3, RI R2, R3, R4, R5) E Zp;

• Next uses: SignLínkableG (M ', M}' is equivalent to performing the SignG (M) procedure without performing the

1st step of the generation of (h h T3). In this way, the couple (a, {3) and its result 20 (h h T3) = (ua, II, Aha + f3) are reused and the second step of the SignG (M) procedure is followed.

or use the same pair (a, {3) with the same linear encryption of A as in the first signature: (h h T3) = (Ua, .J, Aha + f3);

or given a message M ', sign the message and generate the output to' ~ (TI, T2, T3, C ', Sa', Sf3 ', Sx', Sól ', SÓ2} where:

It can be shown that different signatures are produced by the same user, since the information (h h T3) is public in the same signature. In addition, the random values (ra ', rf3', rx ', rÓI', rÓ2) must be different than in previous uses, that is: (ra 'f :. ra, {f3' f :. rf3, rx ' f :. rx, {ól 'f :. ról, ró2' f :. rÓ2) so as not to reveal information about the identity of the user. Note also that the values (RI ', R2', R3 ', R4', R5) are established in the 2nd step of the SignG procedure (M), and depend on the random values (ra ', rf3', rx ', rÓI ', RÓ2) generated.

The procedure then is:

one.

reuse (a, {3) that was generated in the SignG (M) procedure as well as the linear encryption of A: (hh T3) = (ua, .J, Aha + f3), and the values l = xa and Ó2 = X {3;

2.

select ra ', rf3 "rx', ról ', ró2 /!: - Zp and calculate the values:

3. get the challenge:

4. Calculate the values:

VerifvLinkableG procedure

The procedure is also defined: VerifyLinkableG (M ', M''y. This algorithm takes as input (M' = (M, a), M (= (M ', a')) with the 2 signatures a = (hh hC, Sa, S / 3, Sx, SÓI, SÓ2) and a '= (TI', T2 ', T3', c ', Sa', S / 3 ', S /, Sól', Só2 '), and generates the 'true' or 'false' output depending on whether the signatures have been produced by the same user pseudonym (hh T3):

Zero-Knowledge Proof of the Group Signature Scheme

In the system both standard group and linkable digital signatures are used, so that the internal information of the message can be verified, as well as verify that some specific signatures are related to the same event / digital ticket and belong to the same user. Despite these advantages, these 15 signatures are generated by the same user, and their verification is done offline or not directly with the verifier. In some situations, there is a need to perform interactive knowledge tests to verify that a certain message belongs to the person who is wanting to verify the signed message / digital ticket: it is equivalent then to say that the user knows the secret parameters (a, { 3, x, ol, Ó2) with which the digital group signature has been generated. The ZKPGCommit protocols are then detailed,

20 ZKPGResponse and ZKPGVerify as follows:

ZKPGCommit procedure (MI

This procedure is performed by the entity that wants to demonstrate knowledge of a certain value. Dadaist

a group public key gpk = (gl, g2, h, u, v, w), a group private key of a particular user gsk [iJ

= (A;, x¡) and a self-signed message M = (M, a) where a is the knowledge signature a = (hT2, hC, Sa, S / 3, Sx, Sól, Só2),

A new commitment information is generated to be actively verified:

m '= {TI, T2, T3, RI', R2 ', R3', R4 ', R5').

one.

the knowledge of (a, f3, x, ol, Ó2), which has been generated for the signature of M, must then be demonstrated, saving the resulting values as the linear encryption of A: (T¡, h T3) = { ua, .J, Aha + f3);

2.

select ra ', rf3', rx ', ról', ró2 f!: - Zp and compute the values:

ZKPGResponse procedure (m ', c')

Given a commitment m '= {T¡, h hRI', R2 ', R3', R /, R5} and a challenge chosen by the verifier, the demonstrator generates a response to the ZKP as follows:

one.

calculate the values:

2.

generate as output the response S '= {Sa', Sf3 ', Sx', SÓI ', SÓ2}.

ZKPG Verifv procedure (m ', c', s')

15 Given a commitment m '= {T¡, h T3, RI', R2 ', R3', R4 ', R5}, a challenge c' chosen by the verifier, and its response S '= {Sa', Sf3 ' , Sx ', Sól', SÓ2} generated by the demonstrator, the verifier continues with these steps:

1. check that:

Linkage between digital signatures

Two conventional digital signatures will be linked if they have been issued by the same issuer that has the private key.

In relation to the aforementioned Figs. 1 to 3, the nomenclature used and a possible implementation are as detailed below:

In a preferred implementation, but which does not limit the invention, the user terminal (110, 210, 230, 310) can be a portable device (eg mobile phone, mobile phone, PDA, Tablet, etc.), the application The user terminal (120, 220, 240, 320) can be an application for the portable device (eg J2ME application, Android, iPhone, etc.) or even a card mode application (eg JavaCard) , using a storage unit (125, 225, 245, 325) (eg Secure Element of the mobile, SD cards, microSD, SIM, UICC, internal device memory, hard drive, database, etc.)

In the part of the ticket issuer, the terminal (130) can be a machine or server that has an application

(140) (with various programming languages, such as Java, C #, C ++, etc.) and with a storage unit (145) (such as database, etc.).

In the service provider, its terminal (330) can be a machine or server that has an application (340) (with different programming languages, such as Java, C #, C ++, etc.) and with a storage unit (345) (such as database, etc.).

The communication between the sender / service provider and user applications (150, 250, 350) can be based on the near-field Near Field Communication (NFC) technology, both in peer-to-peer (IS018092) and in card mode (IS014443, etc.) or Read / Write, but does not exclude other communication modes such as: Internet access, through the TCP / IP protocol stack, WAN (Wide Area Network), or WWAN (Wireless Wide Area Network, which includes 3G, UMTS, HSPA, etc.), RFID or Bluetooth among others.

The bank terminal (160, 260) can also be a network of interrelated banking terminals, communicating the banking entities of both the user and the issuer of the digital ticket. Thus, the communication (170, 270) between the user terminal (110, 210, 230) and the banking entity (160, 260) can be a long-range connection, such as through Internet access, through the TCP / IP protocol stack, or through a WAN, or WWAN, among others. On the other hand, the communication (180, 280) between the machine of the issuer of the digital ticket (130) or the machine of the receiver of the digital ticket (230) and the banking entity (160, 260), will be carried out, in a preferred implementation without being limiting, by means of the TCP / IP protocol stack, but it is not restricted only to it. In both cases, it is not limited to the application itself having to be connected to the bank terminal, since it is also considered that other applications can be used on the same device that independently connect to the bank terminal, and the application in Yes, it is indirectly connected to the bank terminal.

The present invention proposes a method for digital ticket transactions which can be broken down into 3 different phases or protocols:

•

Issuance of the digital ticket (Figs. 1 and 4): The user receives an original digital ticket from his correct issuer. The user can use it to obtain a service.

•

Transfer of the digital ticket (Figs. 2 and 5): The user who has received a digital ticket can transfer it to another user so that this other user can use it instead. The new user who has received the transferred digital ticket, can retransfer the digital ticket to another user.

•

Use of the digital ticket (Figs. 3 and 6): The user who has a digital ticket, whether original or transferred, can use that ticket to obtain the associated service.

Issuance of the digital ticket:

Fig. 1 shows the architecture corresponding to the issuing part of the digital ticket. Fig. 4 shows its sequence diagram.

The digital ticket issuance protocol consists of several steps:

•

In step 8101, the user makes a request to the issuer to obtain a digital ticket, being able to specify the service (and / or the terms and conditions) that one wishes to receive later.

•

In step 8102, the issuer of the digital ticket generates a first pre-contract where, in the case of specifying a service and / or terms / conditions, said data is reflected. In a preferred implementation, the issuer of the digital ticket generates a unique serial number, a random value, and the service and / or terms / conditions to be received; These data are digitally signed with the private key that the issuer of the digital ticket has. Finally, the issuer sends the pre-contract to the user.

•

In step 8103, the user verifies the pre-contract data. In a preferred implementation, the user verifies the electronic signature of the pre-contract.

•

In step 8104, in case the verification is correct, the user creates the acceptance of the contract, which includes the digital or group signature with the serial number, associated service (if it exists) and the random number of the pre-contract, and send this acceptance of the contract to the issuer of the digital ticket. If the verification is not correct, the operation is aborted (8111). The use of group signatures guarantees anonymity in this step.

•

In step 8105, the issuer of the digital ticket verifies acceptance of the pre-contract. A preferred implementation is to verify the signature, whether electronic or conventional, of said contract.

•

In fork 8106, in case the verification of acceptance of the pre-contract is correct, the electronic digital ticket (8107) is generated. In a preferred implementation, the digital ticket contains the serial number, the associated service, the acceptance of the pre-contract created by the user, in addition to other optional parameters such as terms and conditions, etc .; This digital ticket is signed electronically with the issuer's private key and sent to the user. If the verification is not correct, the operation is aborted (8111).

•

In step 8108, the user verifies the digital ticket received. In a preferred implementation, the electronic signature of the digital ticket is verified.

•

In fork 8109, in case the verification is correct, the issuance of the digital ticket is satisfactorily concluded (8110); if it is not correct, the operation is aborted (8111).

Digital ticket transfer:

Fig. 2 shows the architecture in the transfer part of the digital ticket. Fig. 5 shows its sequence diagram.

The digital ticket transfer protocol consists of several steps:

•

In step 8201, the issuing user sends the digital ticket that is to be transferred. Said digital ticket gives permission to use only the issuing user. In a preferred implementation, in the part of the transmission of the digital ticket, a commitment can also be calculated and sent to verify that it is the correct user of the digital ticket by means of digital signatures or linkable group (*) (this verification is carried out in step 8206 but can be prepared in previous steps to reduce the response time of the protocol).

•

In step 8202, the receiving user verifies the digital ticket received. In a preferred implementation, the information and its digital or group signature are verified.

•

In step 8203, it is evaluated whether or not the digital ticket is correctly verified. 8i is correct, continue in step 8204; if it is not correct, the transfer operation (8216) is aborted.

•

In step 8204, the previous transfers that the digital ticket may have are verified. In a preferred implementation, these verifications consist of verifying the digital or group signatures and that all the digital or group signatures are correctly linked (*). That is, there is a digital ticket adapted for each user who has owned the digital ticket, where they are given permission to use it, and if you want to retransfer the digital ticket, you can do so by demonstrating that you are the correct user and signing with a digital signature or group linkable with its previous one generated in obtaining the digital ticket. The challenge is also generated according to the emission commitment sent by the sending user in step 8201.

•

In fork 8205, it is evaluated whether or not digital or group signatures are correctly verified and whether they link correctly. 8i is correct, continue in step 8206; if it is not correct, the transfer operation (8216) is aborted.

•

In step 8207, the issuing user demonstrates ownership of the digital ticket by testing the receiving user. In a preferred implementation, the response to the challenge received by the receiving user (step 8204) is calculated taking into account the commitment sent in step 8201.

•

In fork 8208, it is evaluated whether or not the property of the digital ticket is correctly verified. 8i is correct, continue in step 8209; if it is not correct, the transfer operation (8216) is aborted.

•

In step 8209, the receiving user generates the transfer request. In a preferred implementation, this involves the generation of the digital or group signature with the content of the digital ticket that you want to obtain.

•

In step 8210, the sending user verifies the transfer request. In a preferred implementation, this involves the verification of the digital or group signature of the transfer request.

•

In fork 8211, it is evaluated whether or not the transfer request is verified correctly. 8i is correct, continue in step 8212; if it is not correct, the transfer operation (8216) is aborted.

•

In step 8212, the issuing user generates the transfer acceptance, which consists, in a preferred implementation, of signing the request of the receiving user with a digital or group signature linked to the signature that was used to obtain the digital ticket previously .

•

In step 8213, the receiving user verifies the transfer acceptance. This transfer acceptance then includes the digital ticket and the permissions for the receiving user to use later. In a preferred implementation, this verification includes the verification of the digital or group signature, in addition to checking whether this signature matches the one used by the issuing user to obtain the digital ticket.

•

In fork 8214, it is evaluated whether transfer acceptance is verified correctly or not. 8i is correct, it is continued and the 8215 satisfactory transfer state is reached; if it is not correct, the transfer operation (8216) is aborted.

Use of the digital ticket:

Fig. 3 shows the architecture in the part of use of the digital ticket. Fig. 6 shows its sequence diagram.

The protocol for using the digital ticket consists of several steps:

•

In step 8301, the user sends the digital ticket that he is about to use.

•

In step 8302, the service provider verifies the digital ticket. In a preferred implementation, this involves verifying the digital or group signature of the digital ticket.

5 • On fork 8303, the verification of the digital ticket is evaluated. 8i is correct, continue in step 8304; if it is not correct, the operation is aborted (state 8310).

• In step 8304, previous transfers are verified (if any). In a preferred implementation, this consists of verifying all the digital or group signatures of the transferred digital tickets, and also verifying that they link, for each user, the obtaining of the digital ticket with their

10 subsequent transfer.

•

In fork 8305, the verifications of previous transfers are evaluated. 8i are correct, continue in step 8306; if they are not correct, the operation is aborted (state 8310).

•

In step 8306, ownership of the digital ticket is demonstrated. In a preferred implementation, this involves making a digital or group signature (which is linkable with the digital ticket obtained) of

15 a value sent by the service provider "at the same time". In this way, the user cannot know the content to be signed and must calculate it at that moment.

• In step 8307, the ownership of the digital ticket is verified. In a preferred implementation, this consists of verifying the digital or group signature, and also verifying that said signature is linkable with the digital ticket obtained by the user and has been submitted.

20 • On fork 8308, the verification of ownership of the digital ticket is evaluated. 8i is correct, the satisfactory utilization state 8309 is reached and the user can receive the service; if it is not correct, the operation is aborted (state 8310).

The use explained contemplates being able to have reusable digital tickets for a limited time, or for a number of authorized uses.

25 References

[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.-Method to carry out transactions with digital tickets, containing said digital ticket: an identifier linked directly or indirectly to contract conditions; a proof of validity created by the issuer of said digital ticket, and information relating to the right of use of a user who has acquired said digital ticket, the method characterized by comprising at least one transmission of said digital ticket between users: owner owner UP and user receiving UR, with a secure transfer of said right of use, through the following stages:

to.

sending by said UP of a transaction offer relating to a digital ticket;

b.

verification of the proof of validity of said digital ticket by said UR;

C.

generation by said UR of a request to transfer the digital ticket to said UP;

d.

verification of said request for transfer of the digital ticket by said UP and generation by said UP of a transfer acceptance;

and.

verification by said UR of said transfer acceptance; Y

F.

transfer by said UP of the digital ticket acquiring said UR the said right of use of said UP.

2. Method according to claim 1, wherein said identifier contains the date of issuance of the digital ticket and said proof of validity consists of a digital signature of said issuer that guarantees authenticity, non-repudiation and integrity of said digital ticket. 3. Method according to claim 1, wherein said right of use is a link between said digital ticket identifier and said UP made by means of a digital signature of said UP or a digital certificate of said UP. 4. Method according to claim 1, wherein said right of use is a link between said digital ticket identifier and said UP made by means of a first group digital signature that provides a revocable anonymity to said UP. 5. Method according to claim 4, wherein in said transmission a second group digital signature is made by said UP that links to said first group digital signature providing a guarantee that UP is the one transferring said ticket Digital preserving its anonymity. 6. Method according to claim 2, wherein said verification of said proof of validity consists in the verification of said digital signature of said issuer. 7. Method according to claim 3, which includes an additional step consisting in providing by said UP a proof of its right to use the digital ticket to said UR, which proves said linkage between identifier and UP. Method according to claim 1, characterized in that said information relating to the right of use of a user who has acquired said digital ticket contains data about previous transfers and that it comprises an additional stage of verification of said previous transfers by said U R. 9. Method according to claim 1, characterized in that said digital ticket has been obtained by the following steps:

g.

generate a pre-contract from a request for a digital ticket by said UP through a digital signature of said issuer;

h.

verify said pre-contract by said UP;

i.

accept said pre-contract by creating a link between UP and said digital ticket; Y

j. issue said digital ticket through a digital signature of the issuer. 10. Method according to claim 9, characterized in that the linking of said step i) is performed by a digital signature of UP. 11. Method according to claim 9, characterized in that the linking of said step i) is carried out by means of a UP group signature. 12. Method according to claim 9, characterized in that the linking of said step i) is performed by including a digital UP certificate. 13. Method according to claim 11 or 12, characterized in that it comprises an additional verification step 10 of said digital signature. 14. Method according to claim 2, characterized in that said digital ticket capable of being transferred is verified by a service provider through the following steps: k) said UR presents or sends said digital ticket transferred to said provider; 1) said supplier verifies said proof of validity by checking the digital signature of 15 said issuer. 15.-Method according to claim 8, characterized in that said digital ticket capable of being transferred is verified by a service provider through the following steps: m) said UR presents or sends said digital ticket transferred to said provider; n) said supplier verifies said proof of validity by checking the digital signature of 20 said issuer; and o) said provider verifies said prior transfers. 16. Method according to any one of claims 14 or 15, characterized by including an additional step consisting in providing said UR a proof of its right to use the digital ticket to said provider, which proves said linkage between identifier linked to conditions of contract and URo     







                     