One of the first questions people ask about is security tokens is how are they different than a USB flash drive? This page attempts to provide some info on that subject.

A security token is used to store cryptographic keys and certificates. It contains a processor, storage space, and a special-purpose operating system. The most important capability is that it can store a cryptographic key that cannot be copied off of the token by any easy means. The authentication methods used involve the user proving he has access to the secret key and not the transmission of the actual key.

The cryptographic method used is "public-key" cryptography. Plenty of reference material exists elsewhere, but here's a very brief overview. A user generates a pair of mathematically-related numbers. One of these numbers is kept secret (the "private" key) and the other is published (the "public" key). A person who has one of the keys can prove he has that key to a person with the other key without disclosing the key. (Note: the person with the public key must also have some assurance that the key belongs to the party he wants to authenticate. That's what certificates are all about.)

You can also think of the token as a sealed computer system. In general, we usually say that a person with physical access to a computer can access anything on it. A token seals the whole system in a tamper-resistant package you can only access through its serial port.

A party that wants to authenticate someone who has a security token can be reasonably sure that:

  • The token was present at the time of authentication (since the key can't be copied off the token).
  • Someone knew the PIN for the token. (Note: another feature of tokens is that they only allow a limited number of PIN guesses before disabling themselves. This is why it is reasonable to use a much simpler PIN than you would for a system where password guessing is a more practical attack.)

The relying party doesn't necessarily know:

  • Where the token was. The cryptographic challenges could be sent over the network and the answers returned the same way.
  • Who was using the token. The level of assurance is probably much better than a user name/password authentication though.

The user of the token doesn't necessarily know:

  • What data he is really signing. The actual data signed depends on the integrity of the computer hardware and software being used. The signer must trust that what is being displayed is actually what is being sent into the token and that it is all that's being sent into the token.
  • No labels

2 Comments

  1. Zeb Bowden

    Jun 12, 2006

    In the last part of your post you talk about data being sent into the token. Assuming you are encrypting data, does the data you're encrypting really get sent to the token? This is the first time I'd really thought about it that way and I can't say I can think of a better way to do it but it just seems odd to me that the token actually processes the data you're encrypting.

  2. Phil Benchoff

    Jul 13, 2006

    Good question. I'm making a few assumptions here, so maybe someone can provide some real info.

    First, you are usually encrypting with a public key so it is actually the decryption process that requires the token.

    Typical public-key encryption involves derriving a random session key used with a stream cipher.
    It is that session key that is encrypted with the recipient's public key and all you should have to send to the token is the encrypted session key, not the entire data stream.