Cyberspace of Shujun LI

Shortcuts

Title Page

hPIN/hTAN: A Lightweight and Low-Cost e-Banking Solution against Untrusted Computers

Shujun Li¹, Ahmad-Reza Sadeghi^2,3, Sören Heisrath³, Roland Schmitz⁴ and Junaid Jameel Ahmad¹

¹ University of Konstanz, Germany
² Darmstadt University of Technology and Fraunhofer SIT, Germany
³ Ruhr-University of Bochum, Germany
⁴ Stuttgart Media University, Germany

This paper has been published in Financial Cryptography and Data Security: 15th International Conference, FC 2011, Gros Islet, St. Lucia, February 28 - March 4, 2011, Revised Selected Papers, Lecture Notes in Computer Science, vol. 7035, pp. 235-249, Springer-Verlag GmbH, 2012. © IFCA

Abstract

In this paper, we propose hPIN/hTAN, a low-cost hardware token based PIN/TAN system for protecting e-banking systems against the strong threat model where the adversary has full control over the user's computer. This threat model covers various kinds of attacks related to untrusted terminal computers, such as keyloggers/screenloggers, session hijackers, Trojan horses and transaction generators. The core of hPIN/hTAN is a secure and easy user-computer-token interface. The security is guaranteed by the user-computer-token interface and two underlying security protocols for user/server/transaction authentication. The hPIN/hTAN system is designed as an open framework so that the underlying authentication protocols can be easily reconfigured. To minimize the costs and maximize usability, we chose two security protocols dependent on simple cryptography (a cryptographic hash function and a random number generator). In contrast to other existing hardware-based solutions, hPIN/hTAN depends on neither a second trusted channel nor a secure keypad nor external trusted center. Our prototype implementation does not involve cryptography beyond a cryptographic hash function. The minimalistic design not only enhances usability but also increases security since more complicated systems tend to have more security holes and software bugs. As an important feature, hPIN/hTAN exploits the human user's active involvement in the whole process to compensate security weaknesses caused by careless human behavior.

hPIN/hTAN in a Nutshell

Simplistic design + Open framework
Two parts: hPIN for login + hTAN for transaction
Three h-s: hardware (USB token) + hashing + human
Three no-s: no trusted keypad + no trusted OOB (out-of-band) channel + no encryption
Four security requirements: PIN confidentiality, user authenticity, server authenticity, transaction integrity/authenticity
A better balance between security and usability

Threat Model and System Requirements

USB-token = a processing unit + memory units (for program and data) + a communication (USB) module + an "OK" button + a trusted display

Data @ USB-token: (UID, s, C_T, K_T* = K_T ⊕ h(PIN || s), PIN* = HMAC(K_T, PIN || s))
Data @ Server: (UID, h(K_T), C_S)

hPIN

Step 1: U connects T to C, and presses the “OK” button on T.
Step 2: U enters IDU on the untrusted keyboard and sends it to T via C.
Step 3: For i=1, …, n, T and U perform the following interactive protocol to enter PIN.
Step 4: T verifies if PIN* = HMAC(K_T* ⊕ h(PIN || s), PIN || s). If so, then T recovers the secret key as K_T = K_T* ⊕ h(PIN || s), stores h(K_T) in its volatile memory for future use in the hTAN part, shows a "PIN correct" message to the user U via its display, and goes to Step 5; otherwise T performs C_T++, shows an alert to U and stops. If C_T > V_T, T locks itself. Here, V_T is a parameter controlling the security against random guess attack of the PIN.
Step 5: T and S authenticate each other by following a mutual authentication protocol. When the SKID3 protocol is used, the mutual authentication process works as follows:

                   T -> S: (UID, r_T),
                   S -> T: (r_S, H₁ = HMAC(h(K_T), r_S || r_T || S)),
                   T -> S: H₂ = HMAC(h(K_T), r_T || r_S || T),

Step 6: T shows a message on its display to inform U about the result of the mutual authentication protocol in Step 5.

Legend: Dashed lines denote information display, and bold lines should the reconfigurable part.

hTAN

Step 1: U clicks a button on the e-banking web page to inform T about the start of a new online transaction. Then, she inputs each sensitive transaction data (STD) item one after another on the untrusted keyboard of C by repeating Steps 1-4. To embed STD verification into the input process, each character in the STD is shown as an asterisk "*" on the untrusted monitor of C, but in clear on the trusted display of T. This can naturally force U to verify the STD simultaneously while she is entering the STD. If U presses key, T shows an eye-catching warning message to inform the user for a few seconds and then the previously entered character is deleted.
Step 2: Upon completion of current STD item, U presses the "OK" button on T.
Step 3: T highlights current STD item for a few seconds, and prompts U to press the "OK" button again if the current STD item was not changed by C after Step 2.
Step 4: U presses the "OK" button again to approve the current STD item.
Step 5: U inputs non-sensitive transaction data (NSTD) to T by filling a blank on the web page in clear.
Step 6: T sends STD and NSTD to S by running a transaction/message authentication protocol. Here, we use HMAC to build the following protocol:

                   T -> S: (IDU, STD, NSTD, r_T),
                   S -> T: (r_S, H₃ = HMAC(h(K_T); r_S || r_T || STD)),
                   T -> S: (IDU, H₄ = HMAC(h(K_T); r_T || r_S || STD)),
          where r_T and r_S are two new nonces generated by T and S, respectively.

Step 7: S checks if H₄ = HMAC(h(K_T); r_T || r_S || STD). If so, S executes the requested transaction and sets M = "success", otherwise sets M = "error". Then, S sends H₅ = HMAC(h(K_T); r_S || r_T || M || STD) to T.
Step 8: T checks if H₅ = HMAC(h(K_T); r_S || r_T || "success" || STD). If so, it shows "transaction executed", otherwise "transaction failed", on its display.

Proof-of-Concept System

User study

Number of test persons: 20 (students and staff members of the University of Konstanz and the Stuttgart Media University)
Median login time (PIN = 8327): 27.5 seconds
Login success rate: 60/66 = 91%
Median time for making a transaction with 55 characters: 70 seconds (1.27 seconds per character)
User's average opinion on the overall usability: 3.65 (moderately usable - very usable)
User's median opinion on the overall usability: 4 (very usable)

How lightweight is the token?

Hardware
- Microcontroller: ATmega32 @ 16 MHz
- Program memory (Flash): 32 KB
- Program memory (EEPROM): 1 KB
- Data memory (RAM): 2 KB
Software
- Size of firmware ≈ 10 KB (can be downsized to 5-6 KB)
- Number of lines of C code ≈ 1500 (own code) + 1100 (other’s code for LCD and the SHA-1 hash function)

How low-cost is the token?

Our actual costs: 3-5 € per token
- Microcontroller: 1 €
- Display: 1-3 €
- Case: < 1 €
- Other hardware stuff: ≤ 1 €
- Programmer (Sören Heisrath): 0 €
Actual costs of mass production: ≤ 5 € per token?
- Batch purchase is always much cheaper!
- Programming costs per token is negligible: 3 man months / O(100,000) << 1 €.
- The gap between the token vendor and bank customers…

hPIN/hTAN vs. Existing Solutions

e-banking CAPTCHAs: insecure against automated attacks [Li et al., Breaking e-Banking CAPTCHAs, ACSAC 2010]
iTAN (indexed TAN): insecure against MitM (Man-in-the-Middle) attacks
mTAN (mobile TAN): insecure against mobile malware; require a trusted OOB channel; unavoidable additional costs (SMSs); untrusted telecommunication service provider (click here to see a recent news report)
photoTAN: insecure against mobile malware
sm@rtTAN plus: not very portable (with trusted keypad); repeated data input; expensive; require banking card
sm@rtTAN optic: not very portable (with trusted keypad); require optical sensors; expensive; require banking card
AXSionics personal token: require optical sensors; expensive (including fingerprint recognition system); dependency on third-party website
Class-4 e-banking smart card readers like FINREAD/FinTS/HBCI: not very portable (with trusted keypad); expensive; require banking card
IBM ZTIC: without PIN entry protection; complicated design (encryption + TLS/SSL + HTTPS)
...

hPIN/hTAN: portable (without trusted keypad); independent (no dependency on an OOB channel or a trusted third-part website other than the e-banking server); dedicated but cheap device (simplistic design); no risk of mobile malware; no smart card needed; no optical component needed; enhanced user experience of security; open framework that can be further generalized/complicated if necessary

Errata

In the published edition of the paper, the SKID3 protocol in Step 5 of hPIN protocol is erroneous, which was caused by a mistake when we made some changes to the description of hPIN protocol. In addition, in both hPIN and hTAN protocols, the key used in HMAC should be h(K_T), not K_T. This is a typo we made in the paper writing. We apologize for making these errors.

To be more exact, in hPIN protocol, the following part

                   T -> S: UID,
                   S -> T: r_T,
                   T -> S: (UID, r_S, H₁ = HMAC(K_T, r_S || r_T || T)),
                   S -> T: H₂ = HMAC(K_T, r_T || r_S || S)

should read

                   T -> S: (UID, r_T),
                   S -> T: (r_S, H₁ = HMAC(h(K_T), r_S || r_T || S)),
                   T -> S: H₂ = HMAC(h(K_T), r_T || r_S || T)

And in the hTAN protocol, K_T should be replaced by h(K_T) wherever it appears.

Yet another error is about PIN* which is represented by two different equations: h(PIN || K_T || s) and HMAC(K_T, PIN || s). Since the latter is more general, so it should be used to replace the former.

All information on this website is for personal use and Shujun Li is not responsible for any misuse of information provided. The listed links on any page do not indicate any personal recommendations for any purposes for the visitors of this website, as each link is included for a different reason meaningful for Shujun Li's personal use. Logo files of websites are used to facilitate recognition of the external links, and does not represent endorsement of the corresponding websites for the content of this website. If the use of any logo file violates the copyrights or policies of any individuals or organisations, please contact Shujun Li so that he can removes the logo file or the whole link. Please also help report broken links and broken images on this website.