How do hardware OTPs work?

Question

I've recently stumbled across a number of one-time-password (OTP) smartcards in some of the internet shops specialized on cryptographic equipment.

Now I know / think to know how OTP works with YubiKeys and RSA tokens:

1. You get the token, a shared secret with the production server is hardcoded
2. You do something with the token and he gives you the OTP (via display or simulated keyboard)
3. You send the OTP to your app which in turn asks the manufacturer's server if the code is correct
4. You successfully authenticated if the server responded "yes"

Now do actual cards (like the Gemalto MD 830) work the same way, e.g. hard-coding the shared secret andf requiriung online servers by the provider or how does the secret get onto the card?

Furthermore how is the generated OTP moved from the card to the computer? Will it be displayed so the user can copy and paste it? Does it require additional hardware (except for the PC connected reader)? Must it be fetched by the software?

Note: For the paragraph directly above, I'm explicitely talking about cards that don't feature a built-in display.

Answer 1

@JeffMeden gave a good overview of how PKI smartcard work, he failed to point out that they use completely different protocols and security models compared to OTP tokens.

An OTP token uses some kind of pre-agreed secret* to generate a password. The protocol can only prove someone at the time holds the token. It cannot verify the identity of the server nor protect against man-in-the-middle, replay (while the password is still valid) or duplication of the secret. These has to be migitated externally (e.g. using TLS).

A PKI smartcard, on the other hand, is like a small computer that can handle all kind of cryptographic functions like key generation, signing and ecryption. The card can defend against all of the attacks mentioned above if implemented correctly. I.e. the card alone can establish secure communications with the server using insecure pipes.

That being said, PKI cards are probably overkill for pure authentication applications.

* either by the user registering an id on the token or the user being issues a secret code which is loaded onto the device

Answer 2

The smartcard based systems like the product in the link you provided are based on PKI (public key infrastructure) which is a means to authenticate a user based on their ability to sign something with a private key (held on the smartcard) that can be proven with application of the public key. Since the private key never leaves the card (at least, in fully secure implementations) it is a means to guarantee that the user does have the card since there is no practical way to duplicate it and it is challenged to prove itself during each sign-on.

So, the RSA SecureID has a similar purpose (proving the user has the object in their possession, and is impossible to duplicate) but is not as robust because the smartcard can interact with the OS, to do things like force the user to log out if the card is removed from the computer, and provide other cryptographic functions like signing emails.

In the case of the keyfob, the "private" section is still known to RSA (or whoever issued the fob) because it is needed to validate the code. In the case of the smartcard, the private key could (should) only exist on the card, and the public key is used to validate the card.

Answer 3

@JeffMeden and @billc.cn already gave a very good explanation. In your original question you mentioned something, I would like to comment on:

You said "You send the OTP to your app which in turn asks the manufacturer's server if the code is correct".

This can be true in some cases like the yubico validation service or services like duo or onelogin. These are services that ease the process of getting started.

But you can as well run your own authentication service. Then your application will ask your own auth server, if the OTP is correct. Still - as both pointed out - the OTP token (fob) usually has the shared secret implanted on it by the manufacturer. I.e. the manufacturer might still know this shared secret.

Anyways, there are some OTP devices where you can create your own shared secret, like the yubikey, which you can initialize and authenticate against your own auth server. In such a scenario the secret keys and the authentication decision is under your control. There are several implementations of different complexitly levels out there. privacyIDEA is a very sophisticated authentication server, that is open source and supports a wide range of different token types - getting you into control, back in the drivers seat.

Answer 4

You can also use a programmable hardware token as a source of the required OTP. The difference with this type of token is it can act as a direct replacement for an authenticator app (such as Google or Microsoft authenticator).

Additionally, you can also consider using a Fido key (these work differently to hardware tokens in that rather than generating an OTP code they use a different authentication strategy. FIDO keys are generally more expensive than oath tokens, but do offer additional anti-phishing protection measures.