Re: Security Dynamics PinPAD problem?

[jbrainard () SECURITYDYNAMICS COM (Brainard, John)]

A few clarifications are in order here. Mr. Moses is correct that we obtain
the PASSCODE for PINPAD tokens by adding the PIN, without carry, to the next
tokencode. The attack he proposes, however, will not work. Details are in
line.

                                John G. Brainard
                                Principal Resarch Engineer
                                RSA Labs/Security Dynamics


        -----Original Message-----
        From:   Joel Moses [SMTP:jmoses () DTTUS COM]
        Sent:   Wednesday, September 23, 1998 4:45 AM
        To:     BUGTRAQ () netspace org
        Subject:        Security Dynamics PinPAD problem?

             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

        This is incorrect. The PIN is always added, without carry, to the
tokencode, regardless of the time.

             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.

        This is not correct. As soon as the ACE/Server receives a PASSCODE,
the time corresponding to the tokencode is stored in the user's database
record. Any subsequent requests with tokencodes corresponding to that, or
any earlier time, are rejected. The scenario goes like this:

        1) At 12:00, a user enters a PIN into a token. The token adds the
PIN to the tokencode for 12:01, and the result is sent to the server. The
server stores 12:01 in the user's record.

        2)The attacker sends a duplicate packet to the server.

        3) The server sends "Access denied, multiple simulaneous attempts."
to both the user and the attacker.

        4) The attacker subtracts the stolen PIN from the observed PASSCODE,
and sends the result (the unmodified tokencode for 12:01) to the server.

        5) The server finds the time corresponding to the received tokencode
(12:01) and compares it to the time in the user's record (12:01) since the
received tokencode is for the same time, it is rejected. The server sends
"Access denied, tokencode repeated." to the attacker.



             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.