Description VERIFYING PRESENTED DATA THROUGH STREAMLINED

REVIEWING

Technical Field

[0001] Mitigating the threats of malicious software (e.g. Trojan horses), malicious firmware (e.g. cracked TPM) and malicious hardware (e.g. hardware key loggers) on electronic transactions. Background Art

[0002] Dl : WO 02/01520 A (DEVICE FOR CARRYING OUT SECURE

TRANSCηONS IN A COMMUNICATIONS NETWORK) 3 January 2002

[0003] D2: PCT/IB2004/050628 (SECURE PIN ENTRY USING PERSONAL COMPUTER)10 May 2004 Disclosure of Invention Technical Problem

[0004] Given a trusted computer, e.g. a micro-processor based smartcard, with limited I/O capabilities and an un-trusted terminal, e.g. a PC, with rich FO capabilities.

[0005] It is desired to realize a transaction making environment made of the un-trusted terminal and the trusted computer such that the resulting transaction making environment would benefit from the rich FO capabilities of the un-trusted terminal, yet the environment would be considered secure and trusted.

[0006] Since the un-trusted terminal was involved, the result of the above combination would normally be an un-trusted environment.

[0007] To illustrate this problem by an example: a transaction making environment made of a PC connected to the Internet, which is the un-trusted terminal, and a microprocessor-based smartcard, which is the trusted computer.

[0008] The PC, has the following rich FO capabilities :

1. Presenting transaction data on the display of the PC

2. Entering user PIN using the keyboard of the PC

[0009] At the time of writing, the smartcard is the most trusted element in the IT industry, but it is limited in that it can only communicate through its electronic interface. The user cannot interact directly with this electronic interface.

[0010] When it is desired to make an Internet transaction, such as bill payment, the following process would normally occur:

1. The transaction data, such as bill amount, beneficiary institution, date of the bill...etc are delivered to the PC over the Internet. The mentioned transaction data are usually delivered to the PC over an SSL connection, i.e. digitally

signed by its sender, to keep its integrity while being transferred over the Internet.

2. The PC presents the received data among with the result of the integrity verification to the user on the display of the PC.

3. The user would review the result of integrity verification and all the transaction data on the PC's display and would decide if he wants to continue to commit the transaction or not.

4. If the user decides to commit the transaction, he inserts his smartcard into the reader.

5. The PC prompts the user for his smartcard PIN.

6. The user enters his PIN on the PC's keyboard.

7. The PC sends the PIN entered by the user to the smartcard among with the transaction details.

8. The smartcard verifies the PIN and if the PIN is correct, the smartcard signs the transaction details using the private key.

9. The smartcard sends the signed transaction back to the PC.

[0011] If the PC is considered un-trusted, such as a PC in an Internet Cafe or a computer infected with malicious software such as Trojan Horses, then the following two problems can occur:

1. Malicious software running on the un-trusted PC can manipulate what is presented to the user on the display of the PC (i.e. in step 3), such that it would contain false transaction data that would deceive the user

2. Malicious software running on the un-trusted PC can capture the PIN entered by the user on the keyboard of the PC (i.e. in step 6), and use it to sign fraudulent transactions using the user's smartcard while it is still inserted in the smartcard reader of the PC.

[0012] The user will not be able to tell if there is malicious software in action or not.

[0013] At the time of writing, even sophisticated anti- virus software cannot detect all types of Trojan horses, because the new Trojan horses are polymorphic: i.e. they change their characteristics by time.

[0014] The example above shows an example of a typical transaction making environment made of an un-trusted terminal (a PC) and a trusted computer (a secure microprocessor-based smartcard). The resulting environment is un-trusted, because the transaction making process relied on un-trusted I/O capabilities of the un-trusted terminal, namely:

1. The display of the un-trusted PC

2. The keyboard of the un-trusted PC

[0015] This trust problem is critical, especially in the e-signature field, because if it is not

possible for the user to have a trusted transaction making environment, then the user should not be held liable for the electronic transactions committed using his private key.

[0016] There are two categories of solutions in the prior art that mitigate this technical problem:

1. Solutions that attempt to equip the trusted computer with all necessary user I/ O capabilities such that the rich user I/O capabilities of the un-trusted terminal would not be used altogether during making the transaction. Dl in the prior art represents this category.

2. Solutions that attempt to make the un-trusted terminal to be trusted to a sufficient extent during the transaction making process. D2 in the prior art represents this category.

[0017] Problems in the prior art solutions:

1. Solutions in Dl does not scale well with the size of the transaction data that needs to be displayed, because the display that comes with Dl needs to be small in order to keep the size of Dl appropriate and also keeping the cost low. It is not possible for example to review a long dozen-field form on a small LCD display, even on the standard 16x2 character LCD screen.

2. Solutions in D2 ensure trust only when the underlying hardware and firmware is trusted, such as a user's own computer at home or the user's own notebook. This is not the case in for example public computers in Internet Cafes and PC- based Point Of Sale terminals in small shops. Because the Internet Cafe administrator can eventually update the firmware of the PC with malicious firmware or even attach a piece of malicious hardware to the PC. The same problem applies to the PC based POS in a shop: the shop clerk can update the firmware of the PC with malicious firmware downloaded from the Internet that attempts fraudulent transactions after the wishes of its installer, i.e. the malicious clerk.

[0018] None of the solutions in the prior art ultimately solve the technical problem posed: "Realizing a transaction making environment consisting of an un-trusted terminal and a trusted computer, such that the resulting transaction making environment would benefit from the rich I/O capabilities of the un-trusted terminal in order to realize scalability in the size of the transaction data, yet without sacrificing that the resulting transaction making environment would be trusted"

Technical Solution

[0019] The current invention can be viewed as an improvement to the known cryptographic devices such as smartcards, smart tokens, HSMs, cryptographic smartcard

readers, smartcard enablers...etc

[0020] The current invention makes the cryptographic device fulfil all the trust without requiring any trustworthiness in the external world, e.g. the un-trusted terminal needed to fulfil the transaction, such as the PC.

[0021] The current invention is also scalable and compact: it does not require a large LCD screen to be embedded in the cryptographic device. Instead, it relies on the rich user I/ O capabilities of the un-trusted terminal, such as the rich display of the PC used to prepare and fulfil the transaction.

[0022] Figure 1 depicts an embodiment of the current invention, showing the essential physical components: a pointing means, which is an optical pointing sensor in this case and an output device which is a small LCD module in this case.

[0023] The embodiment shown in Figure 1 uses a wireless proximity interface, based on the ISO 14443. This opens the possibility for using the token in POS and ATM environments also.

[0024] For making a transaction, the following process takes place:

1. The un-trusted terminal (i.e. the PC) is used to prepare the transaction

2. The user decides that he wants to commit the transaction

3. The user holds his pen-shaped token near the proximity coupling pad

4. The PC detects the token in proximity and sends to it the transaction details

5. The token verifies the integrity of the transaction data

6. The PC launches an emulated display to present on it what would the token display if it had a large display as the emulated display

7. The token reports to the PC the displacement of the pointer, based on its embedded pointing means

8. The PC shows the pointer on the emulated display, as a rectangle of dimensions that match the resolution of the LCD screen that is embedded in the token. This rectangular pointer is called "window pointer" because it is window shaped.

9. The token presents on its embedded LCD screen, from its internal memory buffers, the portion that should be identical to what is displayed in the window pointer on the un-trusted emulated display. This step occurs without influence from the un-trusted terminal, because it is driven (i.e. controlled by) the token itself.

10. The user compares by his eyes what is in the window pointer on the un-trusted emulated display to what is displayed on the embedded LCD screen of the token, if they match then there is no malicious activity that tampered this portion in the transaction data.

11. The user changes the position of the pointer, via sliding the token on the

proximity pad

12. Steps 7 through 11 are repeated a few times until either the comparison fails indicating that there is a problem and the user should not proceed with committing the transaction, or all the comparison(s) succeeded supporting the user to believe that there is no malicious activity trying to tamper the transaction and it is safe to proceed with committing the transaction.

13. The user uses the pen-token to move the pointer to the "<SIGN>" virtual button, and taps the pen-token in order to press it. It is important to note that the pen-token does not rely on the un-trusted terminal to know the position of the pointer or whether it is on a virtual button; the token relies on its internal buffers for doing this.

14. The pen-token now switches to the biometrics entry mode, where the pointer movements are not reported to the un-trusted terminal.

15. The user would use the pen-shaped token to make his hand- written signature. The token would not report to the un-trusted terminal these pointer movements in order to keep the user's biometric data secret.

16. The pen-token would verify the entered handwritten signature, and if the comparison succeeds, it would use the private key to sign the transaction data.

17. The signed transaction data is secure data, because the signature preserves the integrity. The signed data can now be transferred to the un-trusted terminal.

[0025] Secure PIN entry can also be realized using the current invention, in addition to or instead of the biometrics authentication.

[0026] We present here two variations of the secure way for secrets entry on the trusted computer using the current invention. Both variations rely on showing the user on the trusted output device a secret mapping of the entry keys or entry buttons.

[0027] The first variation is when the mapping represents scrambling of entry keys. The user would then use the keyboard of the un-trusted terminal to enter the corresponding keys.

[0028] Any malicious software on the un-trusted terminal that captures keystrokes (even hardware key loggers) will not be able to know the secret key that is actually intended by the mapped keystroke.

[0029] The second variation is when the mapping represents entries of masked buttons shown on the Emulated display; i.e. when the user points to a virtual button on the Emulated Display, its intended value is presented on the Trusted Output of the trusted computer. The user can scroll through the virtual buttons on the Emulated display to know which virtual button corresponds to which key entry; then the user would click on the virtual button that corresponds to the entry he intends and repeat this process as

much as needed to enter whatever secret data he wants to securely enter into the trusted computer. [0030] The un-trusted terminal cannot get these securely entered data, even though the FO capabilities of the un-trusted terminal were involved during the described secrets entry process. [0031] Figure 2 depicts the essential physical and logical components of the resulting transaction making environment. The shown adapted Trusted Computer represents the main product of the current invention. [0032] The dotted arrows represent logical relationships between components as follows:

1. Logical relationship between the Emulated Display and the Virtual Display: this emphasizes the fact that in the data verification mode, what is displayed in the Emulated Display should be similar to what is in the Virtual Display of the trusted computer when there is no malicious activity on the un-trusted terminal affecting the transaction.

2. Logical relationship between the Virtual Display and the Trusted Output: this emphasizes that in the data verification mode, the Trusted Computer presents on the Trusted Output a portion of what is displayed in the Virtual Display (actually, it is the portion pointed to or marked by the pointing means of the Trusted Computer)

3. Logical relationship between the Trusted Pointing and the Virtual Display: this emphasizes that in the data verification mode, the Trusted Computer keeps track internally of where the pointer is on the virtual display

Advantageous Effects [0033] Provides a uniform, terminal independent, way for the user to discover if the terminal is attempting to make malicious transactions [0034] Not only discovering malicious activities, but also aborting. No transaction can ever be committed without the aware consent of the user on what is actually going to be committed. [0035] As a result, putting the liability of the electronic transactions on the user becomes fair, because the user will be aware of every transaction being committed and no software or firmware or hardware on the un-trusted terminal can maliciously commit transactions without the user's awareness and consent to what is being committed. [0036] Prevents the user's secrets from being tapped by malicious terminals or malicious transaction making environments [0037] Prevents the user' s biometric data from being tapped by malicious terminals or malicious transaction making environments [0038] Eliminates the costs required to make and show that the transaction terminal is trust

worthy, because using the current invention, the user needs to trust his cryptographic device only (i.e. the trusted computer), which is based on the current invention. [0039] The current invention can be implemented such that it relies on components that are already produced in huge mass production, such as optical sensors to be used as the trusted pointing means; Optical sensors are already mass produced for the purpose of manufacturing optical mice. The optical sensor not only satisfies the pointing means requirement of the current invention, it also brings the biometric factor in multiple embodiments of the current invention, such as the hand-written signature capturing.

Brief Description of the Drawings

[0040] Figure 1 : a diagram of a pen-shaped token embodiment of the current invention, showing the following components:

1. The pen-shaped advanced smart token, which is the inventive trusted computer.

2. An un-trusted PC, which represents the un-trusted terminal

3. Display of the un-trusted PC, which represents the rich display of the un- trusted terminal, because a typical PC display is of much higher resolution than an embedded LCD screen for example

4. Emulated display; because it is running on the un-trusted PC, it is considered un-trusted

5. The embedded optical sensor, which is the chosen pointing means in this embodiment

6. The "window pointer", a rectangular shaped pointer representing what should be displayed on the trusted output device of the smart token.

7. The embedded trusted output device, which is a small LCD module in this embodiment

8. An optional right-click button, enables the smart token to function also as a general purpose pointing device for the PC, if ever needed

9. A special pad: both powers up the smart token wirelessly and acts also as a communication channel between the PC and the smart token. The ISO 14443 standard is one possible implementation for this technique

10. The USB cable for the pad. The USB brings both power and communications for this proximity coupling pad.

11. A virtual button, such as "<SIGN>" or "<CANCEL>", the user brings the pointer on it and taps the token in order to press the virtual button. The token has internal representation of what should be on the Emulated display, so it does not rely on the un-trusted terminal; it rather relies on its internal buffers.

[0041] Figure 2: is a block diagram showing the essential physical and logical components

of both "A) The Trusted Computer" and "B) An Un-trusted Terminal". Figure 2 also shows some important logical relationships between the different components (represented by dotted arrows). [0042] The components of "A) The Trusted Computer" :

1. The controller, e.g. a micro-controller, or a micro-processor and memory, or even a logical controller implemented on an existing micro-controller or micro-processor

2. Virtual Display, a logical component representing the memory buffer(s) holding the data which the Trusted Computer would have wanted to display if it had a large display of the same size as the Emulated Display that is on the un-trusted terminal

3. Trusted Pointing, this is the pointing means that enables the user to navigate in the virtual display

4. Trusted Output, this is a device that should present the portion of the virtual display that is pointed to or marked by the trusted pointing means.

5. Crypto Engine, this is the component responsible for making the secure cryptography. This could be e.g. a crypto-processor or a logical software component or a SIM-sized smartcard or a smartcard module or chip.

6. Interface: this is the communications interface that enables the trusted computer to talk to an un-trusted terminal

[0043] The components of "B) An Un-trusted Terminal" :

1. Controller, which could be e.g. a micro-processor and memory, or a microcontroller of the un-trusted terminal...etc.

2. Display of the un-trusted terminal

3. Interface that accepts the communication from the Trusted Computer

4. Emulated Display, it is a logical (i.e. software or firmware) component, but it is actually presented on the Display of the un-trusted terminal so that the user can see it.

[0044] Figure 3 depicts an embodiment of the card-shaped variant of the current invention, showing the essential physical components:

1. The smart chip that does the cryptography, and can optionally function as the main controller of the current invention, otherwise a secondary controller embedded in the body of the card can take this role

2. The card body, which also embeds the antennas of the contactless ISO 14443 interface for example

3. Fingerprint reader, also functioning as a pointing means through taking multiple scans of the finger print and comparing them to get the displacement of the pointer

4. Malleable display embedded in the card body

Best Mode for Carrying Out the Invention

[0045] Figure 1 described in details in the technical solution section represents the suggested best mode for carrying out the current invention.

Mode for the Invention [0046] This section collectively shows a variety of modes for carrying out the current invention. [0047] There are multiple variations aspects for carrying out the current invention:

• The type of the pointing means, e.g. optical sensor, touch pad, touch buttons, finger-print readers that also act as pointing means, gyroscopic pointing...etc.

• The type of the output device, e.g. an LCD display or a text-to-speech engine

• The device shape, e.g. token shaped such as the described pen-shaped token, or card shaped similar to a contactless smartcard with a malleable display on its body and an embedded pointing means. At the time of writing, malleable displays are available from multiple manufacturers.

• Device communications interface, e.g. contact based such as through a wire, proximity such as ISO 14443, wireless such as Bluetooth, optical communication through light signals as in PCT/IB2006/050080, GIRGIS, Hani)

[0048] The card-shaped variant is the runner-up candidate best mode implementation for the current invention; a sample embodiment is shown in Figure 3.

[0049] The embodiment shown in Figure 3 is actually an ISO 14443 proximity card, i.e. it gets powered-up from the reader, like the advanced smart-token embodiment depicted in Figure 1.

[0050] An interesting advantage in this embodiment, is that while the user is still navigating in the virtual display using the finger-print pointing means, the card can automatically verify the finger print to know whether it is the legitimate user who is actually using it or not, so it can eliminate the separate step for verifying the user identity through biometrics or PIN entry.

[0051] Another embodiment is when the output device is a text-to-speech engine. The user uses the pointing means to mark (or to select text) in the virtual display (the user sees it marked on the emulated display on the un-trusted terminal); the trusted computer would then present the marked text as voice that the user can hear, hence the user can compare what he heard from his trusted computer with what is marked on the emulated display that is on the un-trusted terminal, if they match then the user can feel confident that what he sees on the un-trusted emulated display is actually what is going to be signed.

[0052] The pointing means in this embodiment can also be an optical sensor, but the user

uses his finger over the light sensor to move the pointer, instead of moving the optical senor on a flat surface as in the case with traditional optical mice. As the optical sensor captures the images of resolution such as 32x32 pixels, it can also function as a partial finger print reader, and as the user rubs his finger on the optical sensor many times as a pointing means, the controller driving the optical sensor can use the captured images to reconstruct the actual (or even a partial) finger print of the user which can still be used to authenticate the user automatically without an independent authentication step; if the user's finger was not scanned sufficiently during the data verification step, the user would be notified to rub his finger more on the optical sensor in order to get authenticated before the final step of committing the transaction. The notification can be through for example a led.

[0053] One advantage of this embodiment is that it can be compact enough to fit in wearable gadgets such as a key fob, a ring or a watch. This embodiment is preferably implemented such that it would work without physical contact, using e.g. Near Field Communication; it can also get powered over the air from the contactless reader, as in the ISO 14443.

[0054] At the time of writing, most optical sensors available in the market enable the controller driving them to get the actual images being captured in real time. This is essential to enable the controller of the trusted computer to use these images to construct the sufficient fingerprints sub-images from which the finger-print authentication is accomplished.