GB2510793A - Method and apparatus for electronic payment authorization - Google Patents

Abstract

A method of electronic payment authorisation comprising an authorization server 102 performing steps of receiving an authorisation request from a sender 100 and/or a receiver 101 for authorisation of a payment transaction, the authorization request comprising a first information, a second information, a third information associated with the sender, a first information associated to the authorization server and a first information associated with the receiver; verifying that the third information associated to the sender and the first information associated to the authorization server are correct, and if the third information associated to the sender and the first information associated to the authorization server are correct: identifying, based on the first information associated with the receiver, a second information associated with the receiver; and transferring the second information associated with the sender to add on to the second information associated with the receiver.

Description

Method and apparatus for electronic payment authorization

Field of the invention

This invention relates to the field of electronic payment system, authentication and authorization, and in particular, to the authentication and authorization of electronic payment transactions.

Background of the invention

Electronic payment authorization method usually requires a full set of personal authorization credentials, (ie. a complete 16-digit credit card number, expiry date and security codes) that are routinely and necessarily required by merchants in order to complete a legitimate transaction. Since all transaction involves the provision of such a complete set of authorization credentials by the consumers, compromising the transactional credential can easily lead to identity theft. Such compromise of authorization credential can occur by many common routes and can usually be conducted without tipping off the card holder, the merchant or the card issuer, at least until the account is ultimately used for fraud. An example of identity theft of personal authorization credentials that are routinely performed during a legitimate transaction is skimming attack. Skimming involves the theft of credit card information used in an otherwise legitimate transactions. The thief can procure a victim's credit card number using basic methods such as photocopying receipts or even more advanced method such as using electronic device to swipe and store victim's credit card numbers for lateral fraudulent activities.

To address fraud committed by identity theft, banks have introduced electronic payment supplementary systems such as the One-Time Password generated using a hardware token. However, the problem is hardly resolved. The single break in point of the system vulnerability lies within the fact that a complete authorization credentials are still routinely and necessarily required to complete a legitimate transaction. A consumer who wishes to make an electronic payment would still need to provide the full set of authorization credential (now including a one-time password) in order to complete a payment transaction. At the point of transaction, this full set of authorization credential is still vulnerable to identity theft.

s In an example of identity theft as illustrated in a relay attack, an attacker can makes use of a fake device to request consumers to reveal all required information, including a valid one-time-password or signature to complete a purchase. Since the fake device processes nothing, but simply makes a copy of the authorization credentials, the attacker could then reuse the authorization credentials to commit illegitimate transactions. The critical point summarizing the prior art authorization method that are continually open to various schematic attacks is due to the fact that a complete set of authorization credentials that are routinely required in a legitimate transaction can be easily leaked on occasions whenever a consumer wishes to complete a transaction.

The purpose of the invention is thus to dynamically thwart identity theft using new authorization system.

Summary of the invention

A method of electronic payment authorization, the method comprises an authorization server performing steps of: receiving an authorization request from a sender and/ar a receiver for authorization of payment transaction, the authorization request comprising a first information, a second information, a third information associated with the sender, a first information associated to the authorization server and a first information associated with the receiver; verifying that the third information associated to the sender and the first information associated to the authorization server are correct, and if the third information associated to the sender and the first information associated to the authorization server are correct: identifying, based on the first information associated with the receiver, a second information associated with the receiver; and transferring the second information associated with the sender to add on to the second information associated with the receiver.

The authorization request comprising of the individual components such as the first information, the second information, the third information associated to the sender, the first information associated to the receiver, and the first information associated to the receiver is encrypted using either a public key or a private key associated to either the sender, receiver or authorization server.

The authorization request may be indicative of signed permission of the sender, directed to an intended receiver and determining if the authorization request is correct comprises determine if the authorization request originated from the sender, to the intended receiver.

The step of verifying the first information associated to the authorization server involves decrypting the first information associated to the authorization server using the authorization server public key.

Before receiving a sender or receiver authorization request, the method comprises: receiving, at the authorization server, from a sender or receiver, a first information associated to the sender, a first information associated to the receiver, and a second information associated to the sender; generating, at the authorization server, a third information associated to the sender, and a first information associated to the authorization server wherein the first information associated to the authorization server is extracted from the hash information digest comprising of the first, second, third information associated to the sender and the first information associated to the receiver; encrypting, at the authorization server, the first information associated to the authorization server using the authorization server private key unknown to the sender and receiver.

The first information associated to the sender may indicates a location in the memory address at which the third information is generated from a first content attribute associated with the sender using seed algorithm.

is Prior to receiving the authorization request from the sender or receiver, the method may comprises the authorization server: receiving a request from the sender for generating a third information associated to the sender; generating the third information associated to the sender using a seed algorithm; and transmitting the generated third information associated to the sender to the sender.

Generating the third information associated to the sender may comprises using a seed algorithm comprising of steps of: identifying an attribute associated with the sender; applying a predetermined number of hash functions to the identified attribute; determining a list of potential keys comprising the output of the hash functions; selecting one of the listed potential keys as the third information associated to the sender; and transmitting the third information associated to the sender to the sender.

The third information associated to the sender may be time-varying.

Verifying whether the received authorization request is correct may comprise an authorization server performing steps of: determining, based on received first information associated to the sender, a first content attribute associated to the sender; computing, based on the first content attribute associated to the sender, a second content attribute associated to the sender; computing, based on the first, second, third information associated to the sender, and the first information associated to the receiver, a first content attribute associated to authorization server; decrypting, based on the received first information associated to the authorization server, the first information associated to the authorization server, using authorization server public key; and determining, if the computed second content attribute associated to the sender is determined to be equal to the received third information associated to the sender, and the computed first content attribute associated to the authorization server is also determined to be equal to the decrypted first information associated to the authorization server, verifying that the is received authorization request is correct.

The authorization request may comprises: a first information associated to the sender, encrypted using receiver public key; a second information associated to the sender, encrypted using sender private key; a third information associated to the sender, encrypted using receiver public key; a first information associated to the receiver, encrypted using sender private key; a first information associated to the authorization server, encrypted using authorization server private key.

The authorization request may also contain one or more components non-encrypted.

The authorization request may also contain one or more components that are encrypted using a combination of the sender's, receiver's, authorization server's public and private keys.

A server for authorizing transactions, wherein the server may be configured to: receive an authorization request from a sender and/or a receiver for authorization of payment transaction, the authorization request comprising a first information, a second information, a third information associated with the sender, a first information associated to the authorization server and a first information associated with the receiver; verify that the third information associated to the sender and the first information associated to the authorization server are correct, and if the third information associated to the sender and the first information associated to the authorization server are correct: identify, based on the first information associated with the receiver, a second information associated with the receiver; and transfer the second information associated with the sender to add on to the second information associated with the receiver.

The server may be further configured to carry out a method according to any one of the method above.

is A user device for generating authorization request, wherein the device is configured to: send, to an authorization server, a request for authorization of payment, the request comprising of a first, second information associated to the user device, and a first information associated to receiver's user device; receive, from an authorization server, a third information associated to the user device, and a first information associated to the authorization server; encrypt the authorization request by components; and decrypt the authorization request by components; The device may be further configured to: connect to the authorization server for exchange of authorization information; and communicate with other user device for exchange of authorization information.

The device may further configured to store an authorization request, public keys associated to the sender, receiver and authorization server, and the device's corresponding private key.

A computer program comprising instructions which, when executed, may cause a processor to carry out a method according to any of the methods above.

An authorization system comprising: a server according to any method as described s above; and a user device according to any method as described above.

It will be appreciated that this invention changes the core fundamental approach for authorization. Instead of requiring a full set of authorization credential from the sender, the authorization credential requires the method on a joint authorization credentials derived from both the sender and receiver's authorization credentials to process a legitimate transaction.

The dual signature authorization ensures that each transactional authorization credential is unique, and hence not a fixed set of authorization credential that could be reused for multiple transactions. It places the receiver as the filter before processing a legitimate transaction. Only the intended receiver could filtrate a valid authorization credential to satisfy a valid transaction.

In this way, the invention ensures that the authorization credential of a sender, at the best of his/her knowledge, is necessarily incomplete without a valid receiver's joint authorization credential to construct a legitimate transaction. That authorization credential as a result of the dual signature authorization method prevents identity theft, because sender's authorization credential are necessarily incomplete, hence unable to satisfy any valid transaction.

List of Figures Figure 1 is a system in accordance with an embodiment of the invention.

Figure 2 depicts a method of registering and assigning user certificate to an user by an authorization server in accordance with an embodiment of the invention.

Figure 3 depicts a method of generating personal authorization credentials and exchange of the credentials between users in accordance with an embodiment of the invention.

Figure 4 depicts a method of generating a dynamic dual signature transfer function using users' shared secrets in accordance with an embodiment of the invention.

Figure 5 depicts a method of validating the dynamic dual signature transfer function is in accordance with an embodiment of the invention.

Detailed Description

In this invention, electronic authorization credentials will be made dynamically secured in a way that complete personal authorization credential is enough to provide only half of a valid authorization credential. Authorization credential is made to vary from transaction to transactions, hence rendered invalid for multiple transactions. Authorization credential is also made to vary from recipient to recipient, leaving no opportunity for illegitimate transfer of payment to unintended recipient.

It would be appreciated that authorization credentials provided by the consumer, at the best of his/her knowledge, is by itself necessarily incomplete, then a fraudulent transaction cannot be satisfied since no useful information could be derived out of the incomplete authorization credential. Comparing to the prior arts, if consumers were, otherwise to provide all authorization information that helshe knows to the best of his/her knowledge (ie. 16 digital credit card number, security codes and the One-Time-Password), an attacker would have, otherwise, the necessary information to complete a fraudulent transaction.

A dual signature authorization method will be described in detail, using a combination of transactional credential derived from joint sender and receiver authorization credentials. The authorization credential can only be exhausted at that particular relationship-based transaction, preventing abuse of authorization credentials for illegitimate transactions.

The invention will now be described in detail with reference to the figures in the Drawings.

Figure 1 depicts an authorization system according to an embodiment of the invention. The system comprises an user device 100, and another user device 101, both the user device 100 and user device 101 could be mobile phone, mobile device, computers, or other devices capable of communicating information through a network etc. The user device 100 is associated to a consumer/user or entity wishing to send an electronic payment to the user device 101, which is, on the other hand, associated to a consumer/user or entity wishing to receive the electronic payment.

The user device 100 and the user device 101 are in communication with a database server 102 and based on the information stored in the database server 102, verifies whether the payment transaction originates from an indicated sender associated to user device 100 to an intended receiver associated to user device 101 and, if so, the database server 102 provides a complementary transactional information associated to the user device 100 that is necessary to complete the transaction between user device 100 and user device 101.

An user device 100 and user device 101 wishing to use the system to authorize transaction (payment, digital points, rewards, products or any other digital data values) first register with the database server 102.

is As depicted in figure 2, a method of registering and assigning user certificate to an user with the database server 102 in accordance with an embodiment of the invention is provided. At step 200, user registration process begins at which the user input personal information into the user device 100 or user device 101, or any other communicating device (computer, mobile device etc) which are in communication with the database server 102. The database server 102, upon receiving the required registration information from the user, initiates a generation of user certificate that is associated to an unique cryptographic key pairs, a public key and a private key for the user. The generation of the user certificate may use asymmetric cryptographic algorithm such as RSA (Rivest, Shamir, Adleman) algorithm or otherwise, and the generation of the user certificate may either be done on database server 102 or on the user device.

In a preferred embodiment, the generation of the user certificate in step 201 is generated on the user device, and bind to the user information provided during the registration process at step 200, and may also be bind to a UDID (unique device identification number) associated to the user device. The user certificate generated at step 201 may then be code signed by the database server 102 to preserve the integrity of the user certificate from tampering by attackers. In an alternative embodiment of the invention, the user device 100 or user device 101 can generate a certificate signing request and transmit the authorization server 102. A code signed user certificate is then issued to the user upon a valid code signing by the authorization server 102.

At step 202, the public key of the generated user certificate in step 201 is stored in database server 102 together with the user registered information provided in step 200. An unique identification number may also be assigned to the user and stored into the database server 102 for referencing. On the other hand, the private key of the generated user certificate in step 201 may be stored into the user device. A backup copy of the private key generated in step 201 may also be stored in the database server 102.

is At step 203, the database server 102 generates one or more security credentials and injected these security credentials in association with the user registered information in step 200. In a preferred embodiment of the invention, the security credentials associated to the user is being generated by the database server 102 that includes a "Shared-secret-key", and an "authorization-key". The "Shared-secret-key", and the "authorization-key" are generated values based on seed algorithm. The seed algorithm contains a numerical seed, with value 5, and a computational limit, with value K. Each time an user requests for a valid shared-secret-key or an valid authorization-key, the database server 102 computes a list of consecutive hash on value S, up to K times. Then in response to the user request for the shared-secret-key or the authorization-key, the hash function generated at the Kth position of the consecutive hash is provided to the user. Whenever the key is successfully exhausted, the computational limit K is then reset to (K-i), which means that, in response to the next successful key request for a shared-secret-key or an authorization-key, the next computational limit of K would be (K-i).

Figure 3 depicts a method of generating user authorization credentials and exchange of the credentials between users (sender and receiver) in accordance with an embodiment of the invention. At step 300, an user associated with the user device wishes to be involved in a transaction with another user associated with the user device 101, both users initiate a connection with each other, and the communication connection may also include the communication with the database server 102. The established communications between the user device 100, user device 101 and the database server 102 may be connected through internet, Wifi, wireless communication, wired communication, Bluetooth or other forms of communication methods etc. Optionally, at step 301, the connected user device 100 and user device 101 each requests a valid shared-secret-key from the database server 102. The shared-secret-key retrieves the Kth position in the consecutively generated K times of hash functions based on the seed value, S. The shared-secret-key is then transmitted securely to the associated user and stored into the user device 100 and user device 101.

At Step 302, user device 100 and user device 101 exchanges information that was stored in their own devices, namely, the unique identification number assigned to the user in step 202, the public key associated to the user as stored in the user device in step 202, and the generated shared-secret-key in step 301. The exchange of information then allows both the sender, which is associated to the user device 100 and the receiver, which is associated to the user device 101, to have two complete sets of authorization credential involving both the sender and the receiver.

Figure 4 depicts a method of generating a dual signature transfer function in accordance with an embodiment of the invention. At step 400, user device 100, which is associated to a sender, may input an amount or data value for transfer. In an alternative embodiment of the invention, the user device 101, which is associated to a receiver, may input an amount or data value for transfer, and sends the authorization request to the sender. The authorization request may comprise a receiver's unique identification number, a public key associated to the receiver, the data value for transfer, an unique identification number associated to the sender, and/or a public key associated to the sender.

At step 401, the user device 100 which is in communication with the database server s 102, requests for a valid authorization-key using the seed algorithm that is similar to step 301. The authorization-key is transmitted to the user device 100 via secured communication channel.

At step 402, user device 100 transmits the transactional information to authorization server 102, the transactional information include an unique identification number associated to the sender, an unique identification number associated to the receiver, the data for transfer, and the authorization-key. The authorization server 102, then generates an authentication check sum on the transactional information using hash function, and encrypt the authentication check sum using the authorization server 102 private key. In an alternative embodiment, the generation of the authentication check-sum in step 402 may also include any other added data, strings, characters, numbers, symbols etc in the hash function to create more robust authentication check-sum; a copy of the included data, strings, characters, numbers, symbols etc or the resultant authentication check-sum may also be stored into the database server 102. After computing the encryption of the authentication check sum using authorization server 102 private key, the authorization server 102 transmits the encrypted authentication check-sum to user device 100.

At step 403, the user device 100, which is associated to the sender then proceeds to generate a transfer function that may consists of the following components, a sender unique identification number, a receiver unique identification number, the data for transfer as input in step 400, the authorization-key as generated in step 401, and the authentication check-sum as generated in step 402. Note that the sender unique identification number and receiver unique identification number are first information associated to the sender and receiver respectively, and may be represented by any characters, strings, numbers, symbols that is indicative of a specific sender or receiver.

At step 404, the encryption of the components in the transfer function generated in step 403 is performed in the following manner: the sender unique identification number is to be encrypted using the receiver's public key associated to user device s 101, the receiver unique identification number is to be encrypted using the sender's private key associated to user device 100; the data for transfer is to be encrypted using the sender private key associated to user device 100; the authorization-key is to be encrypted using the receiver's public key associated to user device 101; the authentication check-sum was already encrypted using the database server 102 private key, hence may be presented in plain text. In an alternative embodiment of the invention, the components of the transfer function generated in step 403 may also be encrypted using various combinations of sender and/or receiver public and private keys. Alternatively, one or more components of the transfer function may also be in plain text (ie. without any encryption).

Optionally, at step 405, an encryption that involves the "Shared-Secret-Key" that was generated in step 301 may be applied to the encrypted transfer function generated in step 404 using DES (Data Encryption Standard) algorithm. In this manner, only either the sender, which is associated to the user device 100 or the receiver, which is associated to the user device 101 could decrypt the encrypted transfer function. In an alternative embodiment of the invention, the encryption of the generated transfer function may be done using other encryption algorithm that involves both the sender's and receiver's generated "Shared-Secret-Key".

Figure 5 depicts a method of validating the dual signature transfer function in accordance with an embodiment of the invention. At step 500, the sender, who is associated to the user device 100, may transmit the encrypted transfer function to the intended receiver through any medium such as SMS, messages, plain text, email, in-app data transfer, Barcodes, or any other medium capable of storing data.

The receiver, who is associated with the user device 101, is then able to decrypt the encrypted transfer function (dual signature transfer function) systematically.

At step 501, if the dual signature transfer function had been encrypted using the shared-secret-keys as in step 405, the receiver, who is associated to the user device 101, decrypts the information using the combined shared-secret-keys that was exchanged in step 302 to recover the dual signature transfer function. The receiver, who is associated to the user device 101, then decrypt the dual signature transfer function by components using the corresponding decryption method. In response to the preferred embodiment of encryption method as described in step 404, the receiver, who is associated with the user device 101 decrypts the dual signature transfer function in the following manner: decrypt the sender unique identification number using the receiver's private key, decrypt the receiver unique identification number using sender's public key; decrypt the data for transfer using the sender public key; decrypt the authorization-key using the receiver's private key; the authentication check-sum was previously encrypted using database server 102's private key in step 404, and hence non-decrypt-able using either user device 101 or is user device 100 public or private keys.

At step 502, user device 101 transmits the partially decrypted dual signature transfer function to the database server 102 via a secured communication channel for authorization. The database server 102 locates, based on the sender unique identification number component of the dual signature transfer function, the user information associated to the user device 100, and retrieves the Seed, S associated to the authorization-key, and the computational limit, K associated to the authorization-key, compute using hash function on value S consecutively up to K times, and determine a possible match with any of the generated hash function in the list to the received authorization-key component in the dual signature transfer function. If the authorization-key matches any of the generated hash function on the Xth position of the list containing K possible keys, the authorization server 102 resets the computation limit, K, associated to the authorization key, to (X-1). The database server 102 continues to validate for a valid authentication check-sum by first recomputing a hash function check-sum of the dual signature transfer function components, which comprises the unique identification associated to the sender, the unique identification associated to the receiver, the data for transfer, and the authorization-key, and secondly, decrypts the authentication check-sum component in the dual signature transfer function using authorization server 102 public key.

Determining both the recomputed authentication check-sum matches the decrypted authentication check-sum, and if the authentication check-sum is correct, database server 102 resets the computational limit, K associated to the shared-secret-key of sender user device 100 to K-i.

At step 503, the database server 102 then authorize the data for transfer component in the dual signature transfer function to be deducted from user database associated to the sender user device 100 and added onto the user database associated to the receiver user device 101. In a preferred embodiment of the invention, the database server 102 locates, based on the receiver unique identification number component of the dual signature transfer function which points to a database address associated to the receiver database information of user device 101. The database server 102 then deposits the data for transfer from the dual signature transfer function component into the database information associated to receiver user device 101. Upon a successful transfer of the data, the database server 102 resets the computational limit, K, associated to the shared-secret-key of user device 101 to K-I.

Whilst the in invention has been described with respect to performing a sequence of steps, it will be appreciated that the order in which the steps are carried out may be varied or reversed, and that individual steps may be omitted or modified using different array of cryptographic methods, or plain text to achieve the same objective.

Claims (22)

1. Claims 1. A method of electronic payment authorization, the method comprises an authorization server performing steps of: receiving an authorization request from a sender and/or a receiver for authorization of payment transaction, the authorization request comprising a first information, a second information, a third information associated with the sender, a first information associated to the authorization server and a first information associated with the receiver; verifying that the third information associated to the sender and the first information associated to the authorization server are correct, and if the third information associated to the sender and the first information associated to the authorization server are correct: identifying, based on the first information associated with the receiver, a second information associated with the receiver; and transferring the second information associated with the sender to add on to the second information associated with the receiver.
2. 2. The method of claim 1, wherein the authorization request comprising of the individual components such as the first information, the second information, the third information associated to the sender, the first information associated to the receiver, and the first information associated to the receiver is encrypted using either a public key or a private key associated to either the sender, receiver or authorization server.
3. 3. The method of claim 1 or claim 2, wherein the authorization request is indicative of signed permission of the sender, directed to an intended receiver and determining if the authorization request is correct comprises determine if the authorization request originated from the sender to the intended receiver.
4. 4. The method of any of the preceding claims, wherein the step of verifying the first information associated to the authorization server involves decrypting the first information associated to the authorization server using the authorization server public key.
5. 5. The method of any preceding claims, before receiving a sender or receiver s authorization request, the method comprises: receiving, at the authorization server, from a sender or receiver, a first information associated to the sender, a first information associated to the receiver, and a second information associated to the sender; generating, at the authorization server, a third information associated to the sender, and a first information associated to the authorization server wherein the first information associated to the authorization server is extracted from the hash information digest comprising of the first, second, third information associated to the sender and the first information associated to the receiver; encrypting, at the authorization server, the first information associated to the authorization server using the authorization server private key unknown to the sender and receiver.
6. 6. The method of claim 5, wherein the first information associated to the sender indicates a location in the memory address at which the third information is generated from a first content attribute associated with the sender using seed algorithm.
7. 7. The method of claim 6, wherein, prior to receiving the authorization request from the sender or receiver, the method comprises the authorization server: receiving a request from the sender for generating a third information associated to the sender; generating the third information associated to the sender using a seed algorithm; and transmitting the generated third intormation associated to the sender to the sender.
8. 8. The method of claim 7, wherein generating the third information associated to the sender using a seed algorithm comprises: identifying an attribute associated with the sender; applying a predetermined number of hash functions to the identified attribute; determining a list of potential keys comprising the output of the hash functions; selecting one of the listed potential keys as the third information associated to the sender; and transmitting the third information associated to the sender to the sender.
9. 9. The method of claims 1 to 8, wherein the third information associated to the sender is time-varying.is
10. 10. A method of verifying whether the received authorization request is correct, the method comprising an authorization server performing steps of: determining, based on received first information associated to the sender, a first content attribute associated to the sender; computing, based on the first content attribute associated to the sender, a second content attribute associated to the sender; computing, based on the first, second, third information associated to the sender, and the first information associated to the receiver, a first content attribute associated to authorization server; decrypting, based on the received first information associated to the authorization server, the first information associated to the authorization server, using authorization server public key; and determining, if the computed second content attribute associated to the sender is determined to be equal to the received third information associated to the sender, and the computed first content attribute associated to the authorization server is also determined to be equal to the decrypted first information associated to the authorization server, verifying that the received authorization request is correct.
11. 11. The method of any of claims of 1 to 10, wherein the authorization request s comprises: a first information associated to the sender, encrypted using receiver public key; a second information associated to the sender, encrypted using sender private key; a third information associated to the sender, encrypted using receiver public key; a first information associated to the receiver, encrypted using sender private key; a first information associated to the authorization server, encrypted using authorization server private key.
12. 12. The method of claim 11, wherein one or more of the authorization request components are non-encrypted.
13. 13. The method of claim 11 and 12, wherein one or more of the authorization request components are encrypted using a combination of the sender's, receiver's, authorization server's public and private keys.
14. 14. A server for authorizing transactions, wherein the server is configured to: receive an authorization request from a sender andlor a receiver for authorization ot payment transaction, the authorization request comprising a first information, a second information, a third information associated with the sender, a first information associated to the authorization server and a first information associated with the receiver; verify that the third information associated to the sender and the first information associated to the authorization server are correct, and if the third information associated to the sender and the first information associated to the authorization server are correct: identify, based on the first information associated with the receiver, a second information associated with the receiver; and transfer the second information associated with the sender to add on to the second information associated with the receiver.
15. 15. The server of claim 14, wherein the server is further configured to carry out a method according to any one of claims 3 to 13.
16. 16. A user device for generating authorization request, wherein the device is configured to: send, to an authorization server, a request for authorization of payment, the request comprising of a first, second information associated to the user device, and a first information associated to receiver's user device; receive, from an authorization server, a third information associated to the user device, and a first information associated to the authorization server; encrypt the authorization request by components; and decrypt the authorization request by components;
17. 17. The device of claim 16, wherein the device is further configured to: connect to the authorization server for exchange of authorization information; and communicate with other user device for exchange of authorization information.
18. 18. The device of claim 16 and 17, wherein the device is further configured to store an authorization request, public keys associated to the sender, receiver and authorization server, and the device's corresponding private key.s
19. 19. A computer program comprising instructions which, when executed, cause a processor to carry out a method according to any of claim 1 to 13.
20. 20. An authorization system comprising: a server according to claim 14 or claim 15; and a user device according to any one of the claims 16 to 18.
21. 21. A system substantially as hereinbefore described with reference to any of figures ito 5.is
22. 22. A method substantially as hereinbefore described with reference to any of the figure ito 5.