Comparison of TAN mechanisms and alternatives

This blog post should provide a short overview of TAN alternatives and methods as well as their pitfalls and security.

The presented ones are:

• Traditional TAN
• Indexed TAN
• SMS based transaction authorization
• Mobile app based transaction authorization
• TOTP / HOTP token
• ChipTAN / PhotoTAN / FlickerTAN
• Signature based

And at the end a short

• Conclusion

Traditional TAN

In traditional TAN environments the user gets a list of transaction authorization numbers which is an unordered set of numbers of a fixed length. Whenever the user wants to authorize an transaction he can use any of the provided numbers - any number that hasn’t been used up to this point and is contained on an unexpired set of TANs can be used to authorize an operation.

This method has been seen as unsafe for a longer time (justified). The main problem is that this mechanism is particular prone for phishing attacks - an attacker can trick an user into entering any TAN anywhere and use it so sign any operation in the future - and the user won’t re-use that TAN since he thinks that it had already been used.

If one neglects phishing the probability of completing a transaction with a single request - for numeric TANs consisting of $n$ numeric characters chosen of the list of $m$ valid TANs $m * \frac{1}{10}^n$. So if one uses the typical $6$ digit TANs on a list of 25 TANs the probability of executing an operation is about $0.0025$ percent. This may seem low but since one has multiple tries during an automated attack (one has to guard such a system against repeated invalid tries - without opening the door for denial of service attacks - so one cannot simply lock an account for which an attacker tries multiple transaction authorizations) the probability is not that low.

Main attack vectors:

• Phishing (highly vulnerable)
• Malware (Proxies, local manipulation)
• In case of short TANs: Brute-force
• Interception of TANs during transfer (Postal)

Indexed TAN

Since traditional TANs are that prone for phishing attacks indexed TAN lists have been introduced. In this case there is a set of $m$ numbers as before but they are ordered and numbered. In case a user wants to authorize an operation he is asked for a specific TAN instead of any TAN. Since every TAN is only asked for exactly once this reduces the probability of guessing correct by $\frac{1}{m}$ compared to the traditional TAN list. On the other hand - depending if one completely locks TANs that have not been sent properly - this might open the door for denial of service attacks. One may also only temporarily block usage of such numbers or block them from given sources, etc.

The main attack surface for iTAN is malware that executes on the computer or is capable of altering network traffic (for example by running on proxy servers and having people ignore certificate security warnings of their web browsers) and again phishing attacks. In case of malware software may alter the transaction details displayed to the user - letting the user enter an iTAN to authorize a totally different transaction.

Main attack vectors:

• Phishing (vulnerable in case of near real-time interaction)
• Malware (Proxies, local manipulation)
• In case of short TANs: Brute-force
• Interception of TANs during transfer (Postal)

SMS based transaction authorization

This is the weakest method and even less secure than TAN and iTAN. The idea is that a user requires to own his phone to receive an SMS after an operation has been requested. This SMS contains a unique transaction authorization number that is valid for the requested transaction (many times these SMS should also contain a description of the operation that will be authorized by this code so people can check that malware hasn’t altered their requested operation during transfer to the service).

The main problems with this approach are:

• Telephone networks are unsafe. There are known attacks on SS7 (the routing protocol used for telephony networks) which allow just redirection of all calls and SMS for a given number into a different networks; there are known attacks on encryption; support centers are known to hand out SIM duplicates after really weak authentication or via postal service without strong identification of the receiver; About 30% of SIM cards are still crackable via a year old known bug that allows discovery of keys required to install arbitrary software; Phone theft is a huge thing with street criminals and screen locks do not provide safety; SMS are only transport encrypted and mobile devices can be forced into unencrypted connections with the mobile network in which case wireless sniffing is possible
• Smartphones are currently the least secure known electronic computing platform (see below)

SMS based authorizations are that unsafe that they are explicitly not recommended with standards like NIST SP 800-63B.

Main attack vectors:

• Malware on the device (If only mobile fully automated attacks are possible; highly vulnerable devices)
• Telephony-Network based redirection
• Requesting substitute SIMs with nearly non-existing authentication
• Phone number transfer with nearly non-existing authentication
• Sniffing of wireless traffic
• Malware on the SIM
• Phishing (somewhat vulnerable in case of near real-time interaction)

Mobile app based transaction authorization

This is again on of the weaker authorization methods. In this case an application is installed on the mobile phone of the user who wants to authorize an operation. He issues the request on his computer or another device, gets a push notification on his mobile and responds there granting or declining the operation. The application might use strong authentication (for example using public key authentication - maybe even using hardware security modules like SIM cards or keys stored in some secure storage that’s accessed via secure enclave of the mobile device) to authorize itself against the webservice that is notified about the users decision.

This may sound like a good idea on the first hand - and in theory it is as long as the mobile device is secure.

On the other hand every mobile phone that’s capable of executing such authentication applications currently out there is vulnerable to a whole bunch of attacks:

• All phones out there can be rooted via rowhammer based attacks. Rowhammer based attacks have a long history but haven’t been seen in the wild because they are - compared to simply send some phishing mails which is currently highly effective - more sophisticated. As soon as phishing won’t be that promising one may seem them though. They exploit hardware vulnerabilities in today’s DRAM (i.e. memory) chips by hammering the same location again and again with fast requests. These requests induce random bit flips in the memory which may corrupt the stack points of the application, virtual machines or the kernel - which may lead them to jump to a random memory location after return from the current subroutine. If one fills a huge amount of RAM with code that just jumps to a location containing loaded shellcode one has a chance of executing that shellcode after hammering memory. Currently there is no known countermeasure to that that doesn’t drastically (by a factor of many orders of magnitudes) despite if has been tried (see for example CAn’t Touch This for some ways this has been tried). On the other hand for every known Software solution to his problem there had been multiple solutions how to continue exploitation of the systems. The only known way to massively reduce the success probability is usage of ECC memory - i.e. memory that tries to detect and correct memory errors. This also doesn’t fully mitigate the attack but massively reduces the chance. Rowhammer is particular bad because it also works out from interpreted machines like JavaScript interpreters and JITs, can evade virtual machines because it’s a hardware exploit, etc. And even when one used ECC memory there are variants of this attack targeting GPU memory - for example via OpenCL, OpenGL or even from the web via JavaScript and WebGL.
• Phones are devices on which people often install untrusted Software - way more often than on their computers. A small game, a small app that somebody recommended, etc.; they tend to have their browsers configured in an insecure way.
• Phones are always connected to untrusted networks. Telephony networks are mainly untrusted and known to contain many weak spots (starting from authentication, partly using weak encryption; roaming puts phones into different networks, etc.) and the networks have been inspected way less than wireless LAN or wired networks because experimenting with them is illegal in most parts of the world - and activity on them is monitored by network operators. Since phones are also upgraded not very often by owners (most of the time they are also kept years after the manufacturer stopped providing updates) most of the devices out there run with a massive amount of known security bugs.
• Most phones also provide WLAN services and many permanently scan for open networks, connecting to them as soon as they discover them. This provides additional attack surface - together with the previously mentioned update status this is a nightmare from a security standpoint.
• SIM cards are also often vulnerable to attacks (an older example is the crackable 3DES key leakage via data SMS which allowed attackers to install arbitrary applications on SIM cards - and most devices allow the SIM card to initiate installation of software called SIM toolkit. The STK allows to run arbitrary code on the SIM card (normally this should be authorized by the network operator).
• Phone theft is a massive problem with street-crime.
• Since phones are used permanently during the day risk of loss is higher than with other hardware and theft is also more probable.

There is a whole bunch of known malware attacking banking App-Tan applications lie Zeus, Game over Zeus, Citadel, etc. Most of the time this malware is distributed via spam or scamming attacks. There have also been Trojans and worms that tried to automatically correlate mobile devices and malware via sidechannels like identifying the networks hosts and mobiles had been using, using UXO, etc.

Main attack vectors:

• Malware on the device (If only mobile fully automated attacks are possible; highly vulnerable devices)
• Phishing (somewhat vulnerable in case of near real-time interaction)

TOTP / HOTP token

These methods have one thing in common: They use a seed that the issuer of the token (the entity that asks for your authentication) and the device that one uses know. They use this seed to derive a TAN that’s either changed on basis of the time (TOTP) or based on the number of previously generated TANs (HOTP). There are multiple common implementations of these tokens - beginning from Software implementations like the Google Authenticator app and ending at hardware implementations that do not have any network connection to the outside. The latter ones are already commercially available (like the RSA SecurID system).

The key requirement for such systems to be safe is that the seed is only ever known to the device issuing the tokens and the service that one authenticates against. As soon as a third party gains knowledge of the seed this third party can issue any authorization it desires. In case the manufacturer pre-programmed the tokens a hack of the manufacturer may compromise a large amount of services as has happened during the hack of RSA SecureID (which has been an interesting thing on it’s own if one reads how the hackers managed to compromise the system - it all started with MS Word on a secretary’s computer). Also a hacked backend database on the service side allows the attackers to forge any users confirmations without having a ability to discriminate between the forged ones and the ones generated by the users.

As long as these systems are used on dedicated hardware the only pitfalls are leaked / stolen seeds and malware displaying different information inside the applications / webpages that ask for authorization. So these methods are prone for authorizing different actions when malware gains access to computer systems.

Main attack vectors:

• Malware (Proxy, local device)
• Stealing seeds on either side

ChipTAN / PhotoTAN / FlickerTAN

This method removes the need for the TAN generator to have a permanent network connection which provides an enormous gain in safety. Most of the time the smartphone is used for PhotoTAN - so the same problems apply as for application based TAN and SMS. If an external device is used (like with ChipTAN most of the time - they use devices like the RainerSCT) this methods may provide a suitable way of issuing TANs as long as the generation algorithm which normally is based around an known seed as well as an hash or symmetric encryption algorithm (applied in a special way) is used or the transaction details are signed with a public key mechanism. The transaction details which are included in the visually transferred and captured bar code that’s required by these generators have to be included in the hash generation (for example one can combine the generated OTP token with the transaction details and hash them both to generate the TAN that has to be entered by the user).

The major drawback when done safely is that the user requires an addition device instead of his mobile phone - that device should not have any communication abilities despite the visual recognition of the transaction details and a display to display the transaction details and the corresponding TAN.

Main attack vectors:

• Stealing the hardware key store

Signature based

These are of course as always the most secure ways - if the keys are managed in a safe way and the users cannot be forged into signing other content than they think they do. Basically it’s application of strong public key signatures with which one can sign a request.

The key point is securing the signature keys. If they are only stored in some device memory like your computers or mobile phones storage they are as safe as your device is (and note that there are sidechannels - for example cache timing attacks - that allow readout of memory regions even from JavaScript, even though browser vendors try to convince one that they apply countermeasures - but it has been shown that there is always a way to get enough timing resolution to steal data from other applications on the same physical hardware as long as these applications are not developed in a way to prevent such attacks from end to end).

The safest way to store keys is an external hardware security module (HSM) or a smartcard. In case of smartcards and HSMs the second important thing is how they are commanded to sign content. If content is sent to them from a computer or mobile phone and the user is prompted for a PIN code on the computer or mobile itself - like for class 1 card readers - malware might steal users pin or send forged data to the smartcard or HSM. If malware steals the pin with class 1 devices it’s able to sign as many data as it wants to as long as the HSM is connected / the smartcard is inserted into the card reader (so remove them when not required!). On class 2 card readers the pin is entered on the card reader itself but the user lacks feedback about what he has signed with his action. It prevents malware to sign an arbitrary amount of messages - but doesn’t prevent it to send counterfeit data to the smartcard - so the number of stolen signatures is limited but the risk of signing other data than intended is imminent (as soon as the device has been compromised).

Class 3 smartcard readers offer a pin terminal as well as a display. They display the data that is going to be signed by the card and ask the user for the pin together with the shown data. This prevents malware from presenting the user different data than he’s going to sign.

Class 4 smartcard readers are not any more interesting for most applications - the main difference is that the smartcard readers authenticate themselves also against the backend that they send data to. These are used at point of sales terminals for example and should prevent shops from using counterfeit terminals that collect pin numbers without being noticed.

The main reason signature based mechanisms are more secure than OTP tokens is that the only location ever that need to know the private key is the HSM or smartcard (keys may even be generated on these devices without the ability to read them externally which is the best way such systems can be used).

Examples for smartcard readers are (note - the links are Amazon affiliate links, the author profits from any qualified purchases):

• A simple class 1 reader from CSL
• A class 2 reader with keypad but without display
• A full class 3 reader from RainerSCT including display and keypad - as well as RFID functionality
• Class 4 readers are normally not purchased through end-user retail shops

Main attack vectors:

• Stealing the hardware keystore
• Malware for class 1 (fully automated) and class 2 (only single transactions) card readers or locally stored keys
• Using manipulated terminals (hardware exchange required)

Conclusion

Methods like TAN and iTAN are prone for phishing but at least not an arbitrary number of automated attacks, SMS based solutions are the weakest currently available solutions, App based solutions are as insecure as the mobile platform underneath. Avoid them at any cost.

External TAN generators (TOTP / HOTP tokens) offer acceptable security whereas ChipTAN/PhotoTAN/FlickerTAN provides good security against automated attacks - assuming they are not implemented on hardware that’s connected to a network and assuming that the seeds have been stored in a safe way at the entity that one’s authenticating against too (a really bad example of how this can fail has been the hack of RSA SecureID where hackers stole the Seeds for millions of hardware tokens that have been pre-programmed by the manufacturer (note that such tokens should always be programmed by the issuing party - nobody else should ever have access to the seeds and the seeds have to be truly random).

If done correctly (external key store on i.e. a smartcard or HSM, external verification of the signed data and external PIN entry or at least confirmation) signature based mechanisms offer the best available security.

This article is tagged: Internet, Security, Web, Tutorial, Computer