I wrote this up about a weirdness I spotted in one of the SecurID
devices from Security Dynamics (strong authentication, token-based). I
don't know if it's known or not - and it may not even be a problem -
but it is decidedly interesting behavior and worthy of note.
Joel Moses, CISSP
Nashville, TN
----------------------------------------------
Security Dynamics' PinPAD Tokens - How they work and why they
sometimes don't
Joel Moses, CISSP
This may not be new information to some of you, but might be of
interest to others because of the different stories your SDI
salesperson may have told you. It is the result of a little hands-on
trial and error with a Security Dynamics token.
To those who are not familiar with the product line, Security
Dynamics' line of SecurID time-based strong authentication products
include several different form-factors: Standard Card, Key Fob,
PinPAD, and SoftID, to name the most popular. The standard card uses a
display of a tokencode only, forcing the user to append this code to
their PIN and then send both to the client for authentication by the
ACE/Server. The Key Fob functions in the same way.
The two other methods, PinPAD and SoftID, rely on a different method.
They apparently use the same method, although I have not extensively
tested SoftID. If you ask most of your Security Dynamics salespeople,
they will tell you that these two devices encode the PIN in the
tokencode to create the passcode. I've even heard one go so far as to
claim it encodes it in a "secure hash."
The truth is a bit more simplistic than that, and may, in my opinion,
represent a possible danger to the wellbeing of your current strong
authentication scheme.
I. The PinPAD
The PinPAD is laid out within the same form factor as a regular
"standard card." It is approximately 4 inches long by 2 inches high
and has its LCD display placed in the upper right hand corner of the
front placard. Examination of some destroyed cards handed around as
demo units by the SDI sales force reveals that at least some of these
"standard cards" use the same internal circuit board as the PinPAD,
but lack a small row of chicklet-type contact switches.
These switches, on the PinPAD, allow a user to enter their PIN on the
unit, compute it, and clear the display. There are 10 switches in the
lower half of the card, labeled from 1-9 and 0 following. Below these
numbered switches are two others, marked with a gold letter "P" and a
diamond. The diamond is what instructs the card to compute the
passcode based on the currently entered PIN. It should be noted that
if no numbers have been entered, this button does nothing. The "P"
button purges the computed passcode from the display of the card, but,
as you will see, does not prevent one from determining it in the
minute following its entry.
The PinPAD, like every other time-factor authentication device sold by
Security Dynamics, has an internal lithium battery-backed clock set to
the current time UCT (Greenwich time, or Zulu time for some of you).
This time, when computed against a unique cryptographic seed, provides
a pseudo-random number on the display. This number will match an entry
in the ACE/Server database for that particular unique token.
II. Observations about the PinPAD
On the surface, the PinPAD appears to work much as advertised. A
4-digit pin is apparently converted into a passcode number which bears
little resemblance to the original tokencode. For instance, if my
tokencode reads 159246 and I enter a PIN of 3339, it may very well
generate a passcode which looks like 382913.
It is well documented that a user of the PinPAD is not allowed to
choose a PIN which starts with a leading zero. The reason for this
becomes apparent when one enters a PIN consisting of all zeroes.
Original tokencode: 401203
Entered PIN: 0000
Derived passcode: 719423
The last number is somewhat interesting. It will be the next available
tokencode. In other words, the next known tokencode to the ACE/Server
will be presented in the display. It gets worse.
The token derives its time from UCT, which is -6:00 Central time. It
turns out that, when encoding the PIN inside the next tokencode, the
token uses the UCT hour to determine whether an addition or
subtraction should be used to encode the PIN. For instance, if the
time UCT is 8AM (even number), the token will increment the decimal
value by the same place in the PIN. If the time UCT is 9AM (odd
number), it will decrement the decimal value by the same place in the
PIN. The value for each place would roll over if the place exceeds 9
and not carry. For example:
Next tokencode: 389453
PIN: 7324
Time: 9:23 UCT
Passcode: 386777
III. Possible risks
I think it's fairly clear what the risks are when one considers that
the PinPAD user is essentially sending over the line an obsfucated PIN
inside the NEXT VALID TOKENCODE. If an attacker obtains a PIN somehow,
and knows the user of that PIN carries the PinPAD token, he or she
merely has to wait until that user attempts to authenticate with the
ACE/Server and parrot the transaction (just send a duplicate UDP
packet). The ACE/Server will, under its default behavior, wait a
second before authenticating for other packets. If the server receives
one, it requests the user authenticate again to prevent spoofing.
Unfortunately, by this time, the attacker has already computed the
PIN/next-tokencode passcode and sent it down the line, beating the
user to his or her own account.
Ironically, the "standard card" approach - which sends the
PIN+tokencode combination in the clear - appears to defeat this by
simply not revealing the next tokencode as part of the passcode.
Consider this a matter of security through obscurity, not obsfucation.
:>
IV. Fixes
There are several ways to fix this problem. Two of the foremost would
be:
1. Security Dynamics could change the PinPAD to choose an "offset"
tokencode instead of the next-new tokencode. This would select a
tokencode which had been expired by 10-30 minutes or so. This code
would not be accepted for authentication later because it is too old,
but would be valid in this form.
2. The ACE/Server could be changed to put any duplicate connection
tokens in "next tokencode mode" twice, which would prompt the user two
enter the next TWO tokencodes before being authenticated. This would
pass over the revealed codes.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:17:35 PDT