Smart cards can dramatically reduce password exposure by supporting a
2-factor, 2-step authentication mechanism (See, for example, J. Kohl
and C. Neumann, ``The Kerberos Network Authentication Service'',
Internet Engineering Task Force, Networking Group, Internet Draft RFC
1510, Sep 1993 or Marjan Krajewski, Jr., ``Smart Card Augmentation of
Kerberos'', Proceedings of the Privacy and Security Research Group
Workshop on Network and Distributed System Security, February 11-12,
1993, San Diego, CA, pp.119-123.).
With passwords only, a user must know one piece of secret information
-- the valid password for a principal name -- in order to log in to a
company cell. There is one step involved in authentication -- supply a
login name and its password to the system.
With smart cards, a user must possess a unique physical token -- the
smart card -- as well as knowing one piece of secret information -- a
password associated with the card. Knowledge of the card password is of
no use without possession of the card itself. Possession of the card is
of no use without knowledge of the associated password.
With passwords only, there is one step to the authentication process --
the user principal is authenticated to the computer. With smart cards,
there is an additional step involved -- before being authenticated to the
computer, the end user must be authenticated to the smart card. The first
step depends on knowing the correct password. The second step depends on
possessing the correct smart card -- the one containing the user's
long-term key.
Therefore it is hereby proposed using the smart card's secure file
system to store the user's long-term key. To access the key and log in
to the computer, a user must possess the card and must also know the
password required to access the key file on the card.
The details of this solution are contained in the following sections.
The card must conform to the accepted International Standards ISO
7816-1, ISO 7816-2, and ISO 7816-3.
The card must be tamper-resistant. Common tamper-resistance features
include: chip enclosed in a hard, opaque, tamper-evident sealing
coating over a passivation layer; circuitry to disable card output if
the passivation layer is removed or if temperature, voltage, or
frequency fluctuates outside the specified operating range.
Cards with higher levels of tamper-resistance generally have a higher
cost. The card issuer must evaluate with the card vendor the
appropriate level of tamper-resistance for the issuer's application.
Failure to provide adequate tamper-resistance makes the long-term key
stored on the card vulnerable to physical attacks, reducing security
when a card is lost or stolen.
The card file system must provide access controls that support the use
of a password to protect access to the file containing the key.
Passwords of up to 8 bytes in length must be supported. Without
presentation to the card operating system of the password associated
with the key file, there should be no access to the key stored in the
card file system. Failure to conform to this specification negates the
additional security that smart cards offer.
The card must support detection of sequential invalid access attempts
(a request for a protected card operation without supplying the correct
password for the operation). Upon detecting N sequential invalid access
attempts on any operation (where N may be configurable), the card must
deny all further access to all operations except for possibly one
``unlock/erase'' operation. This one operation, if supported, must
erase the key stored in the card file system before restoring normal
access to the card. Failure to conform to this specification leaves a
lost or stolen card vulnerable to off-line dictionary password-guessing
attacks. Accounts associated with lost or stolen cards are subject to
compromise until an administrator invalidates the account in the
Security Registry.
The card file system must support access controls that allow only the
user to modify the password associated with the key file (with the
possible exception described in the next paragraph).
An interesting implementation would have a way of providing administrative access to unlock/erase a locked card (see above), set a new key on the card and in the Security Registry, set a new card access password, etc., but that is a vendor-issue not required for the basic functionality specified here.