How Do Hardware Token Devices work?

Question

Recently, my bank sent me this tiny device that generates a unique code that must be used when performing online transactions, all the device does is generate this unique code when I press a particular white button and it doesn't look like it connects to a remote server or anything of such.

I did some research and ended up in cryptography with something called the Hash function but I still don't get it.

My Questions

• How does my bank's servers know the code generated by this device is correct?
• Since it just generates five random digits every 30 seconds, why won't the server authenticate a random number I have also decided to use?

Solution

This has very little to do with hash functions. A cryptographic hash function may be part of the implementation, but it's not required.

Actually, it generates the digits on a time-based interval, if I press the button for it to generate the digits, it generates the digits and after about 25 seconds, and I press it again, the digits change not when I press it again immediately after I'd just pressed it.

There's your hint. It's a time based pseudo-random or cryptographic algorithm. Based on the time, there is a code. The dongle and the server know – or rather, can compute – the code for every window. This is a shared secret - the dongle does not connect to a remote server. The server will probably allow one or two of the most recent secret keys, to prevent the situation where you enter a key that has just expired while the transmission was en route.

(Although my recent experience with Amazon Web Service multi-factor authentication has definitely resulted in login failures within 5 seconds of a code being displayed to me. In other words, some vendors are very strict with their timing windows. As always, it's a trade-off between security and usability.)

The abbreviations CodesInChaos mention are Time-based One-Time Password (TOTP) and HMAC-based One-Time Password (HOTP), two algorithms commonly used in two-factor authentication.

Wikipedia has this to say about the RSA SecurID, a particular brand of two-factor-authentication dongle.

The RSA SecurID authentication mechanism consists of a "token" — either hardware (e.g. a USB dongle) or software (a soft token) — which is assigned to a computer user and which generates an authentication code at fixed intervals (usually 60 seconds) using a built-in clock and the card's factory-encoded random key (known as the "seed"). The seed is different for each token, and is loaded into the corresponding RSA SecurID server (RSA Authentication Manager, formerly ACE/Server) as the tokens are purchased.

I chose this article because it has a reasonable, physical description; the higher-level articles focus on the theoretical over the physical implementation.

The article also confirms that you need to keep the secrecy of the token, or someone else can impersonate your logins by knowing what the codes are as easily as you do.

The token hardware is designed to be tamper-resistant to deter reverse engineering. When software implementations of the same algorithm ("software tokens") appeared on the market, public code has been developed by the security community allowing a user to emulate RSA SecurID in software, but only if they have access to a current RSA SecurID code, and the original 64-bit RSA SecurID seed file introduced to the server.

However, since the verifying server has to have foreknowledge of the tokens, the two-factor secrets are vulnerable to attacks on the source as well. SecurID was the victim of a high-profile theft that targeted their own servers and eventually led to secondary incursions on their clients' servers as well.

Finally, there is more information available on the security.stackexchange sister-site under the multi-factor tag, and also on this site under the two-factor-authentication tag.

Comments

[Anand]

I have a device from Rabobank, a bank in Netherland which displays all the information about my transaction before I approve. How is this enabled in the hardware device?

[Patrick M]

And you approve with a button push, not a code you type into their online transaction form? That would necessitate some form of 2-way communication on the device: wifi, bluetooth or cellular. Or maybe a lower-tech 2-way pager system. Do you have to charge this device or replace the batteries on it? @Anand

[Anand]

The comes with 2 AA batteries and I am using it for more than a year. So the procedure works as follows: For login, I insert the card, scan the QR code on the screen and type my password for authentication in the device. When I do a transaction, the system shows a QR code which I scan to get purchase info and authenticate. When I just say authenticate in the device, the system moves to the next screen stating the successful transaction (I don't type any code or scan anything. It is just a click in the device). I have tried this device from many countries and it works very reliably.

[Patrick M]

2 AA batteries sounds like it definitely has to be a pager. Pagers operate by radio signal: lower power, longer range and less bandwidth than cellular signal. I'm sure they have a very specific frequency modulation and encryption scheme, but your bank would be the one to ask for more details. They might be reluctant to disclose, but disclosure is the only way to know if they're actually securing your verifications.

[Anand]

I googled about pager! I think this should be the only way they can communicate. But if there is a low-bandwidth comunication link all over the world with very less power consumption why it is not very popular??

[Patrick M]

It was very popular for a long time. But then cellular service got 'good enough', many people replaced their number-only pagers with voice-only cell phones, and then SMS took off in popularity in 2000. Text based 2-way paging doesn't really warrant carrying a 2nd device. It would be interesting to have a cell phone that was also hooked into a 2-way pager service, similar to how many cell phones were capable of both GSM and CDMA network connections when the techs were new and in more competition.

[Artjom B.]

"its life cycle is starting (as everybody born to world) and none of the devices started at the same exact time" - that's incredibly impractical, because then you couldn't produce more devices than one every 15 seconds. Also, it is incredibly insecure, because then each device in the world would have the same internal key and if one device if reverse engineered, then every device in the world would be broken instantly.

[Admin]

15 sec is too much i mean next device can be born such 1 sec. is okay. It is secure because you are making each device unique as born time is different.

[Artjom B.]

What happens when you press the button repeatedly? If the code doesn't change multiple times during the 15 second interval then there can be only one device minted in each 15 second interval according to your logic. The button is likely only used to power on the screen. If the code does change with each button press, then how would the server at your bank know when you pressed the last time, since they need to calculate the same code and only know when you finished entering the code into the bank website?

[Admin]

Ahhaa these devices just show generated number for 15 sec (or more depends) so within 15 seconds you have to input the number your bank account. You can press button repetadly but software in the device just accepts first press as code generation second press just turns off display and press again turns on but same number shows again if 15 sec does not end. Bank server calculates elapsed time possibly cheks many number combinations which could be in the time limit 15 sec or more depends.

[peter.petrov]

But if I have a virtual MFA device e.g. Authy on my phone, how does Authy know to generate different tokens for the different accounts/websites/etc.? I guess the server and the MFA device or dongle exchange initially some piece of information... E.g. I scanned a barcode with Authy. Otherwise, if the generated tokens are [only function of the current time] they would be identical for all accounts you want to protect with MFA auth. So now my question is: what if I have a physical MFA device, how would it exchange some initial info with the server?

[Patrick M]

You've got it, essentially. Each QR code that you scan is software token. Authy's own docs link out to this handbook article on Common Types of 2FA. A hardware token comes pre-loaded with the information in the QR code. When you set up a hardware token 2FA, you aren't taking new information from the provider; you instead tell the provider 'This is my hardware token', and they look up their copy of the secret and associate it with your account.