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:jmosesat_private]
Sent: Wednesday, September 23, 1998 4:45 AM
To: BUGTRAQat_private
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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:17:47 PDT