WO2012123859A1

WO2012123859A1 - Transaction security method and device

Info

Publication number: WO2012123859A1
Application number: PCT/IB2012/051075
Authority: WO
Inventors: Peter A GARAY
Original assignee: Garay Peter A
Priority date: 2011-03-16
Filing date: 2012-03-07
Publication date: 2012-09-20

Abstract

A method and device are disclosed to facilitate a transaction that is secure even if the computing device it is conducted on is compromised. A human interface device transforms the entered information to a tamper-proof format, and transmits the tamper-proof information to the computer as if it would be entered in such form by the user. The information incorporated in the tamper-proof data would include the transaction data entered by the user and preferably a number used once to ensure that not even correctly authorised transaction can be repeated. This information would be made tamper-proof by cryptographic transformation. It can be verified that the transaction was made with the use of an individual device. In the preferred embodiment the device used is implemented in a form that may conveniently carried on the person.

Description

TRANSACTION SECURITY METHOD AND DEVICE

TECHNICAL FIELD

[0001] Being able to conduct transactions online is a basic requirement in the 21st century. Such transaction typically involves a client computer, where the user initiates a transaction and a remote computer, that receives the instructions and acts upon it. A transaction could be anything wherein in the real or offline world a signed piece of paper would alter state of affairs in some way. An example where most people expect and are prepared to take precautions is a bank transfer. In real world is possible to forge bank transfer documents, but the physical security measures makes it hard to use forged documents because there is a significant chance of being caught. Forgery and specially the use of forged documents is also labour intensive. While forgery exist in the real world it is not frequent and people are reasonably protected using common sense.

[0002] Online transactions are much easier to forge. Data required to forge can be collected automatically, so it can be done profitably on a large scale. The forgery can be conducted remotely. The detection of online forgery activities is difficult even for IT experts, consequently the chance of detection before the damage is done is low and the chance of apprehension is even lower.

[0003] The literature of methods to conduct online fraud is huge, there is a computer security industry grown out of the need fighting it. The methods are getting more and more advanced (for a brief overview, see online article http:// www.securityweek.com/evolution-proxy-trojans). While there are protective measures to pro-actively increase computer security in order to prevent malicious activity, most security products are reactive: once a type of attack is known, there is a mechanism put into place to prevent it. Between the two there is a window of opportunity for criminal interference that can affect millions . It has been noted by many that conducting transactions on a personal computer is insecure, because practice shows that personal computers can be remotely tampered with. There are methods that attempt to create secure environment for transaction, but such methods usually can be circumvented once it is in use and can be reverse engineered. An example of such a solution is described in US patent application publication US 2011/0047305 Al, where security is enhanced by bypassing the original drivers processing user input (before it is intercepted by common spyware).

BACKGROUND ART

[0004] There are two types of solutions commonly used to deal with this problem. One solution is to use a secondary independent method (a secondary communication channel) to confirm transactions. Where a bank requires a text message (SMS) on a mobile phone to confirm an online transaction would be such a system. This would require an attacker to be able to forge both parts of the transaction to be successful. Another example of such an arrangement is described in US patent application publication 2002/0169988 Al. With the growing popularity of smart phones, that are in fact becoming general purpose networked computers, and appear to become target of same kind of attacks, it is now quite likely that successful attacks could be launched on the basis of both equipment being compromised at the same time. This is not an unlikely scenario as multi- platform attacks are known to be feasible. Such attack would result in both devices being compromised by the same attack. The second type of protection is based on the use of an additional equipment that needs to be present to conduct a transaction, such as smart card or fingerprint. Examples of such arrangements are disclosed in US patents 5721781, 7254561, 6959382 and patent application publications 2010/0174653 Al, 2007/0106895 Al. Done correctly, these kinds of devices can ensure that their presence is required to conduct a transaction. However, it is still possible to change the transaction before it is authorised by the device by manipulating the equipment the security device is connect to and to produce a forged document in place of the document the user intended to produce.

[0005] There are even specific devices to conduct authorisation of presented documents by signing a document that can be reviewed before signing and/or encrypting. These devices have an individual key that is used to compute the result of a cryptographic operation on the text. This proves that the operation was done on the individual device (for cryptographic background see for example Schneier: Applied Cryptography Second Edition ISBN 0-471-11709-9). An example of such device is described in US patent application publication 2002/178125 Al. Such devices - assuming they are used correctly and are physically protected - are sufficiently secure for the purpose but are too bulky for mass adaptation, still tied to some specific software on the computer and requires an extra step of visual verification.

[0006] To be acceptable for mass use a security device should be small enough to be carried on the person at all times and cheap enough for mass adaptation. It should also be independent from the system used to conduct the transaction, so it can be used with any of the multiple computing equipment a user would wish to utilise for the purpose of conducting transactions and should be secure even if the equipment used is compromised and the attacker knows what kind of security measure is taken.

DISCLOSURE OF INVENTION

[0007] To facilitate a transaction that is secure - even if the computing device it is conducted on is compromised - a human interface device (HID), [a device that allows user to enter information to a computer,] should be used to enter the key details of the transaction and the human interface device makes the entered information tamper-proof, and transmits the tamper-proof information to the computer as if it would be entered in such form by the user. A preferred embodiment of tamper-proof information would be the transaction data entered by the user, preferably a number used once (NUO) to make each transaction message unique, and a digital signature. An other preferred embodiment would be the encrypted transaction data entered by the user, preferably a NUO, and preferably a digital signature. The purpose of the NUO is to guard against replay attacks (a replay attack is where an attacker once convinced the user to transfer a certain amount of money, it repeats the transaction to gain further money). With a NUO, such as a transaction counter or time stamp, the remote system can ensure that not even correctly authorised transaction can be executed twice.

BRIEF DESCRIPTION OF DRAWINGS

[0008] FIG. 1 shows a security device that would be inserted between a USB keyboard and a USB port on a computing device.

[0009] FIG. 2 shows a credit card sized security device with a numeric keypad that would connect to the computing device, preferably via wireless means, such as Bluetooth.

MODES FOR CARRYING OUT THE INVENTION

[0010] The security method described works with any kind of HID that allows the direct input of transactions details, such as a scanner, a voice response system, an optical character reader or any other input method known in the art, a keyboard would be the most commonly used device. Direct input is where transaction data is entered by some human action, such as typing or scanning, as opposed to just confirming transaction details that are presented by a computing device. The keyboard can be a full keyboard, or - in case of the transactions to be protected only require numeric information - a numeric keypad. The device may use any kind of alphanumeric entry method know in the art. An example would be the text entry using numeric keys, as commonly used on mobile telephones. The full keyboard would be the preferred device in applications where the computing equipment is utilising a separate equipment, such as commonly used in desktop workstation environments. For equipment that have an integrated method of entering alphanumeric information the choice between a full or numeric keyboard depends on the nature of transaction; for home banking type of applications a numeric keypad may be more convenient. Secure transaction can be conducted for example on a smart mobile phone or a tablet computer using a small numeric keypad 7 that connects to the mobile. The connection can be any connection allowing a keyboard to be attached to a mobile or a tablet, such as USB or Bluetooth. For a particular embodiment a Bluetooth based device for occasional personal use may be implemented on a keypad 7 device with the approximate size of a credit card and the thickness allowing it to be stored in a wallet among credit cards. The security device in such embodiment is part of the HID. Any powering method known in the art can be used, given the expected low use and to avoid user service (such as replacing miniature batteries or connecting a charger to such a small device) a solar cell 10 based power solution or other contactless recharging technology may be advantageous.

[0011] Small size is not the essence of the invention. The important thing is that device is always under the control of the user. For mass adaptation small size is advantageous, because it can be an item that a person would normally always carry, such as a keyring, a wallet, a necklace, a watch or like items.

[0012] In an other preferred embodiment the security device is a dongle connected between an existing HID 2 and the computing equipment 1. This way the device could be made the size of a usual„pen drive" or„thumb drive". This allows the security device to be carried on the person all the time, for example on a keyring using a ringlet 6.

[0013] Where a full keyboard is used, the connection between the security device "dongle" and the computing equipment does not have to be the same as the connection between the "dongle" and the original HID. However, at the time of the invention, a dongle between a USB keyboard and a USB connector has the advantage that in such arrangement the "dongle" can be "hot plugged" (installed, removed and reinstalled during operation). On the other hand, due to the nature of Bluetooth protocol - while possible -, it would be complicated to insert a dongle between a Bluetooth HID and the computing equipment. For a tablet or other devices without keyboard or keypad the provision of a security device may have the additional benefit of providing a keyboard or keypad 8 for general use. A set of desktop devices that could contain the security device would be a keyboard, optionally a mouse, connected to the computing system via the keyboard (so it can be disabled during "active" mode, see below). Preferably such an arrangement would contain the security device on a small removable element so that it can be kept with the person at all times.

[0014] The security device appears as a HID (typically a keyboard) on the interface 3A to the computing device once connected. It acts as a host to the HID via the interface 3C, passes on the characters entered on the HID connected to it 2 or entered on the HID integrated within 8. Once a transaction is commenced and the entry of protected data starts, the security device takes an active role. The security device may be switched to this "active" mode by the computing device or preferably by user action. The switching may be performed by a button or switch on the security device 5 (or 4 and 5 in case the device has two active modes). Where the security device is attached to an existing keyboard, a key combination may be used to switch between the modes. It is preferable to have visual feedback of the mode. This may be a coloured light 4 (or built into the switches 4 and 5 when the device has two active modes) or an icon on the security device. Where the security device is attached to an existing keyboard, the feedback maybe provided by the use of the status lights on the existing keyboard, preferably flashing those lights. In this mode the security device collects the data entered. In the mode the user should enter the required data without taking any action affecting the operation of the computing equipment (such as switching between applications or entering other data). In certain embodiments all HID devices of a computing configuration may be connected to the computing equipment via the security device. Such embodiment could be similar to the device shown on FIG. 1, having two host type connections 2 below each other. This way the other HID can be made inactive while the security device operates in active mode, aiding the user during the transaction. In case the device is used in an application, where the transaction data can be sent in plain text and security is provided by a digital signature, the typed characters may be passed on to the computing device to provide user feedback. Where the transaction data should be encrypted for additional privacy, the typed characters are not sent to the computing device. User feedback may be provided by a display 9 giving feedback to the user. Such display may be limited to show the last few characters, especially if it is on a dongle type device, where it may be put on the area shown on FIG. 1 to contain the other electronics 3. Once all information needed to complete the transactions - as signalled by the host or preferably the user - is entered the security device calculates the signature, and/or - in case of encryption used - encrypts the message. The result of this is transmitted to the computing equipment as if it would be typed by the user. It is preferred that the user is in charge of changing between the bypass and data entry mode to avoid the possibility of malicious software attempting to manipulate the user and the security device to enter different transaction details even if at present it seems implausible to successfully launch such kind of attack to create a forged document with a required content. However, it may be plausible to frustrate the user to eventually abandon the use of the security device and to revert to insecure solutions.

[0015] The signature and/or the encryption is preferably conducted by using public key encryption by an embedded microcomputer 3B that preferably integrates 3 the interfaces as well, such as the two USB interfaces 3A 3C on the dongle style solution. The use of public key encryption allows continued use of the device even after a temporary compromise at the remote system. The use of the device and method provides solution to the problem of the transaction being completed on a client that might be under the control of an attacker. It does not enhance the security on the remote device. Using a secret shared key for the encryption or signature of the transaction would render the security device useless once the remote system is compromised. Using public key cryptography the security device can be used again after the compromised remote system has been restored to guarantee that forged documents cannot be created by using the information gained from the compromised remote system. If the additional encryption using a key of the remote system is required, the device obviously needs a new key from the remote system after a compromise and after this is provided, it may continue to use its private key.

[0016] Before the security device can be used, the remote system needs to associate the unique encryption key with the user who will use the particular device to conduct transactions. Where only signature is provided by the encryption device, the unique public key can be made available via any one-way communication. The public key can be made available as a two dimensional barcode, so it can be made known securely to the remote server without the requirement of the device being present, for example, via mail. The public key may be provided on a separate media. Alternatively, the device may make its public key available as a file on a block device (where a USB or similar interface is already utilised), or as a transferred file (in case where the device utilises a Bluetooth or similar interface).

[0017] If there is a need to ensure that information is kept secret from other recipients of the public key an additional encryption step may be performed. Where such encryption is used, this would require a key, preferably the public key of the remote system to be placed on the device. This key may be placed on the device at manufacture, or preferably installed on the device when given to a customer. For this the security device should be in initialisation mode. Initialisation mode might be entered by any known means, commonly pressing a particular key combination at power-up. In the preferred embodiment the initialisation mode is entered via detecting the device being open. Optionally, the device may prevent its re-initialisation by re-opening it and collecting private information, possibly by physical or software destruction of the drive. Such arrangement might be useful to prevent tampering with the device after theft.

[0018] There are other uses beyond securing a transaction between two entities. For example, it is possible to use the same device to encrypt transactions with different remote systems. If an additional encryption step is performed with a key related to the remote entity to ensure that information is kept secret from other recipients of the public key, the user must select the entity it wishes to communicate with. This would select the appropriate key for the encryption. Selection mode could be entered via a certain key combination or certain length of button press. The initialisation process for such uses must then allow multiple keys to be installed in parallel.

[0019] The described device and method is safe and can be put into practice as described above. But there are two practical issues with the implementation of public key encryption in a device disclosed above. Firstly - at the time the application - low cost micro-controllers are unable to do the calculations required for public key encryption in real-time. Secondly, the resulting data is long. Assuming the maximum simulated typing rate of 20 characters per second and depending on the coding used, the commonly used 1024 bit key-length the data would take about 9 seconds to transmit, and with a view on long term security using 4096 bit key-length, the transmission would take over half a minute. Where transaction data is entered in bulk, such times are unacceptable.

[0020] Online (for example, banking) transactions are usually conducted by first logging in, where the user gets identified. Then one or more transactions (such as money transfers) are initiated. The security device could have two separate operating modes accordingly.

[0021] For each login, a random array of bytes can be used. Preferably a NUO would be appended to this array to prevent reuse. This array would be encrypted using the individual private key of the device. A high quality random number generator at manufacturing may be used to initialise the equipment with sufficient random data as the security of the device is now depending on using an unpredictable random array for each login. The encryption of the array can be precomputed. The encrypted array is only transmitted at the first operation of a transaction, commonly at login. Encryption and/or signature of data would use this array in full or in part as a key or a seed to a faster algorithm(s).

[0022] One or more transaction would be processed as follows: [0023] The password entry mode has to be activated by the user once the data entry pointer (cursor) is in the password entry field of the login screen.

[0024] It is preferable that the password is not passed on by the security device to the computer as typed. A place-holding character might be sent, as such solution is often seen when passwords are entered. Once the password entry is finished, the device sends a string that encapsulates (a) the encrypted array, (b) the password encoded with part or whole of the random data used as a key and preferably (c) a hash to authenticate the login sequence and optionally other elements of the message to ensure that message has sufficient randomness even if the password is week.

[0025] Transactions usually are performed using forms where several fields have to be filled in to conduct a transaction. The alteration of some fields would allow fraud to be committed, for example destination account number or transfer amount. Such fields are critical fields. These fields should be filled by the user in signing mode. This mode is activated by the user when the data entry pointer (cursor) is in a critical field.

[0026] It is preferable that user gets feedback of the data typed. Where no other feedback mechanism exists on the device the critical data might be passed on by the security device to the computer where it gets displayed. Once the critical data entry is finished, the device erases the characters sent as a feedback and sends a string that encapsulates (a) the critical data, (b) a hash to authenticate the critical data and preferably (c) a NUO which might also be authenticated via a hash. In the alternative, a string could contain (a) the encrypted critical data and preferably (b) a NUO which might also be authenticated via (c) a hash or by encryption.

[0027] The authentication hash is preferably a hash that is able to withstand all known types of cryptanalytic attack. As an example, the SHA-2 hash algorithm may be used. The hash would be calculated on a given part of the random data and the critical data entered, optionally including the NUO. Without knowing the random data the hash cannot be reproduced by an attacker who would alter the content and the verification on the remote transaction site would fail.

[0028] Data encryption could use any encryption algorithm that is able to withstand all known types of cryptanalytic attack and produces limited length blocks, preferably stream ciphers, that produce the same length output as an input. Where only the password is encrypted, part of the random data may be used as a one time pad.

[0029] After the cryptographic operation, the output has to be encoded using a codeset that is expected from an input device. Standard input devices use scan codes (codes depending on the position on a keyboard) that are converted to character codes (as labelled on the keyboard) by the operating system depending on the language settings. This means that most codes would appear as different characters when using a different language operating system. A possible solution is to use a codeset that is identical on all keyboard layouts - the numeric area. This solution makes the result unnecessarily long. An other solution would be to set up the device to be aware of the language (and consequently the keymap) used. This solution would complicate the device and inconvenience the user. The preferred solution is to prefix the first transaction message with some fixed scancodes. The receiving application can establish what keymap is in use and can decode the messages accordingly. This means that the device can be moved between machines with different languages without any action required from the user.

[0030] It may be advantageous to make matching markings on the entry field and on the activation button, for example by colour, where a button or a key is used to activate a special mode. The device may continue to have multiple uses with an appropriate user interface, for example a 2d joystick to navigate between functions displayed on the device as seen on such small equipments as portable music players. [0031] An added layer of security can be achieved by the user evidencing who she or he is by using - for example - a biometric identification device such as a fingerprint reader or any other biometric scanner to be able to operate the device.

[0032] There are several uses for such a device beyond secure log-in and securing filling out a form. A variety of "transactions" could benefit from the procedure described. It may secure access to any password protected computing resource. It can be used to ensure the identity when authenticating via secure login. For such application the data entered might be a password, but the computing system would verify not just the password but also the NUO together with the digital signature. Following this method access requires both the password and the device. Beside of trade of valuables it can also be used in public administration, securing polling and gaming. It can also safeguard online identity.

[0033] The invention has been described with considerable details and including reference to preferred versions thereof. Other implementations and versions may be feasible. The scope of the appended claims are not limited to the description or to the preferred versions described above. The scope of the invention is defined by the claims that follow.

Claims

What is claimed is:

1. A method for conducting a transaction by electronic means using a human interface device (HID) and an information technology (IT) system, the method comprising the steps of:

(a) setting up the HID with a unique cryptographic attribute;

(b) setting up a component of the IT system with a cryptographic attribute that corresponds to the said HID;

(c) entering transaction data on the said HID;

(d) the said HID inserting into the data flow to the said IT system cryptographically transformed data using the HID's unique cryptographic attribute that cryptographically proves that transaction data was processed by the said unique HID;

(e) a component of the IT system verifying that data was processed by the said unique cryptographic attribute as a requirement to process the transaction.

2. The method according to claim 1, wherein step (d) includes insertion of number used once into the said data flow that makes each transaction unique and step (e) also verifies the uniqueness of each transaction.

3. The method according to claim 2, wherein the said number used once is a counter that is maintained during the life of the said device.

4. The method according to claim 2, wherein the said number used once is derived from the time and date.

5. The method according to claim 1, comprising the additional step of:

(f) using the said HID for untransformed data entry when not used to conduct step (c) and (d).

6. The method according to claim 5 wherein the said HID or part of the HID containing all the data contained in the said HID is kept physically secured when not used to conduct steps (a), (c), (d) or (f).

7. The method according to claim 2, wherein the said inserting into the data flow at step (d) contains a set of codes that allow the said verifying at step (e) to do the verification can be done without the knowledge of what keymap is in use at the receiving point of the said IT system .

8. The method according to claims 1-7, wherein the unique cryptographic attribute in step (a) incorporates a unique private key and the cryptographic attribute in step (b) incorporates the corresponding public key.

9. The method according to claim 8, wherein the transformation in step (d) incorporates encryption of the transaction data using the said private key.

10. The method according to claim 8, wherein the transformation in step (d) incorporates encryption of an array containing random data using the said private key and using the random data for a second type of cryptographic transformation on the transaction data.

11. The method according to claim 10, wherein the second type of cryptographic transformation is encryption using the whole or a part of the random data as key.

12. The method according to claim 10, wherein the second type of cryptographic transformation is creation of a cryptographic hash using the whole or a part of the random data as seed.

13. The method according to claim 8, wherein the step (a) incorporates the storing the public key of an IT system component and the transformation in step (d) incorporates encrypting the data with the public key of a computing entity.

14. The method according to claim 13, wherein the said HID can select between multiple IT system components to conduct transactions with.

15. The method according to claim 8 wherein the result of a transaction is access to computing resource.

16. A human interface device (HID) set up with a unique cryptographic attribute and operatively coupled to a computing equipment (such as PC, a tablet, a smartphone or like device) characterised by one or more operating mode in which the HID transforms the entered data using at least the said unique cryptographic attribute - evidencing the data entered and that the transformation was performed by the said individual HID -, and transmits the encoded result of the transformation to the said computing equipment.

17. A HID according to claim 16, wherein the said transformation incorporates a number used once evidencing that said result of transformation has not been transmitted before.

18. A HID according to claim 17, wherein the said number used once is a counter maintained for the life of the device.

19. A HID according to claim 17, wherein the said number used once is a value derived from the time and date.

20. A HID according to claim 16, wherein the said unique cryptographic attribute incorporates a private key and the said transformation incorporates encryption using the said private key.

21. A HID according to claim 16, wherein the said unique cryptographic attribute incorporates a private key unique for each HID and the said transformation incorporates encryption using the said private key.

22. A HID according to claim 21, wherein the said encryption encrypts at least the data entered.

23. A HID according to claim 21, wherein the said encryption encrypts at least an array containing random data, the random data being used for a second type of cryptographic transformation on the the input data entered.

24. A HID according to claim 23, wherein the second type of cryptographic transformation is encryption using the whole or a part of the said random data as key.

25. A HID according to claim 23, wherein the second type of cryptographic transformation is calculation of a cryptographic hash using the whole or a part of the said random data as seed.

26. A HID according to claims 16-25, wherein the HID is connected to a known prior art input device to receive input from a user and is connected to the computing equipment in place of the said known prior art input device.

27. A HID according to claim 26, wherein the known prior art input device is a hotplugable keyboard, keypad or other device that is used to enter character sequences, such as optical recognition device.

28. A HID according to claim 27, wherein the said HID controls one or more other HID devices that may interfere with the entry of data.

29. A HID according to claim 27, wherein the said device has means to be attached a person or to an item normally carried on a person.

30. A HID according to claims 16-25, wherein the said HID is a keypad.

31. A HID according to claim 30, wherein the said keypad has approximate physical dimensions of a credit or like card that commonly fits into a wallet.

32. A HID according to claim 30, wherein the said keypad is attachable to a person as a wrist watch.

33. A HID according to claims 16-25, wherein the said HID provides feedback of the data entered.

34. A HID according to claims 16-25, wherein the said unique cryptographic attribute also incorporates one or more public keys and the said transformation incorporates encryption using a selected public key.

35. A HID according to claims 16-25, wherein the said unique cryptographic attribute cannot be retrieved from the HID.

36. A HID according to claims 16-25, wherein the said encoded result contains a set of codes that allows the decoding of the said transmitted result regardless of the keymap used by the said computing equipment.