Two-Factor Authentication

Introduction

Two-factor authentication (TFA) is often used to let users authenticate themselves to computer systems in a safe way. It requires the use of two authentication factors out of three possible:

• Something the user knows - e.g. a password, a code or a PIN number.
• Something the user has - e.g. a smart card or a hardware token.
• Something the user is - e.g. a biometric characteristic - possibly a fingerprint.

By itself, two-factor authentication is nothing new. However, many of the applications are more recent.

The Golden Standard - RSA SecurId

At some time around 1980 a company was granted a significant US patent. The patent had a long description, but the essense of the content was how two parts could agree upon a token without ever communicating and by just agreeing upon the current point in time. Today, this company is known as RSA Security.

This idea led to the RSA SecurID token - something a user has - and which is used in combination with something a user knows to implement two-factor authentication.

The token is personal in that it has been factory initialized with a personal key together with the current time. It is basically a digital watch implementing a propritary hash-algorithm. These tokens contain no servicable parts. The time in even the cheapest, digital clock never drifts unless the temerature is changed significantly. No resetting of any kind is ever necessary. Once initialized, the circuitry can run for multiple years up until some date of expiration. Once the battery is empty, the tokens are disposed.

For 30 years RSA Security has had a great business selling their custom two-factor authentication solutions. Until not too long ago, these tokens were expensive. RSA Security went for the biggest customers only. As part of selling their products, they made their customers sign a non-disclosure agreement including statements about the customer promising not to try to reverse engineer the products sold. However, some individuals around the internet have done some reverse engineering. This possibly started with some Russian engineers being experts in electronics.

Many other companies have tried to follow in the tracks of RSA Security. However, US patents last for 20 years. In order to circumvent the expiration of the original patent, the original patent has been covered with newer, overlapping patents which once granted have the effect of extending the effect of the original patent. The US patent law does not really try to honour the publication of private inventions by granting a limited, exclusive right to use. The European patent law is quite different from the US patent law, but let this be for now. Competing companies have for a long time had to invent other ways to implement two-factor authentication. Since the idea of using the clock and the timeline has been covered by patents and could not be used, then different kinds of other strategies have been put to use. Many of these have involved hardware tokens where the token and the server must be kept in synchronization relative to the number of tokens used. Many of these alternative solutions happen to appear somewhat clumsy during actual use.

Today, the RSA SecurID token exists in many forms. The basic idea continues to be the same. Since RSA SecurID tokens have existed for a long time and the solution with using the time is very elegant, this has by many (including RSA Security itself) been called the golden standard of two-factor authentication.

Since the solution is the golden standard and its use has been implemented all over the world and by many large corporations and organizations, it has been the target of much scrutiny from researchers and the like. One possible example of the outcome of this is exposed in Scientists crack RSA SecurID 800 tokens, steal cryptographic keys. This indicates that the effective security of the solution may possibly degenerate over time.

As it happens with e.g. common, NIST-approved hash functions and public-key cryptography, which happens to be weakened over time and as a result of research and scrutiny, nothing lasts forever.

Danish NemID

Since July 2010 there has in Denmark existed a common two-factor authentication scheme called NemID (translated EasyID). Initially, the "has" part was something as simple as a small card with printed numbers:

This is developed by the company DanID and is used by Danish internet banks, government websites and private companies.

At first, this somewhat low-tech solution was disappointing. Technically, it does not impress. However, as compared to digital circuitry, the solution has some immediate benefits since it helps implement two-factory authentication right away and without any kinds of compatibility problems which may easily be introduced as a result of using electronics. Additionally, one-time pads generated from a random source of input happens to be the safest possibly codes to use.

The cards with printed numbers do expire and users do need to have new cards issued and with regular intervals. Some more recent developments have lead to a hardware token, which can optionally be used in place of the card.

This does not expire too fast as compared to the card. The physical appearance of the token with its form factor and its rounded corners does happen to give associations to some of the RSA SecurID tokens.

What the future may hold for NemID is hard to tell. For one thing, I have recently read that DanID has tried to make their NemID work on mobile terminals. Apparently, some of their first initiatives have not been backed up with enough money to implement it. I have read some indications of this in Eight million DKR to NemID on the cell phone was not enough. Possibly, three times the amount of money happens to be necessary to implement a solution for mobile terminals.

Yelstream SecurePIN

Back in the year 2003 someone told me that it was impossible to implement something similar to RSA SecurID on mobile terminals. This I had to explore.

At around 2003, one of the most common platform for mobile terminals was Suns MIDP/CLDC - a set of profiles within the Micro Edition of Java. Nokia had many variants of a smaller series of terminals with colour screens and called Series 40. SonyEricsson had introduced a model called T310 which was crammed with functionality and which was one of the very first models with Java and colour and allowing for a decent sized program to run. These generations of mobile devices had very fragmented memory of which some was available to user programs. Devices like these allowed for a program of a static size of 50-64 KiB and a runtime size of 96-160 KiB. To reduce the size of compiled programs, it was necessary to apply hard obfuscation. The solution of mine used around 35 KiB of static space.

After studying, seeking information, asking around and trying out a bit, I came up with a solution named SecurePIN and built around the concept of a personalized hash function:

This uses a hash-based message authentication code (HMAC) to calculate a message authentication code. The calculation needs a secret, personal key in combinatation with the actual input. The cryptographic strength of the HMAC depends upon the strength of the underlying SHA-1 hash function. The actual input used was the current time modulus some chosen amount of time. The output of the hash function had to be processed carefully to reduce it to a number of decimal digits.

This ended up with a fully functional prototype as described in more detail here: SecurePIN.

The difficulty with which this implementation was crammed into the phones and by using standard libraries, is hard to imagine for the common Android and iPhone developers of today. The other end of embedded programmers would try to state that a few KiB would be enough both now and then, which of course is not right.

Putting the "has" part of two-factor authentication into a mobile terminal has advantages over propritary tokens. For one thing, people already carry their mobile phone with them. For another thing, it is possibly to include MANY software tokens without having to carry the same amount of physical tokens. As a third thing, it is as part of the personalized initialization process possible to set the length of output.

Have you ever tried leaving home on your bicycle and riding to work with just your mobile phone and your house key?

Using a common platform in favor of propritary, epoxy-sealed tokens may open up for unwanted access. For one thing, it may be possible to steal a persons phone, set the clock of the phone to some time in the future - say, a day later - and read the token for this day, set the clock back to normal, hand the phone back without the owner knowing that it was ever gone, and then a day later applying the PIN code without actually having the phone.

Should something like SecurePIN be implemented today, a number of things should be considered. While the hash function SHA-1 was safe before 2005, multiple security flaws have been found. For possible consideration is the set of SHA-2 functions or even the SHA-3 functions (to be finalized by NIST in 2012).

Using an encrypted keystore to save personalized, secret keys could be a good idea. Very much depending upon the purpose, it may be a cludge to force the user to remember and enter yet a password to open up the keystore. But it could be much safer, if the device was ever lost. Classical keystore handling tends to be CPU-intensive.

Other constructions are possible. Whetever these other constructions and improvements could be, it would be extremely important to test the randomness of the produced numbers by applying a common chi-squared test.

Other, important subjects for consideration is the common negligence of users and the procedures for how to perform personal initialization and issue secret keys in a safe manner.

It most certainly was possible to implement two-factor authentication by using the timeline.