Security Dynamics PinPAD problem?

[jmoses () DTTUS COM (Joel Moses)]

     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.