A SYSTEM AND METHOD FOR EFFECTING A TRANSACTION USING A MOBILE COMMUNICATIONS DEVICE ASSOCIATED WITH A RECEIVER OF TRANSACTION INFORMATION
BACKGROUND OF THE INVENTION
The present application relates to a system and method for effecting a transaction using a mobile communications device associated with a receiver of transaction information.
The transaction could be an on-line payment transaction but could also be any other type of suitable transaction to which the method may be applied.
SUMMARY OF THE INVENTION
According to a first example embodiment there is provided a method for effecting a transaction using a mobile communications device associated with a user who is a receiver of transaction information, the method comprising: receiving a data set on the mobile communications device, the data set containing at least metadata, transaction information, a transaction public key and a digital signature; verifying that the transaction public key has not expired; if the transaction public key has not expired, verifying the authenticity and integrity of the transaction information by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key;
if the digital signature is valid, verifying that the received transaction information is uniquely associated with a sender of the transaction information and the receiver of the transaction information by verifying a transaction association value, wherein the transaction association value is verified by: obtaining identification information of the sender from the transaction public key; obtaining identification information of the receiver from the received transaction information; calculating a transaction association value by hashing the identification information of the sender and receiver to obtain a transaction association value; retrieving from a memory of the mobile communications device a list of previously stored approved transaction association values; comparing the calculated transaction association value with the values stored in the list; and if the calculated transaction association value is found within the list then verifying the transaction association value; if the transaction association value is verified then displaying the transaction information to the receiver via a display of the mobile communications device; receiving a user input to approve the transaction; and in response to receiving an approval user input, transmitting the transaction information from the mobile communications device to a payment system to effect the transaction.
According to a second example embodiment there is provided a mobile communications device for effecting a transaction, the mobile communications device associated with a user who is a receiver of transaction information and comprising: a communications module for receiving a data set on the mobile communications device, the data set containing at least metadata, transaction information, a transaction public key and a digital signature; a processor for: verifying that the transaction public key has not expired; if the transaction public key has not expired, verifying the authenticity and integrity of the transaction information by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key; if the digital signature is valid, verifying that the received transaction information is uniquely associated with a sender of the transaction information and the receiver of the transaction information by verifying a transaction association value, wherein the transaction association value is verified by: obtaining identification information of the sender from the transaction public key; obtaining identification information of the receiver from the received transaction information;
calculating a transaction association value by hashing the identification information of the sender and receiver to obtain a transaction association value; retrieving from a memory of the mobile communications device a list of previously stored approved transaction association values; comparing the calculated transaction association value with the values stored in the list; and if the calculated transaction association value is found within the list then verifying the transaction association value; a display for displaying the transaction information to the receiver if the transaction association value is verified; a user interface for receiving a user input to approve the transaction; wherein in response to receiving an approval user input, the processor transmits the transaction information from the mobile communications device via the communications module to a payment system to effect the transaction.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a block diagram illustrating a system for effecting a transaction using a mobile communications device associated with a receiver of transaction information;
Figure 2 is a block diagram illustrating the server of Figure 1 in more
detail;
Figure 3 is a block diagram illustrating in more detail the system for effecting a transaction using a mobile communications device associated with a receiver of transaction information ;
Figure 4 is a block diagram illustrating one example implementation of the present invention;
Figure 5 is a block diagram illustrating another example implementation of the present invention;
Figures 6a show example messages displayed to a user of a mobile and 6b communications device;
Figure 7 is a block diagram illustrating another example implementation of the present invention; and
Figure 8 is a block diagram illustrating another example implementation of the present invention.
DESCRIPTION OF EMBODIMENTS
Referring to the accompanying drawings, a system for effecting a transaction using a mobile communications device associated with a receiver of transaction information is illustrated.
The transaction is typically conducted between two users with one user composing and sending transaction information and the other user receiving and reviewing the transaction information before initiating the transaction at a system operated by a banking or non-banking institution.
Referring to Figure 1 , the figure shows a central transaction server 10 that can be accessed via one or more communications networks 12.
The communications networks 12 will include the Internet as well as mobile communication networks depending on the specific implementation.
The server 10 has a non-transitory data-storage device in the form of database 14.
A plurality of users access the server 10 using computers 16 and/or mobile communications devices 18.
It will be appreciated that the computers 16 could be one or more of laptop computers, desktop computers, tablet computers, Point of Sale (POS) device, mainframe computer, or any other suitable computing device.
The mobile communications devices 18 could be mobile telephones, mobile tablet devices or any other suitable computing device with communication ability, preferably access to a GSM network.
It will also be appreciated that whilst only some users are illustrated, in a real world implementation there will be a large number of users.
As will be described in more detail below, some of the users that access the central transaction server 10 will be transaction information senders and some of the users will be transaction information receivers.
In any event, referring to Figure 2, the server 10 includes a processor 20 which is operably coupled to the other illustrated components and controls the operation of the server.
A communications module 22 allows the server to communicate via communications networks 12 with the computers 16 and mobile communications devices 18.
The first step in the process is to obtain the relevant transaction information.
This is obtained from a sender of transaction information using one of the computers 16 or mobile communications devices 18 to send the transaction information to the central server 10.
For purposes of illustration, the transaction will now be described as a payment. However, the transaction could be any other suitable transaction.
In this illustrated example, the sender of the transaction information will be a merchant requiring payment for goods or services and the central server will be a server of a financial institution such as a bank.
The sender will author transaction information to be authenticated. This will include at least some of the identity of the sender, an identity of the transaction information receiver, an identification of the goods and/or services for which payment is being made and an amount to be paid.
For payment requests, it is a feature of the invention to further securely include bank account information as part of the transaction information to facilitate payment by way of a bank credit transfer. It should however be appreciated that the invention is not limited to this form of electronic payment.
The sender will now use their computer 16 or mobile communication device 18 to request a digital signature over at least the transaction information, from a signature generation service 24 which may be located at a trusted authority.
In the illustrated embodiment of Figure 2, a signature generation service 24 forms part of the central server 10.
Alternatively or in addition, as illustrated in Figure 3, the signature generation service 24 sits outside of the central server 10.
Thus the signature generation service 24 will receive a signature request from the transaction information sender.
Referring to Figure 3, the signature generation service 24 may either be implemented as an online service, dedicated software service or a dedicated server which may consist of suitable computing equipment that contains a processor 26 (and circuitry) to execute processor instructions associated with a signature generation software program 28.
The signature generation service 24 may in turn be connected, through a short-lived or persistent secure network connection to one or more transaction information senders enrolled with the signature generation service 24.
A database 30 is used for storing credentials uniquely associated with each transaction information sender. The signature generation service 24 may store, within secure storage 32, one or more key pairs consisting of a transaction private key 34 and transaction public key 36, generated by and received from a key generation server 38 which will be described in more details below.
The secure storage 32 may form part of the database 30 or may be separate therefrom as illustrated.
A key generation server 38 is typically associated with a trusted authority generally responsible for key generation and an example of a key generation server 38 is illustrated in Figure 3.
It will be appreciated that there could be more than one key generation server 38, for instance each bank my act as a trusted authority with their own distinct key generation server 38.
ln any event, the key generation server 38 consists of suitable computing equipment that contains a processor (and circuitry) 40 to execute processor instructions associated with a key generation software program 42.
The key generation server 38 may be connected, through a secure network connection to one or more signature generation services 24 enrolled with the key generation server 38.
A database 44 is used for storing credentials uniquely associated with each enrolled signature generation service 24. The key generation software program 42 has an initial once-off setup phase, when executing for the first time, during which a master public key 46 and master private key 48 are generated using known cryptographic system parameters associated with an Identity-Based Signature scheme.
The master public key 46 and master private key 48 are subsequently stored within a secure storage area 50, offering tamper resistance for active protection of secrets.
Henceforth, the key generation software 42 generates a transaction private key 34 in response to receiving a request from a uniquely identified signature generation service 24.
The transaction private key 34 is generated using the master private key 48 in conjunction with at least a user ID and usage period received as part of the request.
The user ID consists of a string unambiguously representing a user, for example a website URL, while the usage period represents a period of time for which the transaction private key should be valid.
A corresponding transaction public key 36 is formed by combining at least the user ID and usage period. The key generation server 38 returns the
transaction private key 34 and public key 36 to the signature generation service through a secure connection 12.
The signature generation software program 28 uses the transaction private key 34 to generate a digital signature on the transaction information received as part of a signature request from a uniquely identified transaction information sender.
The digital signature is computed using an Identity- Based Signature (IBS) scheme associated with known cryptographic system parameters and which relies on, for example, bilinear mappings.
An IBS scheme is a type of public-key cryptography which eliminates the need for conventional public key certificates and associated Public Key Infrastructure (PKI), which includes the issuing and administration of public key certificates. In the IBS scheme, and Identity-Based Cryptography in general, public keys consist of a publicly known string, which can be used to uniquely identify an individual, organization or computing entity, e.g. an e- mail address, a mobile number or a website URL. Provided that the known string uniquely identifies an individual, organization or computing entity, this string essentially also serves as a user ID.
In any event, the digital signature and transaction public key, to be used for signature verification, is returned through a secure connection to the transaction information sender using either a computer 16 or a mobile communications device 8.
The transaction information sender will now encode the information into a data set consisting of: metadata, transaction information, transaction public key and the digital signature.
The transaction data set is sent from the transaction information sender to the mobile communications device 18 of the transaction information receiver.
There are numerous ways in which this could occur and a few of these methods will now be described as it should be appreciated that other methods could equally be used without detracting from the heart of the invention.
In a first example illustrated in Figure 3, the transaction data set is transmitted from the transaction information sender to the transaction information receiver via a communications network.
It should be appreciated that the type of network used for interconnecting the elements depicted in Figure 3 may include, for example, the Internet, local area networks, wide area networks, public switched telephone networks, networks based on dedicated leased lines, wired or wireless networks, fibre- optic networks or any other suitable networking technology.
Where communication paths between elements require security, a secure network connection will be used offering both encryption and authentication, for example the Transport Layer Security (TLS) protocol.
In any event, where the communications network is a mobile communications network, the transaction data set could be sent directly to the mobile communications device 18 of the receiver.
Where the communications network is the Internet, the transaction data set could be received on a separate computer of the receiver from where it will be transferred to the mobile communications device 18 of the receiver.
Alternatively or in addition, the transaction data set could be received in an executable application executing on the mobile communications device 18.
In one example embodiment, the transaction data set is formed into a 2D code that can be read using the mobile communications device 18 and particularly using a camera incorporated into the mobile communications device 18.
One example of a 2D code is a Quick Response (QR) code.
Using the example of a QR code, the transaction data set is formed into a QR code and displayed to the transaction information receiver.
This could be done electronically via the Internet for example or in a non electronics fashion such as being printed on an invoice.
Thus it will be appreciated that the sender of the transaction information (in this example a merchant creating a payment request) may be off-line, in which case the merchant may invoice a customer for goods or services delivered by sending an invoice with the 2D-code printed on the invoice. The merchant may also be online, in which case the online merchant may display the 2D-code on the checkout page of the online merchant web server.
In either case the transaction information receiver will use their mobile communications device 18 to scan the QR code and thus obtain the transaction data.
Referring to Figure 4, the mobile communications device 18 includes a processor 52 which controls the operation of the mobile communications device 18.
A communications module 54 allows the mobile communications device to transmit and receive data.
Camera 56 allows the mobile communications device, for present purposes, to scan QR codes.
A user interface 58 allows the user to input commands into the mobile communication device. The user interface 58 could be one or more of a key pad, external buttons or a touchscreen through which a user can input commands to the mobile communications device 18.
A display 60 is used to display information to the user.
Finally, a memory 62 is used to store data such that the memory 62 is secure against malicious tampering of data.
As described above, the transaction data set is received and the mobile communications device 18 in one of the many ways described above.
An executable application executing on the processor 52 controls the mobile communications device to process the transaction data as will be described below in order to effect the transaction described by the data.
Firstly, the transaction public key is extracted and it is verified that the transaction public key has not expired.
If the transaction public key has not expired, the authenticity and integrity of the transaction information is verified by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key.
Once it has been ascertained that the digital signature is valid, the received transaction information is further processed to determine if the transaction information is uniquely associated with the sender of the transaction information and the receiver of the transaction information.
This is done by verifying a transaction association value.
The executable application running on the processor 52 verifies the transaction association value by obtaining identification information in the form of a User ID of the sender from the transaction public key and obtaining identification information of the receiver from the received transaction information.
The processor 52 now calculates a transaction association value by hashing the identification information of the sender and receiver to obtain a transaction association value.
A list of previously stored approved transaction association values is next retrieved from the memory 62 of the mobile communications device.
The calculated transaction association value is compared with the values stored in the list to determine if the calculated value is found within the list.
If the calculated value is found within the list, then the transaction association value is considered verified and the transaction information is displayed to the receiver via the display 60 of the mobile communications device 18.
The user will also be prompted via the display 60 to approve the transaction by inputting an approve command via the user interface 58.
An example of this could be displaying to the user two options, approve transaction and decline transaction, and requesting the user to select one.
The user input is received by the processor 52 via the user interface 58, and if the user input selected is to approve the transaction, the transaction information is transmitted from the mobile communications device 18 to a payment system 64 (Figure 3) to effect the transaction. It will be appreciated that the payment system 64 of Figure 3 is the central server 10 of Figure 1 .
If the user input received is to decline the transaction, the transaction is cancelled by not transmitting the transaction information.
In this case, a notification is displayed to the user that the transaction has been cancelled.
If the calculated transaction association value is not found within the retrieved list of transaction association values then one or more messages are displayed to the user via the display 60 of the mobile communications device 18.
The first message displayed asks the user if they want to proceed to approve a new transaction and if the user approves this then another message will be displayed to the user.
The next message displayed will display the transaction information to the user and that the transaction involves a new sender and/or receiver of transaction information, as well as identification information for both the sender and receiver which will be displayed together with a request for approval of this information.
If the user input now selected is again to approve the transaction, the transaction information is transmitted from the mobile communications device 18 to a payment system 64 to effect the transaction and in this scenario the calculated transaction association value is added to the list of stored in the memory 62.
In all cases where the user selects to approve the transaction, they may be asked to input for example, a Personal Identification Number (PIN) or biometric data based on a fingerprint or facial recognition, for example.
Referring to Figure 3 and as mentioned above, if the user selects to approve the transaction the transaction information is transmitted to the payment system 64
The payment system 64 may be operated by a banking or non-banking institution and is used to settle transactions. A user obtains access to payment services, being an account holder at the institution. The payment system 64 settles transactions by processing at processor 66 transaction
information received from a transaction information receiver 18 over a secure network connection.
Upon successful transaction execution, the payment system 64 may generate a notification providing proof of successful transaction execution, which is sent through a secure network connection to an instant notification service 68.
The instant notification service 68 offers instant notification for transactions such as payments where the original transaction information sender expects proof of payment before shipping goods sold or services rendered.
The instant notification service 68 may either be implemented as an online service or dedicated server, which may consist of suitable computing equipment that contains a processor (and circuitry) 72 to execute processor instructions associated with transaction notification software. The instant notification service may be connected, through a secure network connection to one or more transaction information senders enrolled with the instant notification service and credentials stored in a database 74 accessible to the service.
A notification received from a payment system 64 is sent to the appropriate transaction information sender based on unique identification information contained within the notification.
The above methodology will now be described with reference to three different transaction applications.
A first embodiment of the invention, illustrated in Figure 5, allows an account holder holding an account at a bank, represented by bank server 64, to make an online purchase using a smartphone 18 while visiting an online store using a client computer 76.
The payment is made to an online merchant, represented by merchant web server 78, by way of a bank credit transfer using a banking software application (not shown) running on the smartphone 18.
The banking software application provides a secure wireless connection to the account holder’s Internet banking profile with the bank.
The banking software application furthermore has cryptographic and QR code scanning capabilities for scanning and reading transaction information from a QR code to initiate the bank credit transfer.
The bank server 64 operates a payment system based on Internet banking for settling transactions.
The account holder using smartphone 18, equipped with a camera 56 and running a banking software application with cryptographic and QR code scanning capabilities with a secure wireless connection to the bank server 64, serves as an embodiment of a transaction information receiver.
The merchant uses the web server 78 running a web application that offers a checkout page with payment transaction information, and serves as an embodiment of a transaction information sender.
The signature generation service 24, key generation server 38 and instant notification service 68 may be located at trusted authorities.
Assuming the key generation server 38 completed its initial setup phase, the trusted authority distributes once-off, cryptographic system parameters and master public key 44 to the bank server 64 and signature generation service 24.
The bank server 64 in turn integrates these cryptographic system parameters and master public key 44 with the banking software application running on smartphones 18, used by their banking customers to obtain secure wireless access to their Internet banking profiles.
The sequence of steps for the account holder making an online purchase or payment to the merchant, by way of a bank credit transfer from the account holder’s Internet banking profile, are as follows.
The account holder uses Internet browser software (not shown) running on a client computer 76 connected to the Internet to visit the online merchant web page hosted by the merchant web server 78.
The account holder chooses to make a payment for items ordered from the online merchant.
The online merchant web server 78 requests, through a secure network connection with the signature generation service 24, a digital signature for transaction information suitable for performing a bank credit transfer from the account holder’s bank account to the merchant’s bank account.
Transaction information will at least include:
a. Merchant identification information, to be used by the account holder for unique identification of the merchant to confirm that a funds transfer will be in favour of the intended merchant. Merchant identification information may for example, consist of the merchant business name and merchant web site URL.
b. Merchant bank account information.
c. Reference information to identify the payment, such as an online order number.
d. The amount due to the merchant.
e. Receiver identification information.
The signature generation service 24 generates an identity-based digital signature over the transaction information received from the uniquely identified online merchant, using a transaction private key 34 obtained from the key generation server 38. The digital signature and transaction public key
36 to be used for signature verification are returned through a secure connection to the merchant server 78.
The merchant server 78 uses transaction composing software to compose secure authenticated transaction information consisting of, for example, metadata, transaction information, a transaction public key and a digital signature. The secure authenticated transaction information is encoded within a QR code and displayed on the checkout page.
The account holder receives the checkout page within a browser session running on the client computer 76.
The account holder uses smartphone 18 running a banking software application with access to an Internet banking profile, to scan the QR code displayed on the client computer 76 screen.
The banking software application scans the QR code as described and the verification process proceeds as has been described above.
Firstly, the transaction public key is extracted and it is verified that the transaction public key has not expired.
If the transaction public key has not expired, the authenticity and integrity of the transaction information is verified by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key as described.
Once it has been ascertained that the digital signature is valid, the received transaction information is further processed to determine if the transaction information is uniquely associated with the sender of the transaction information and the receiver of the transaction information.
This is done by verifying a transaction association value as has been described.
The executable application running on the processor 52 verifies the transaction association value by obtaining identification information of the sender from the transaction public key and obtaining identification information of the receiver from the received transaction information.
The processor 52 now calculates a transaction association value by hashing the identification information of the sender and receiver to obtain a transaction association value.
A list of previously stored approved transaction association values is next retrieved from the memory 62 of the mobile communications device.
The calculated transaction association value is compared with the values stored in the list to determine if the calculated value is found within the list.
If the calculated value is found within the list, then the transaction association value is considered verified and the transaction information is displayed to the receiver via the display 60 of the mobile communications device 18.
The user will also be prompted via the display 60 to approve the transaction by inputting an approve command via the user interface 58.
If the user input is received to approve the transaction, the transaction proceeds as will be described below.
If the user input received is to decline the transaction, the transaction is cancelled by not transmitting the transaction information to the bank server 64. In this case, a notification is displayed to the user that the transaction has been cancelled.
If the calculated transaction association value is not found within the retrieved list of transaction association values then a message is displayed to the user via the display 60 of the mobile communications device 18.
The message will inform the user that the transaction involves a new sender and/or receiver of transaction information and identification information for both the sender and receiver will be displayed together with a request for approval of this information before continuing to display transaction information also for approval by the user.
As mentioned above, upon successful verification of the QR code, transaction information is shown to the account holder to be approved or rejected, with an example shown in Figure 6a.
Information to be reviewed consists of the type of transaction 80 to be performed, merchant identification information 82, the amount due 84 to the merchant, optionally merchant bank account information and payment reference information 86, and a choice to reject 88 or approve 90 the transaction.
The account holder reviews the transaction information and approves by way of, for example, a PIN or biometric data based on fingerprint or facial recognition.
In response to approval by the account holder, the banking software application running on the smartphone 18 transmits the transaction information to the bank server 64 over a secure wireless connection for transaction processing and execution at the bank.
In case of successful transaction execution, the bank server 64 sends a proof-of-payment notice, containing at least transaction payment details combined with merchant identification information, to the notification service 68, over a secure network connection.
The notification service 68 in turn uses the merchant identification information from the proof-of-payment notice to forward the notification to the merchant server 78 being paid.
The merchant server 78, upon receipt of the notice, recognises the payment based on reference information indicating the order number, and concludes the purchase made by the account holder through a message on the checkout page indicating that payment was received.
It should be appreciated that a variation of the secure authenticated transaction information encoded in a 2D-code may include using an electronic data message format or electronic file format to convey the authenticated transaction information instead of using a 2D-code and that this variation still falls within the scope of the invention.
A second embodiment of the invention, illustrated in Figure 7, employs a variation and allows an account holder holding an account at a bank, represented by bank server 64, to make an online purchase using the smartphone 18 while visiting an online store using an Internet browser application running on the same smartphone 18.
Similarly to the previous embodiment, the payment is made to the online merchant, represented by merchant web server 78, by way of a bank credit transfer using a banking software application (not shown) running on the smartphone 18. But in contrast with the previous embodiment, the banking software application receives the secure authenticated transaction information using an electronic data message format as opposed to scanning a QR code conveying the secure authenticated transaction information.
In this example, the account holder will use Internet browser software (not shown) running on a smartphone 18, wirelessly connected to the Internet to visit the online merchant web page hosted by the merchant web server 78.
The account holder chooses to make a payment for items ordered from the online merchant.
The online merchant 78 requests, through a secure network connection with the signature generation service 24, a digital signature for transaction information suitable for performing a bank credit transfer from the account holder’s bank account to the merchant’s bank account. This step is performed consistently with the corresponding step in the first embodiment. The signature generation service 24 generates an identity-based digital signature over the transaction information received from the uniquely identified online merchant 78, using a transaction private key 34 obtained from the key generation server 24. The digital signature and transaction public key 36 to be used for signature verification are returned through a secure connection to the merchant server 78.
The merchant server 78 uses transaction composing software to compose secure authenticated transaction information consisting of, for example, metadata, transaction information, a transaction public key 36 and a digital signature.
The web application running on the merchant web server 78 detects that a smartphone is used to visit the online store. Accordingly the secure authenticated transaction information is embedded in an electronic data message format that can be passed, in the form of a JavaScript object, from a web page payment button on the checkout page to a native smartphone banking software application.
The account holder receives the checkout page, containing the payment button, within a browser session running on the smartphone 18.
When the account holder presses the payment button, the secure authenticated transaction information is passed as a data message by, for example, using a JavaScript object, from the checkout page to the banking software application.
The banking software application reads the received data message to check that that the transaction public key 36 has not expired and that the digital signature verifies successfully using the transaction public key 36 obtained from the data message. This process, which includes transaction association value verification, is the same as has been described above with reference to the previous embodiment.
Upon successful verification of the data message in the manner described above, transaction information is shown to the account holder to be approved or rejected as shown in Figure 6a.
The account holder reviews the transaction information and approves by way of, for example, a PIN or biometric data based on fingerprint or facial recognition. In response to approval by the account holder, the banking software application running on the smartphone 18 transmits the transaction information to the bank server 64 over a secure wireless connection for transaction processing and execution at the bank.
In case of successful transaction execution, the bank server 64 sends a proof-of-payment notice, containing at least transaction payment details combined with merchant identification information, to the notification service 68, over a secure network connection.
The notification service 68 in turn uses the merchant identification information from the proof-of-payment notice to forward the notification to the merchant server 78 being paid.
The merchant server 78, upon receipt of the notice, recognises the payment based on reference information indicating the order number, and concludes the purchase made by the account holder through a message on the checkout page indicating that payment was received.
A third embodiment of the invention, illustrated in Figure 8, allows an account holder holding an account at a bank, represented by bank server 64, to make a peer-to-peer payment to another account holder holding an account at another bank represented by bank server 92.
The payment is made by way of a bank credit transfer using a banking software application (not shown) running on each account holder’s smartphone 18. The banking software application provides a secure wireless connection to each account holder’s Internet banking profile with banking servers 64 and 92 respectively.
The banking software application furthermore has cryptographic and QR code scanning capabilities for scanning and reading transaction information from a QR code to initiate the bank credit transfer.
The first account holder using smartphone 18a, equipped with a camera 56 and running a banking software application with cryptographic and QR code scanning capabilities with a secure wireless connection to bank server 92, serves as an embodiment of a transaction information sender.
The second account holder using smartphone 18b, equipped with a camera 56 and running a banking software application with cryptographic and QR code scanning capabilities with a secure wireless connection to the bank server 64, serves as an embodiment of a transaction information receiver.
The first account holder with smartphone 18a uses the banking software application running on smartphone 18a to create a payment request which includes specifying the amount requested from the second account holder with smartphone 18b.
The banking software application on smartphone 18a requests, through a secure wireless network connection with bank server 92, a digital signature for transaction information suitable for receiving funds through a bank credit
transfer from the bank account of the second account holder using smartphone 18b.
Transaction information will include one or more of:
a. Identification information for the first account holder to be used by the second account holder for unique identification of the first account holder to confirm that a funds transfer will be in favour of the intended individual. Account holder identification information may for example consist of a mobile number.
b. The first account holder bank account information.
c. Reference information to identify the payment.
d. The amount requested.
The bank server 92 requests the digital signature, on behalf of the first account holder, from the signature generation service 24.
Hence, the signature generation service 24 generates an identity-based digital signature over the transaction information received from the uniquely identified bank server 92, using a transaction private key 34 obtained from the key generation server 24.
The digital signature and transaction public key 36 to be used for signature verification are returned through a secure connection.
The banking software application running on smartphone 18a receives the digital signature and transaction public 34 key from banking server 92 which is used to compose secure authenticated transaction information representing the payment request.
The secure authenticated transaction information may include, for example, metadata, transaction information, a transaction public key 36 and a digital signature.
The secure authenticated transaction information is encoded within a QR code, and displayed on the screen of smartphone 18a which is in turn displayed to the second account holder.
The second account holder using smartphone 18b running a banking software application, scans the QR code presented on smartphone 18a.
The QR code is scanned, checking that that the transaction public key 36 has not expired and that the digital signature verifies successfully using the transaction public key 36 obtained from the QR code. This process is the same as has been described above with reference to the previous embodiment.
Upon successful verification of the QR code, transaction information is shown to the second account holder via 18b to be approved or rejected.
The second account holder reviews the transaction information and approves by way of, for example, a PIN or biometric data based on fingerprint or facial recognition. In response to approval by the account holder, the banking software application running on smartphone 18b transmits the transaction information to bank server 64 over a secure wireless connection for transaction processing and making a credit transfer to the bank account belonging to the first account holder.
Upon successful transaction execution, banking server 64 creates a proof of payment notice. To ensure that the notice can be securely verified, bank server 64 also requests, from digital signature service 24, a digital signature for the notice.
The digital signature is computed over the transaction payment information using an identity-based digital signature scheme and transaction private key 34 obtained from the key generation server 24.
The digital signature and transaction public key 36, to be used for signature verification, are returned with the proof of payment notice through the secure connection with smartphone 18b.
The banking software application running on smartphone 18b composes secure authenticated transaction information consisting of, for example, metadata, the transaction payment information, a transaction public key and a digital signature received from the proof of payment notification. The secure authenticated transaction information, representing proof of payment, is encoded within a QR code displayed on the screen of smartphone 18b.
Account holder using smartphone 18a running a banking software application, scans the QR code displayed on smartphone 18b. Upon successful verification of the QR code, using the transaction public key 36 obtained from the QR code, transaction payment information is shown to account holder providing proof that the peer-to-peer payment was in fact successfully executed.
This embodiment of the invention is obviously not limited to the assumption that both account holders communicate face to face. The embodiment would be equally relevant to account holders being far apart since the QR codes are protected against fraudulent modification and it would be quite easy to exchange the QR codes through other means such as GSM text messages or even instant messaging applications allowing instant communication over the Internet.
It should be appreciated that a variation of the latter embodiment of the invention may consist of excluding the amount to be paid from the payment request such that the remaining information within the secure authenticated transaction information can be used in a QR code as a way of sharing bank account information.
Hence, another embodiment of the invention may therefore be used by an account holder to add a new beneficiary (i.e. a recipient of funds) to his or
her Internet banking profile, for purposes of future bank credit transfer(s) to be made by the account holder to the recipient.
The account holder may scan this QR code from, for example, a printed utility bill or printed invoice displaying the QR code. The sequence of steps for the account holder to add a new beneficiary to his or her Internet banking profile, are as follows.
The account holder uses a smartphone 18 running a banking software application to scan the QR code as described above, checking that that the transaction public key 36 has not expired and that the digital signature verifies successfully using the transaction public key 36 obtained from the QR code.
Upon successful verification of the QR code, transaction information is shown to the account holder to be approved or rejected, with an example shown in Figure 6b.
Information to be reviewed consists of the type of transaction 94 to be performed, beneficiary identification information 96, beneficiary bank account information 98 and a choice to reject 100 or approve 102 the transaction.
The account holder reviews the transaction information and approves by way of, for example, a PIN or biometric data based on fingerprint or facial recognition. In response to approval by the account holder, the banking software application running on the smartphone 18 transmits the transaction information to the bank over a secure wireless connection for the beneficiary to be added to the account holder’s Internet banking account.
From these exemplary embodiments of the invention, it should be evident that the system and method for secure authentication of transaction information described above, eliminates the drawbacks associated with at least online payments when paying by way of a bank credit transfer.
The user (or account holder) is completely relieved from the burden of manually entering transaction information such as bank account information, reference information and a purchase amount. This eliminates the risk of human error such as typing errors which typically occurs in typing long account numbers.
The fact that transaction information is digitally signed, in accordance with the invention, also protects the integrity and authenticity of information providing complete protection against any accidental or fraudulent changes which may occur due to malware in the browser used to visit an online merchant website.
A maximum level of convenience is made possible through a simple combination of actions consisting of: scanning a 2D-code, reviewing transaction information, approving a transaction to be executed through PIN or biometric data recognition.
Apart from an improved user experience offered by the invention, a further benefit is the fact that the 2D-code conveying transaction information can be instantly verified through verification of the digital signature without a requirement for any external authentication service. The advantage here is saving time in making yet another secure connection to such an authentication service, which is important as this connection time would prolong the time to conclude a purchase transaction. A longer transaction time would in turn diminish user experience.
An additional benefit is the fact that the 2D-code conveying transaction information can be verified through verification of the digital signature without requiring that a public key certificate be embedded in the 2D-code for purposes of verification. This results in a 2D-code which has a much lower density which in turn improves scanning speed and scanning reliability when a user uses a smartphone to scan the 2D-code.
It is conceivable that a user would avoid using a smartphone running an Internet banking application, to perform a credit transfer payment if required
to manually enter a fair amount of transaction information. The simple reason being the risk of typing errors when using the small virtual keyboard associated with most smartphones. Such a user would most likely perform such a payment using a client computer and larger keyboard typically located at home or the office. With this invention, this problem is solved in the event that a 2D-code is available for making a payment using a smartphone. Hence, this invention introduces another benefit to the user in that the user can truly make payments on-the-go rather than being limited to specific locations for making payments.
It should be appreciated that where embodiments of the invention are described for making a payment by way of a funds transfer from one bank account to another bank account, that the invention is not limited to bank credit transfers. The invention would equally apply to for example, a bitcoin payment. In the latter case no bank is involved and the payment destination does not consist of a bank account details but rather a bitcoin address. So for a bitcoin payment, transaction information would for example consist of recipient identification information, such as a name and URL, a bitcoin address and the amount due. This type of variation therefore still falls within the scope of the invention.
A yet further variation of the invention, for making a payment by way of a funds transfer from one bank account to another bank account, would be to substitute bank account information with a reference to bank account information, for example, a mobile number. With this variation, the payment or funds transfer may be effected by way of reference.
The invention described in this specification is by way of exemplary embodiments only and it should be appreciated that several further modifications may be made and different configurations be used without departing from the scope of the invention as described in this specification.