Cryptography Reference
In-Depth Information
However, the way these tokens work is different from what was described in
Section 6.5.1. Why? Suppose the secret password,
S
0
, were stored in the token
RAM. At the push of a button, a one-way hash function would be applied
to it
n
times, and the result would be displayed. The number
n
would have
to be taken from a counter running backwards. Since a token may be used
many thousand times, the counter would have to be initialized to a very high
startup value, e.g., 10 000. In other words, the startup time would apply the hash
function to
S
0
about 10 000 times at each push of a button. The computing times
would be unacceptably long. Moreover, the number of uses would be limited
from the outset. This may not always be desirable. To solve both problems,
value
S
0
could be changed in a defined way when
n
=
0 is reached, and the
counter would be reset. And finally, the pushbutton should be protected against
inadvertent activation.
Users find the SecurID tokens more convenient. These tokens create new pass-
words (in our case six-digit numbers) by the minute. RSA produces two types
of tokens: with and without keypad. In the first version, you type your PIN on
the token keypad and enter the number read in the computer upon request. In
the second version, you put your PIN ahead of the number read and type this
conglomerate. Though this variant is cheaper, it is more insecure, of course.
More about it further below.
But how are the passwords created? One approach accommodates a secret
DES key in every token, and repeatedly encrypts a known or secret 64-bit
startup block with this key. It does not necessarily have to be DES. If you
continually encrypt two 64-bit blocks using IDEA and compute a hash value
from the 128-bits of ciphertext produced, you can certainly forestall cryptana-
lytic attacks. The server (as we call the computer Alice logs on to for reasons
of simplicity) naturally also knows the key and can check the password for
correctness.
In contrast, RSA uses a hash algorithm that has been made public (they trust
in the abilities of Ron Rivest who checked the method). A built-in clock and a
token-dependent secret value called
seed
are used to code a hash value every
15 seconds. The key-tag variant uses four such values to compute numbers that
change every minute. This is a clever idea. One could simply compute a hash
value from the seed and the clock every minute and display it. But if Mallory
knows that two successively displayed values are computed from numbers that
differ by 1 (or by 60), then he might be able to calculate parts of the seed, if
the hash function is vulnerable to such an attack. (I don't think that one-way
hash functions have to be resistant to this type of attack.) However, the four
