[107603] in Cypherpunks
iang's palmpilot auth system (was Re: ArcotSign Software Smartcard)
daemon@ATHENA.MIT.EDU (Ryan Lackey)
Tue Jan 19 12:48:58 1999
Date: Tue, 19 Jan 1999 13:30:07 -0400
From: Ryan Lackey <ryan@venona.com>
To: iang@cs.berkeley.edu, Robert Hettinga <rah@shipwright.com>,
dbs@philodox.com, cypherpunks@algebra.com, marlin@arcot.com,
minow@pobox.com
In-Reply-To: <v04020a1fb2ca5f56dbf1@[139.167.130.247]>; from Robert Hettinga on Tue, Jan 19, 1999 at 11:12:11AM -0500
Reply-To: Ryan Lackey <ryan@venona.com>
Also Sprach Martin Minow (minow@pobox.com)
> At the same meeting, Ian Goldberg previewed his talk to the
> RSA conference. His approach relies on a Palm Pilot to hold
> the secret information. The advantage is that the Palm Pilot
> is small enough to be portable, of limited functionality (hence
> presumably less sensitive to external hacking), and provides
> a user interface (so the user doesn't sign rogue messages.
>
> Ian's approach, however, is vulnerable to attacks through the
> Palm Pilot's backup mechanism: If I can put my Trojan Horse on
> the computer you use for backup, The Pilot's own backup utility
> will install it on the end-user's PDA.
It is perhaps reasonable to assume for some applications that the palm pilot
itself will not be at risk from trojan horses -- the user dedicates the
palm pilot to authentication, never plugs it in to a computer, etc.
One of the more interesting attacks which Ian might be defending against
is the threat of a malicious party cloning the palm pilot, inserting what
amounts to a "wrapper" around the real palm pilot, simulating
the cloned palm pilot in software, such that the the user's input goes
through a MITM. The only real way of defending against this is to have
a secured conduit between the user and the authentication device -- direct
I/O on a tamper-resistant token. This means the device itself has to be
difficult to replicate. It's a very tricky problem, using stuff like a palm
pilot which can be relatively easily duplicated, but in custom hardware I think
the ideal is to have a precisely measured box (1cm x 4cm x 9cm for Clarke
commemeration, perhaps), which is entirely tamper-resistant -- any attempt
to open it destroys the internals. Then, buried deep inside is a
challenge-response system (perhaps a list of secrets, or some simple
cryptographic function -- this is up to the human factors people as to what
is possible). Any attempt to extract the secret from the core of the device
destroys the secret. The user then enters a faraday cage with the device,
ensures that all other untrusted devices inside the faraday cage are rendered
non-operational, and executes the challenge-response authentication protocol
with the device, if an only if the device meets rigid and directly-verifiable
standards for being a potentially good device (right size/volume). If the
challenge-response protocol is successful, the device is good, otherwise it
is a malicious device, and is destroyed before the faraday cage is opened.
This is pretty much overkill for all but the most paranoid people in the
world, though. (I can't think of any compromise if one wants ultimate
security, however.) It is essential that the protocol be conducted
in an environment which allows no interactive communications with the
outside world, that the device be trusted or not be provided the ability
to communicate sensitive information it has picked up to the outside world
(it's unclear if the failed challenge-response is actually information,
but it may be...it depends on if the challenges are ever reused). If you
could shave off even a millimeter from the case housing, you could potentially
put your own transparent sensor array over the keypad and screen, connected
to a miniscule processor on the back. If the challenge-response protocol
is not executed first, the device could be wholely fraudulent, not actually
functional, but pick up commands and data entered by the user for later
replay, perhaps simulating successful responses.
>
> At the Cypherpunks meeting, I gave an overview of the Dallas
> Semiconductor Java iButton <http://www.ibutton.com/>. This
> provides a SmartCard (with Java and a hardware implementation
> of the modular exponentiation function) enclosed in a
> tamper-resistant container. While I haven't implmented anything
> significant on the iButton, you should be able to do PGP-style
> key-signing without the risk of your key "leaking" out of the
> secure environment.
The iButton is effectively the best smartcard ever invented. It unfortunately
doesn't have direct user i/o, and the most unfortunate thing is that it
requires more voltage to drive the serial line than most laptop computers
seem to put out :(
If Dallas ever made a 3.3v-compatible iButton, it would be amazing.
