Re: Smart card proposal

[DE Gustafson <degustafson () comcast net>]

Richard M. Smith wrote:

> < ... > What I still do not understand is how a Web site communicates 
with the USB key device.
> 
>

Token-aware browsers (Internet Explorer, Netscape, Mozilla, etc.) can be 
configured with PKI credentials (e.g., private key and corresponding ID 
certificate) that are stored either on the PC or on a smart card or USB 
token.  The client's private key is used during the optional (and server 
controlled) "SSL client authentication" protocol sequence.  The token 
must be  "online" at SSL/TLS connect time.  The user is prompted to 
enter his/her user PIN as needed to access the private key (which cannot 
be read from the token under any circumstance).  Use of certificates 
that have been issued by an Enterprise CA, etc. can help simplify user 
interaction.  For example, the secure website can inform the remote 
client/browser that it accepts client certificates issued by a certain 
CA or list of CAs.  In that case, other available client certificates, 
if any, will not be part of the site's user-authentication process.

It's important to remember that, SSL connections can be "resumed" for 
some (server-specified) period of time.  The user can revisit the secure 
site without additional token interaction.  Normally, this resume 
capability is invalidated immediately upon browser program close (since 
the client's copy of previously negotiated session parameters is 
deleted) or by expiration of the server/site defined time period.  This 
convenient but somewhat counter-intuitive property of the web browser & 
underlying protocol operation must be factored into secure application 
design.

So the web site communicates with a client machine and browser 
software.  Token operations occur indirectly through browser software, 
token middleware, and USB device drivers.

A couple of fun? details for future reference ...

Per current standards, smart cards/tokens can be configured with a 
"secondary authentication" PIN that must be presented each time a 
particular signing key is used to perform it's digital signature 
operation.  This "Signing PIN" may be distinct from the User PIN that 
controls general access to all protected objects on the card (private 
keys, certificates, data objects, etc.).  See the most recent version of 
RSA's PKCS#11 standard for details.  I believe Microsoft supports same 
or simlar via their CAPI interface.  Intended effect is "one digital 
signature per Signing-PIN presentation".

Some experts believe that, in some environments, the user's PIN should 
be entered through a specially designed reader that protects the PIN 
from being captured (by keyloggers, etc.) -- see "protected 
authentication path" in PKCS#11.  Several vendors have fielded readers 
with a PINPad capability that allows the PIN to be entered directly 
through the reader unit (e.g., bypassing the client workstation).

If / when such capabilities will be sufficiently viable in commercial 
products appears to be an open question.

HTH.

Best,

--dg


Dale Gustafson
Future Foundation Inc.
Secure Application Consulting & Design
+1 651-452-9033 office
+1 218-343-9724 mobile
+1 202-473-9481 onsite/DC