WO2006128215A1

WO2006128215A1 - Method and system for secure authorisation of transactions

Info

Publication number: WO2006128215A1
Application number: PCT/AU2006/000701
Authority: WO
Inventors: Chris Baharis; Ross Oakley
Original assignee: Salt Group Pty Ltd
Priority date: 2005-05-31
Filing date: 2006-05-25
Publication date: 2006-12-07

Abstract

A system for secure authorisation of transactions comprising a secure encryption/decryption device (SEDD) (108) for processing a PIN transport message (PTM) received from a user mobile terminal (140), the PTM including a user entered personal identification number (PIN) and payment data both encrypted with a user public key, the SEDD (108) processing the PTM to decrypt the PTM with the user's private key and re-encrypt with a merchant key as at least part of forming a payment request message (PRM).

Description

Ti tle

METHOD AND SYSTEM FOR SECURE AUTHORISATION OF TRANSACTIONS

Field of the Invention

The present invention relates to a method and system for secure authorisation of transactions. The invention also extends to a technique for providing a security application to a user of the secure authorisation system.

Background to the Invention

Currently most payments made over the Internet or to telephone based payment services are made by credit cards or credit card derivatives such as PayPal^®.

Whilst providing convenient payment mechanisms, credit cards and their derivatives have a number of disadvantages including the fact that fees are generally charged based on the value of the transaction and hence must either be absorbed by the merchant or passed onto the consumer. Another disadvantage is that there is a risk of merchant charge backs for unauthorised fraudulent credit card payments. Another disadvantage is that such systems rely on the user having a credit card.

Currently there exists facilities for making debit type payments via the Internet. In Australia one such system is known as "BPAY". This allows a user to visit their

Internet banking site and initiate a debit type payment. One of the disadvantages of such a service is that the debit transaction must be initiated through the payee bank' s Internet banking service rather than via the merchant's (acquiring) bank as is the case with credit card payments. As such, payment authorisation is outside the transaction flow of a typical online purchase with checkout style payments. Accordingly such models are currently not seen as practical by online merchants as due to the asynchronous nature of the payment, neither the payor nor the payee has a definitive closure point for the transaction from which subsequent actions can be reliably based (such as shipping goods, placing wages or issuing tickets) . That is, the payment cannot be completed at the time the goods, tickets etc. are ordered.

Accordingly, an alternative authorisation technique is required which has general application to authorisation of transactions but is particularly suited to authorisation of debit payments on the Internet, or other remote channel, so that debit payments can proceed in real time.

Summary of the Invention

In a first broad aspect of the invention, there is disclosed a system for secure authorisation of transactions comprising: a secure encryption/decryption device (SEDD) for processing a PIN transport message (PTM) received from a user mobile terminal, the PTM including a user entered personal identification number (PIN) and payment data both encrypted with a user public key the SEDD processing the

PTM to decrypt the PTM with the user's private key and re- encrypt with a merchant key as at least part of forming a payment request message (PRM) .

Thus, the PIN is not exposed outside the secure environment of the SEDD and a PRM can be generated to be sent to an existing payment network (EPN) (e.g. a bank) either directly or via the merchant system.

Preferably, the SEDD also processes user data to incorporate user data that identifies the user into the PRM. Preferably the system comprises a transaction processor for receiving the PTM from the user mobile terminal, sending the PTM to the SEDD and subsequently forwarding the PRM.

Typically, the transaction processor provides the user data to the SEDD. The user data may include an account number or a debit card number.

Preferably, the SEDD stores a secure encryption key and the system further comprises a data store in data communication with the transaction processor, the user's private key being stored in the data store encrypted by the secure encryption key, and the transaction processor sends the user's encrypted private key to the SEDD with the PTM whereafter the user's private key can be decrypted by the SEDD before being used to decrypt the PTM.

Thus, the user's private key is not exposed outside the SEDD.

Preferably, the SEDD is configured such that there is no externally accessible function to decrypt data with the user's private key. This prevents a 'rogue' transaction processor requesting the SEDD to provide the PIN in the clear.

Preferably, the SEDD is configured so that there is no externally accessible function to encrypt data with the user's public key as would typically be available in such a system. This prevents a 'rogue' transaction processor completing a brute force attack on the PTM (i.e. try all combination of PINs and data until a match with the PTM is found) .

Preferably, the merchant key is stored in the data store encrypted by the secure key and the transaction processor sends the merchant key to the SEDD with the PTM and the SEDD decrypts the merchant key with the secure key to obtain the merchant key.

Thus, the merchant key is kept encrypted outside the SEDD.

Preferably, the transaction processor is configured to receive transaction data from a merchant system, the transaction data including user data that identifies the user, merchant data that identifies the merchant and payment data related to a transaction between the user and the merchant, the transaction processor being configured to send payment data to the SEDD together with the encrypted user private key retrieved from the data store on the basis of the user data, the SEDD decrypting the user's private key and encrypting the payment data with the user's private key whereafter the payment data can be sent to a user's mobile terminal as a PIN request message (PRS) .

Typically, the user data is used to retrieve other data relating to the user, for example a mobile terminal number or Track-2 data, that is required by the system to carry out various functions.

It will be appreciated by persons skilled in the art that the payment data may vary at different times and may include differing amounts of data, however at all times the payment data includes at least the payment amount.

Thus, after the PRS is sent to the mobile terminal the payment data can be decrypted from the PRS and displayed to the user.

Preferably, the user mobile terminal is configured to automatically decrypt and display the payment data in response to receipt of the PRS .

Preferably, the user mobile terminal is configured to prompt the user to enter a PIN to approve the transaction following display of the payment data.

Preferably, the user mobile terminal is configured to generate the PTM in response to the user entering a user entered PIN.

It will be appreciated that the user entered PIN may not be the user's actual PIN in which case the PRM will be invalid and payment will be refused by the payment network.

It will also be appreciated that the PIN is not stored outside the existing payment network.

Preferably, the SEDD includes a key generation mechanism for generating user private and public keys.

Typically, the transaction processor comprises a computer or computers running a program that causes the transaction processor to carry out the above functions .

Typically, the user mobile terminal runs an authorisation program to be configured as described above. For example, the authorisation program may employ J2ME whereby the program can be executed automatically in response to receipt of the PRS.

It will also be appreciated that the use of the terms "private" and "public" keys is in some ways contrary to the convention where the private key is held by the user. However, it will be appreciated by persons skilled in the art that public key operations are generally faster than private key operations of asymmetric key pairs and further that the techniques employed above result in the private key being safer when stored in the data store.

Preferably, the system comprises a provisioning mechanism for providing the user public key and the authorisation program to the user mobile terminal.

Preferably, the authorisation program is individualised for the user by embedding at least the user public key in the code before being provided to the user.

Preferably, in order to function, the authorisation program requires entry of an activation code and the activation code is provided to the user independently of the authorisation program, for example by display in a web browser during activation.

It will be appreciated that parts of the various messages may only be relevant to the transaction processor as it controls the flow of data between various system components and hence will not be passed to the SEDD or formed by the SEDD, while attempts are made to reflect this distinction by employing language such as "forming "part of ..." or "at least the portion ..." , the various messages should not be understood as being identical within the SEDD as within the transaction processor, and the references should be interpreted accordingly.

The invention also extends to a method for secure authorisation of transactions comprising: providing a secure encryption/decryption device (SEDD) ; receiving a PIN transport message (PTM) from a user mobile terminal, the PTM including a user entered PIN and payment data both encrypted with a user public key; processing at least an encrypted portion of the PTM within the SEDD to decrypt it with the user's private key and re-encrypt it with a merchant key as at least part of forming a payment request message (PRM) for the merchant system that can be passed to an existing payment network.

Preferably, the user's private key and merchant key are stored outside the SEDD encrypted with a secure key stored within the SEDD. Preferably the secure key is also generated within the SEDD. Preferably, the user's private key and merchant key are each provided to the SEDD with the PTM and encrypted within the SEDD to enable processing of the PTM.

Preferably, the method comprises receiving transaction data from a merchant system including user data, payment data and merchant data and encrypting at least the payment data within the SEDD as at least part of forming a PIN request message (PRS) to be sent to a mobile terminal.

Preferably, the method comprises decrypting the PRS at the mobile terminal with the user public key, and presenting payment data to the user for approval .

Preferably, if the user approves the transaction, the user enters a PIN and the payment data and user entered PIN are encrypted with the user public key and sent as the PTM for processing by the SEDD.

In a second broad aspect, the invention extends to a method of providing a security application to a user of a secure authorisation system, comprising: providing base code for carrying out at least one secure authorisation function; providing a public/private key pair; compiling the base code with at least the public key to form a user specific security application in which at least the public key is embedded; and providing the user specific security application to a mobile terminal of the user.

Preferably, the base code is also compiled with at least one of a serial number and one of an issuer number.

Preferably, the method further comprises generating a provisioning key, encrypting it with an activation code and the encrypted provisioning key is embedded in the user specific security application in the compiling step.

Preferably, the method comprises encrypting the user public key under the provisioning key.

Preferably, the method comprises activating the user specific application by providing the activation code to a user via a different channel by which the user specific security application was provided, the user entering the activation code, the security application decrypting the provisioning key on the basis of the activation code, decrypting the user public key with the provisioning key and generating a confirmation code in response to entry of the activation code using the provisioning key. The user then provides the confirmation code to a validation means which activates the user if the confirmation code is correct .

Brief Description of the Drawings

A preferred embodiment of the invention will now be described in relation to Figure 1 which shows a system for secure authorisation of transactions of a preferred embodiment .

Description of the Preferred Embodiment

The preferred embodiment provides a system for secure authorisation of transactions. The system is particularly suited to be fitted within existing payment networks, for example electronic funds transfer systems such as the Australian system "EFTPOS" (Electronic Funds Transfer Point Of Sale) .

Currently, the key features of a secure electronic funds transfer system are that user PINs are entered by a secure cryptographic device (typically known as a PIN PAD) , details of the transaction are displayed within the secure cryptographic device such that the card holder can reasonably be assumed to have viewed the transaction and approved it if they enter their PIN and the PINs are encrypted by the PIN PAD and transferred in an encrypted form to the issuing bank for verification. It will be appreciated that such a system addresses a number of security threats including: the threat that a merchant/third party will access the secret cryptographic key material held within the PIN pad and used to encrypt customer PINs for relay to a bank verification.

The threat of exposure of a clear text customer PIN to third parties or third party application systems or networks for later user of the PIN by an authorised party. The threat of the transaction detail (amount, payee etc.) being changed after authorisation by the user without the user's knowledge.

The disadvantage of this system is that it requires a user to be have access to the secure cryptographic device when the transaction is confirmed - this usually requires the user to be present when the transaction is carried out, and accordingly it is not suited to transactions initiated online or via interactive telephone systems.

The preferred embodiment attempts to provide a system having an equivalent level of security that allows a user to authorise transactions when they are not present without having to provide the user with any customised hardware or interfering with the existing transaction flow from the customer or merchant perspective.

In the preferred embodiment this is achieved by having a transaction authorised by a user entering their PIN into a mobile terminal e.g. a mobile phone or (cellphone) . In the preferred embodiment the user is provided with an individualised security application that is executed on their mobile terminal. A virtual PIN PAD service handles a number of encryption/decryption processes using a secure encryption device in the form of a hardware security module in order to keep those transactions secure. This technique will be described in further detail in relation to Figure 1.

The central component of the system is the virtual PIN PAD service (VPS) 100. The virtual PIN PAD service 100 comprises means for processing a transaction in the form of virtual PIN PAD software (VPSW) 101 and data communication with a hardware security module (HSM) 108. The hardware security module 108 is a secure encryption/decryption device. Such devices have a number of characteristic features that are known to persons skilled in the art and are provided in hardware as a board or a box. Such devices include internal storage for storing a limited number of keys; cryptographic processors for creating both a local master key (LMK) and, in the preferred embodiment user private and public key pairs.

The user private and public key pairs and all other keys generated by the cryptographic processor that are to be exported from the HSM 108 are typically exported encrypted under the LMK 109 so they are not available in the clear. The device 108 is designed so that if anyone tries to tamper with it the keys are deleted automatically. In the preferred embodiment, the HSM 108 is configured with additional functions not found in existing HSMs such that: there is no externally accessible function to decrypt data with the user's private key. This prevents a ^Λrogue' transaction processor requesting the SEDD to provide the PIN in the clear; and there is no externally accessible function to encrypt data with the user's public key as would typically be available in such a system. This prevents a *rogue' transaction processor completing a brute force attack on the PTM (i.e. try all combination of PINs and data until a match with the PTM is found) .

As will be apparent from the following description all other keys are stored outside the HSM 108 encrypted under the LMK 109 and imported into the HSM 108 as needed. The apparatus has a data store having a number of logically different storage areas 103,104. There is a provisioning web server 106 for providing a user with a security application and for activating user's within the system. A message gateway 107 enables the virtual PIN PAD service 100 to communicate over the air (OTA) 150 with a mobile terminal 140. The provisioning web server 106 communicates over the Internet with a user's web browser 110 as well as with a mobile terminal 140 via an Internet to over the air gateway and hence via WAP protocol over the air 150 to the mobile terminal 140. The virtual PIN PAD service also communicates via the Internet 130 with the merchant system 120. In the illustrated embodiment, the user initiates transactions with a merchant system 120 via Internet 130.

The merchant system includes a virtual PIN PAD service API that makes calls to the virtual PIN PAD service in response to the transaction being initiated. The virtual PIN PAD service then takes the necessary steps to authorise the transaction. If the transaction is authorised by the user entering a PIN into their handset 140 a payment request message that conforms to the existing payment network 160 is returned to the merchant system so that it can be forwarded to the existing payment network for approval and settlement. If the transaction is approved by the existing payment network (i.e. funds are available in the user's account) a payment network response message is returned to the merchant system and the merchant system can advise the user of web browser 110 that the transaction has been completed satisfactorily. In this way, the transaction can be completed within real time and within the normal transaction flow of the web browser. Further details of the system will become apparent from the description below.

System Initialisation

The virtual PIN PAD service 100 is initiated by a number of functions.

A local master key 109 is generated securely in the hardware security module 108. A range of serial numbers are then allocated for an issuer (e.g. a bank) in order to produce a batch of individualised security applications. In the preferred embodiment, these security applications are known as application load units (ALU) . Typically, tens of thousands of application load units will be produced in a single batch run. In this way, the application load units can be produced at a time when the hardware security module 108 is not being used for other functions and most typically, before the system is processing transactions. In order to produce the ALUs, asymmetric key pairs (one public key and one private key) are generated in the hardware security module and then exported encrypted under the LMK.

The generated key pair is stored in the ALU list 104c part of the data store and indexed by the issuer number and a serial number. Thus, the private keys are always encrypted by the LMK when outside the HSM. For each application load unit, for provisioning purposes only, a provisioning key and an activation code are generated. These are also both exported and encrypted under the LMK and stored in the ALU list 104c until needed. The provisioning key and activation code are also indexed by the issuer number and serial number. Further, the provisioning key is exported encrypted under the activation code for embedding in the ALU.

An ALU is then generated for each serial number and the provisioning key (which is encrypted under the activation code) and the public key (which is encrypted under the provisioning key) are embedded in this ALU by compiling base code of an application with the encrypted provisioning key and public key. The base code is code designed to carry out the functions required to be performed by the application once it is running on a mobile terminal. However, by embedding the provisioning and public key within the ALU it makes the keys more difficult to recover. Further, if an ALU is intercepted and copied it is difficult to activate and use it due to the encryption.

Having created the ALUs it is necessary to obtain some data for users. For each user, data from their issuer is imported into the user list 108b while the required user data depends on the requirements of the payment network, this will usually include "track-2" data from the magnetic stripe on the physical account card. While this can be obtained from the issuer in one provisioning embodiment, provisioning may be initiated by a user via an ATM in which case the track-2 data can be obtained as part of the provisioning process. This user data will, when combined with the user account PIN (when it is entered) comprise sufficient information to generate a valid payment request message (PRM) for the existing payment network (EPN) which in this embodiment is the EFTPOS network. This data is stored encrypted under a data encryption key the encrypted data encryption key is stored with the data (i.e. encrypted under the LMK) and is indexed by a VPS Number that is allocated to the user. The VPS Number will typically comprise the user's mobile phone number plus a supplementary code generated by the issuer.

Data is also acquired for each merchant. This includes data from their issuer (e.g. a bank) including one or more PIN PAD keys. The number of PIN PAD keys provided will depend on the expected transaction load for the merchant - i.e. how many online transactions are likely to be completed at any one time. These keys are imported in accordance with processes compatible with existing PIN PAD initialisation methods. Again, this data is stored encrypted under a data encryption key, this time in the merchant list 104a portion of the data store and is indexed by the merchant number and the PIN PAD key number. Importantly, the PIN PAD keys are always encrypted by the LMK when outside of the HSM 108 environment and not available in the clear.

It will be appreciated that additional issuers, merchants, users and ALUs can be added to the system at a later stage without disrupting those already loaded in the VPS 100.

User Provisioning

The user typically registers for the service with their issuer. Registration includes providing their issuer with a mobile phone number. The issuer then allocates an account number known as a VPS Number to the user and one of the ALUs created for that issuer. These details are then provided to the VPS 100 and added to the user list 104b. In order to be provisioned with an ALU and enabled on the system, the user initially uses an Internet connected web browser 110 to navigate to the provisioning web server 106. An appropriate screen is provided in order to allow the user to enter their VPS Number.

The ALU allocated for the VPS Number is selected from the ALU storage 105 and moved to the provisioning web server 105. At this point, the ALU issuer number and a serial number are recorded against the user in the user list 104b. A web link to the ALU is sent to the user's mobile terminal via a provisioning message 171 which is typically a WAP push SMS message. The activation code from the ALU is retrieved from the ALU database, sent by the virtual PIN PAD software 101 to the HSM 108 and decrypted before being sent to the browser 110 for display by the provisioning web server 106. By opening the provisioning message on their handset, the user downloads the application load unit onto their mobile terminal 140 where it is stored as indicated by item 141. After the ALU 141 is downloaded, the ALU 141 is launched and the user is prompted to enter the activation code. The user reads the activation code from their web browser 110. The ALU 141 uses the activation code to decrypt the provisioning key, the provisioning key to decrypt the public key and cryptographically generates a confirmation code in response to entry of the activation code using the provisioning key. The user then is requested to enter the confirmation code into the web browser. The confirmation code is passed to the virtual PIN PAD software and validated (assuming it is correct) by the virtual PIN PAD software 101 which sets the user's status in the user list 104b to enabled. The provisioning key is not used subsequently.

Transactions The user uses a browser 100 to navigate to a merchant website over the Internet 130. It is assumed that the merchant system 120 offers the transaction authentication method of the present invention.

The merchant system runs a virtual PIN PAD service API 121 that makes requests to the virtual PIN PAD software 101 of the VPS 100 as required. Having selected the product or service they wish to purchase from the merchant, the user chooses their account type, for example, cheque or savings and enters their VPS Number. The merchant system sends this information along with the amount, payment summary and a merchant number to the VPS 100. The VPS looks up the user's private key via the user list and the ALUL 104c.

The user list 104b contains the allocated ALU issuer and serial number which is then used to look up the ALU details (e.g. private and public keys in the ALUL 104c) .

The VPS 100 then encrypts a PIN request before sending it as a PIN request message (PRS) 172 to the user's mobile terminal 140. Optionally, other security enhancing data may also be included in the data that is encrypted. Receipt of the PRS launches the ALU 141 as the messages employ J2ME push technology which can automatically launch an application on the mobile phone 140.

An exemplary personal mobile terminal 140 that will allow the system to operate is a mobile phone that supports a mobile information device profile (MIDP-2.0) as specified in the Java community process standard JSR118, connected limited device configuration (CLDC-I.0) as specified in Java community process standard JSR30 and wireless messaging API (WMA 1.1), as specified in Java community process standards JSR 120. An exemplary phone that complies with these standards is a Nokia 6230. The application is written in J2ME-JSR68 and the PRS can be a GSM SMS message as described by the ETSI organisation in GSM 03.40 and GSM 03.38.

The SMS message is encoded in Protocol Description Unit (PDU) mode, in which a destination port number can be assigned in addition to the destination mobile phone number so that the application can be registered on a specific port number.

Accordingly, once the program is launched, it decrypts the PRS 172 with the user's public key which is stored in part of the program and displays a payment summary including at least the amount of the payment to the user.

The user satisfies themselves that the payment details are correct and enters their account PIN. The ALU then encrypts the account PIN with the public key and payment summary. Optionally, other security enhancing data may also be included in the data that is encrypted. A PIN transport message (PTM) 173 including the encrypted PIN and payment summary is sent to the VPS 100.

The VPS 100 now needs to translate the PIN from the user private key to the merchant key and to generate a payment request message (PRM) . To do this, the encrypted user data is retrieved from user list 104b. The encrypted merchant key is retrieved from the merchant list 104a and the encrypted user private key is retrieved from the ALU list 104c. These two keys along with the relevant portions of the PIN transport message, the encrypted user data and the encrypted key used to encrypt the user data are sent to the HSM 108 which decrypts the keys that are encrypted with the LMK 109. The HSM 108 then uses these keys to process the encrypted portions of the PTM the encrypted user data including the account number or debit card number and card Track-2 data if this is required. The HSM then re-encrypts the PIN, the payment amount and the user data (typically the account number or debit card number and optionally the Track-2 data) with the merchant key to thereby form part of a payment request message that will subsequently be constructed by the virtual PIN PAD software 101 and sent to the merchant system 120 for forwarding to the existing payment network 160. It will be appreciated that the two keys, the encrypted portions of the PIN transport message and the encrypted user data are not exposed outside of the secure environment of the

HSM. Accordingly, the payment request message is securely generated and compatible to one generated in a conventional PIN PAD system.

Thus, once the PRM is received by the merchant system,

120, it can forward it to an existing payment network 160 as if it were a conventionally generated payment request message. The payment network response message from the existing payment network is returned to the VPS via the merchant system 120 which validates any cryptographic components thus, the transaction is authorised during the normal transaction flow of an online process.

Persons skilled in the art will appreciate that a number of variations can be made to the preferred embodiment that fall within the scope of the invention. For example, it is not necessary that the transaction be initiated by a web browser. For example, the transaction could be initiated over the phone. Further, alternative techniques may be used to issue the software to the mobile terminal for example, the ATM initiated method referred to above or by physically presenting the mobile terminal at a bank branch. However, it will be appreciated that the provisioning technique described herein is both secure and convenient to the user.

It will be appreciated that other programming languages could be used for the ALUs. For example, the application could be a .Net security application running in the windows mobile 2003 second edition for smart phones environment .

In the preferred embodiment, the provisioning web server 105 and the message gateway 107 are shown as being part of the virtual PIN PAD service 100. However, as indicated by dotted line 102, they could be provided independently of the virtual PIN PAD service 100 provided they are in data communication with the VPSW 101.

In further alternative embodiments, the user keys may be provided in an alternative manner, for example by using a key that was issued with the SIM by the telecommunications company or Bank (with the corresponding private key imported into the HSM 108) . Further, it may be possible to write the key into a secure area of the phone or the SIM. However, even in these embodiments, the authentication of the PIN will not occur on the SIM but will be performed by the existing payment network.

These and other modifications will be apparent to persons skilled in the art and should be considered as falling within the scope of the invention disclosed herein.

Claims

1. A system for secure authorisation of transactions comprising: a secure encryption/decryption device (SEDD) for processing a PIN transport message (PTM) received from a user mobile terminal, the PTM including a user entered personal identification number (PIN) and payment data both encrypted with a user public key, the SEDD processing the PTM to decrypt the PTM with the user's private key and re- encrypt with a merchant key as at least part of forming a payment request message (PRM) .

2. A system as claimed in claim 1, wherein the system comprises a transaction processor for receiving the PTM from the user mobile terminal, sending the PTM to the SEDD and subsequently forwarding the PRM.

3. A system as claimed in claim 2, wherein the transaction processor provides user data to the SEDD and the SEDD processes the user data to incorporate user data that identifies the user to the PRM.

4. A system as claimed in any one of claims 1 to 3, wherein the SEDD stores a secure encryption key and the system further comprises a data store in data communication with the transaction processor, the user's private key being stored in the data store encrypted by the secure encryption key, and wherein the transaction processor sends the encrypted user's private key to the

SEDD with the PTM whereafter the user's private key can be decrypted by the SEDD before being used to decrypt the PTM.

5. A system as claimed in any one of claims 1 to 4 wherein, the SEDD is configured such that there is no externally accessible function to decrypt data with the user's private key.

6. A system as claimed in any one of claims 1 to 5, wherein the SEDD is configured so that there is no externally accessible function to encrypt data with the user's public key.

7. A system as claimed in any one of claims 4 to 6, wherein the merchant key is stored in the data store encrypted by the secure key and the transaction processor sends the encrypted merchant key to the SEDD with the PTM and the SEDD decrypts the merchant key with the secure key to obtain the merchant key.

8. A system as claimed in claim 7 wherein, the transaction processor is configured to receive transaction data from a merchant system, the transaction data including user data that identifies the user, merchant data that identifies the merchant and payment data related to a transaction between the user and the merchant, the transaction processor being configured to send payment data to the SEDD together with the encrypted user private key retrieved from the data store on the basis of the user data, the SEDD decrypting the user's private key and encrypting the payment data with the user's private key whereafter it can be sent to a user's mobile terminal as a PIN request message (PRS) .

9. A system as claimed in claim 3, wherein the user data is used to retrieve other data relating to the user, that is required by the system to carry out one or more functions.

10. A system as claimed in any one of claims 1 to 9 further comprising at least one user mobile terminal configured to automatically decrypt and display payment data in response to receipt of the PRS .

11. A system as claimed in claim 10, wherein the user mobile terminal is configured to prompt the user to enter a PIN to approve the transaction following display of the payment data.

12. A system as claimed in claim 10 or 11 wherein the user mobile terminal is configured to generate the PTM in response to the user entering a user entered PIN.

13. A system as claimed in any one of claims 1 to 12, wherein the SEDD includes a key generation mechanism for generating user private and public keys.

14. A system as claimed in claim 3, wherein the transaction processor comprises a computer or computers running a program that causes the transaction processor to carry out the above functions.

15. A system wherein the user mobile terminal runs an authorisation program to be configured as claimed in any one of claims 10 to 12.

16. A system as claimed in claim 15, comprising a provisioning mechanism for providing the user public key and an authorisation program to a user mobile terminal.

17. A system as claimed in claim 16, wherein the authorisation program is individualised for the user by embedding at least the user public key in the code before being provided to the user.

18. A system as claimed in claim 16 or claim 17, wherein in order to function, the authorisation program requires entry of an activation code and the activation code is provided to the user independently of the authorisation program.

19. A method for secure authorisation of transactions comprising: providing a secure encryption/decryption device (SEDD) ; receiving a PIN transport message (PTM) from a user mobile terminal, the PTM including a user entered PIN and payment data both encrypted with a user public key; processing at least an encrypted portion of the PTM within the SEDD to decrypt it with the user's private key and re-encrypt it with a merchant key as at least part of forming a payment request message (PRM) for the merchant system that can be passed to an existing payment network.

20. A method as claimed in claim 19 comprising: storing the user's private key and merchant key are outside the SEDD encrypted with a secure key stored within the SEDD.

21. A method as claimed in claim 19 or 20 comprising generating the secure key within the SEDD.

22. A method as claimed in any one of claims 19 to 21, wherein the user's encrypted private key and the encrypted merchant key are each provided to the SEDD with the PTM and decrypted within the SEDD to enable processing of the PTM.

23. A method as claimed in any one of claims 19 to 23 comprising receiving transaction data from a merchant system including user data, payment data and merchant data and encrypting at least the payment data within the SEDD as at least part of forming a PIN request message (PRS) to be sent to a mobile terminal .

24. A method as claimed in claim 23, comprising decrypting the PRS at the mobile terminal with the user public key, and presenting payment data to the user for approval .

25. A method as claimed in claim 24 wherein, if the user approves the transaction, the user enters a PIN and the payment data and user entered PIN are encrypted with the user public key and sent as the PTM for processing by the SEDD.

26. A method of providing a security application to a user of a secure authorisation system, comprising: providing base code for carrying out at least one secure authorisation function; providing a public/private key pair; compiling the base code with at least the public key to form a user specific security application in which at least the public key is embedded; and providing the user specific security application to a mobile terminal of the user.

27. A method as claimed in claim 26, further comprising the base code with at least one of a serial number and an issuer number.

28. A method as claimed in claim 26 and claim 27 comprising, generating a provisioning key, encrypting it with an activation code and the encrypted provisioning key is embedded in the user specific security application in the compiling step.

29. A method as claimed in claim 28 comprising, encrypting the user public key under the provisioning key.

30. A method as claimed in claim 28 or 29 comprising activating the user specific application by providing the activation code to a user via a different channel by which the user specific security application was provided, the user entering the activation code, the security application decrypting the provisioning key on the basis of the activation code, decrypting the user public key with the provisioning key and generating a confirmation code in response to entry of the activation code using the provisioning key and, user providing the confirmation code to a validation means which activates the user if the confirmation code is correct.