Tokens, smart cards, and one-time passwords

The card taxonomy, and the one line that matters

Objects used for authentication run: embossed (raised characters on the front, an old credit card) · magnetic stripe (a magnetic bar on the back, a gift card) · memory card (electronic memory inside, a prepaid phone card) · smart card (electronic memory and a processor inside).

The examinable line is the last one, and it is narrower than people expect. Memory card versus smart card is exactly "processor or no processor". It is not size, not shape, not whether the card is contact or contactless — a contactless smart card and a contact smart card are both smart cards, because both compute. Everything a card does cryptographically requires the processor, so a memory card can hold a secret but can never use one without handing it over.

That has a direct consequence. A magnetic stripe holds only a simple security code that cheap equipment can read and reprogram, so a memory card used for authentication is always paired with a PIN: the adversary needs the card (or a duplicate) and the number. Three drawbacks come with any card-based scheme: it needs a special reader, which costs money and must itself be secured; token loss locks the user out and costs an administrative replacement, and a found or stolen token needs only the PIN; and users dislike them for routine computer access.

Four dimensions of a smart token

Smart tokens are classified along four independent dimensions — independent meaning a token has a value on each, not that one implies another.

1. Physical characteristics — an embedded microprocessor. Card-shaped ones are smart cards; others look like calculators or keys.
2. User interface — a manual interface has a keypad and a display; an electronic-only token has neither.
3. Electronic interface — contact (inserted into a reader that touches a conductive, usually gold-plated contact plate, over which commands, data and status travel) or contactless (an antenna in both card and reader, with the chip typically powered by the reader's electromagnetic field, at a range of roughly half an inch to three inches — chosen for interactions that must be fast, like building entry and payment).
4. Authentication protocol, itself a three-member taxonomy and the one that carries the security argument:
5. - Static — the user authenticates to the token, then the token authenticates the user to the computer. Once that local step is done, the second half behaves exactly like a memory token, and it is replayable.
6. - Dynamic password generator — the token produces a fresh code periodically, entered manually or transmitted. Token and system must be initialised together and kept synchronised.
7. - Challenge-response — the system sends a challenge, typically a random number, and the token computes a response, for example by signing the challenge with its private key.

Only the third is inherently replay-resistant, because only the third binds the response to something the verifier chose right now.

Worked example — one TOTP login, both ends

A one-time password device holds a secret seed and combines it with a varying input — the current time, or a counter that advances per use — through a hash or block cipher. Each code is used once. The verifying system holds the same seed and computes the expected value independently.

TOTP, specified in RFC 6238 on top of the HOTP truncation of RFC 4226, makes the varying input the clock:

T     = floor((current_unix_time - Time0) / Step)
TOTP  = Truncate(HMAC-SHA-1(Key, T))

with Time0 defaulting to 0, Step to 30 seconds, and Truncate cutting the HMAC down to 31 bits and then to 6 decimal digits by default (7 or 8 are permitted). The key must be at least as large as the hash output, and SHA-256 or SHA-512 may replace SHA-1 where the token supports it.

Walk one login. At Unix time 59, the token computes T = floor(59 / 30) = 1, takes HMAC-SHA-1(Key, 1), reads the low four bits of the last byte as an offset, pulls the four bytes starting there, masks off the top bit to keep the value positive, and reduces modulo one million. It displays 287082. The user types six digits into a login form.

Now the important observation: the server computed 287082 too, from its own clock and its own copy of the seed, and nothing was transmitted between the two to make that happen. The token has no network connection and never needed one. What crosses the wire is a six-digit number that will be worthless in thirty seconds.

What drift costs, and what the tolerance window buys

The token's clock drifts; the protocol is not loose. The standard accommodation is a tolerance window: the verifier accepts a code computed for the previous or next time step as well as the current one, so a token a few seconds out still works. Record the observed offset and compensate for it in future. When drift grows too large, the token must be resynchronised.

The trade is explicit and worth stating in an exam: a window of ±1 step means the verifier will accept three codes at any instant instead of one, which triples an online guessing attacker's chance per attempt and extends the lifetime of a shoulder-surfed code to about ninety seconds. Widen it further and you are trading real security for user convenience with each step you add.

One more property, easy to state and heavily marked: a host attack is weaker against a token than against a password, because with a one-time passcode there is no passcode file to steal. The verifier stores a seed and derives the current code; there is no stored list of valid answers to lift. And a token turns a low-entropy PIN into a high-entropy passcode, so exhaustive search fails even though the PIN itself is guessable — the attacker must also be physically holding the token.