

Well, here it is.... finally! I was faxed the U.S. Card paper as
introduced at the CardTech/SecureTech Conference on April 30, 1994. The
document was faxed to me by the author, Chuck Chamberlain, of the U.S.
Postal Service. The number in Washington D.C. to reach Mr. Chamberlain is
202-268-2000 and his direct office number is 202-268-5262. There are
several things throughout this document that disturb me even though it is
just a general proposal. I will withhold my concerns until after this
document is released so as not to taint anyone's opinion and out of a
sense of curiosity to see if others bring up the same points.

This document was a fax to my fax modem and I plan to convert the document
to a series of GIF images for distribution so that all of the graphical
pages can be obtained by those who want them. At one point in the document
I lost about a half of a line due to what appeared to possibly be a paper
crease or fold. I don't think there was any extremely important
information in that half line.

I look forward to hearing comments on the text. Please feel free to
redistribute this as widely as possible. EFF has requested permission to
redistribute the previous information I had released and this message is
being forwarded to them.

Chris (chris.schrecengost@highway1.com) Founder - Patriot Information
Network

And... without further delay.... Ladies and Gentleman... The General
Purpose U.S. Services Smartcard.
------------------------------------------------------------------
[Page 1]

GENERAL PURPOSE U.S. SERVICES SMARTCARD (U.S. CARD)

C. R. Chamberlain

United States Postal Service

March 1994


1.1 INTRODUCTION

1.2 REQUIREMENTS

1.2.1 CITIZEN 1.2.2 GOVERNMENT

1.3 DESIGN

1.3.1 SMARTCARD ONBOARD FUNCTIONS 1.3.2 SUPPORTING INFRASTRUCTURE
1.3.1 SUMMARY

1.4 OPERATIONS

1.4.1 ACQUIRING & ACTIVATING THE U.S. CARD
1.4.2 GRANTING LIMITED ACCESS TO OTHERS
1.4.3 MAINTAINING APPLICATION SUPPORT DATA
1.4.4 TRANSACTION AUDIT TRAIL 1.4.5 CARD REPLACEMENT

1.5 CONCLUSION


[Page 2]

1.1 INTRODUCTION

The paper describes a proposed set of functions for a general
purpose government services smartcard that the author believes
builds upon several initiatives already underway. The initiatives
include the recertification of DES, a proposed public key
infrastructure for managing public key certificates, government
agencies exploring the use of attribute certificates, initial
X.500 systems being built by government and private sector,
emerging requirements for a health care card and for an
electronic benefits transfer (EBT) card, adoption of a Digital
Signature Standard and a need to reinvent the delivery of
government services around such themes as "one-stop shopping".

The smartcard as a personal interface tool to National
Information Infrastructure applications enhances a person's
control of their data. Digital security technology such as public
key cryptography and digital signatures are used to secure the
integrity of the smartcard and its infrastructure. The smartcard
with an infrastructure that has directory services, user
certificates, public access terminals, personal identification
numbers (PINs) and up front issuance identification
authentication coupled with the smartcard's on-board features
provides a system for personal transactions that businesses, the
government and the individual can rely upon for privacy and
integrity.

1.2 REQUIREMENTS

Each party to smartcard usage, including businesses and foreign
governments, will bring their own set of requirements but those
of domestic U. S. government organizations and citizens are
briefly addressed here.

1.2.1 CITIZEN

Increasingly the use of electronic transactions enabled by the
smartcard will be paperless and subject to electronic remote
snooping. In order to protect the citizen and to not unreasonably
complicate life, the U.S. Services Smartcard (U.S. CARD) needs to
support:

1) Privacy - assurance exists that parties not approved for
accessing data on the card can not access the information.
Additional assurances are needed that unintended secondary uses
of the information generated through use of the U.S. CARD are not
allowed. Information may need to be generally available to a
functional area/industry (basic health care data for emergency
care) or to a subset of an industry (detail health test results
to doctors) but that information should not flow readily across
functional boundaries (health test results to bankers or
perspective employers).

2) Integrity - assurance that the data is accurate, can not be
altered accidentally or through unauthorized access.

[Page 3]

3) Intuitive Operations - the use of the card follows a logical
sequence able to be performed without training.

4) Personalized Interaction - ability to support English as well
as a different language of preference. Where literacy is a
problem, the U.S. CARD data should be machine readable and
machine spoken in the language of preference.

5) No Cost - the U.S. CARD is part of the government's
infrastructure and there should be no direct costs to the
citizen. However, a family of value added services may be enabled
by the U.S. CARD that might carry transaction fees such as
ordering goverment publications.

6)Replacements - the U.S. CARD must be able to be rapidly
replaced if lost, stolen or damaged.

7) Auditability - transactional uses must be logged and
reviewable to enable review of disputed transactions or just to
facilitate record keeping. This chronological log must be under
the control of the U.S. CARD holder and not available to any
organization without the holder's permission to prevent use of
the log for surveillance purposes.

8) One Card - a single card rather than several cards simplifies
the carrying the card and always having the right card for
interacting with the government.

[Page 4]

1.2.2 GOVERNMENT

1) Integrity - assurance that the data is accurate, can not be
altered accidentally or through unauthorized access.

2) User Authentication and Transaction Repudiation - assurance of
the identity of someone doing business with the government and
the ability to enforce the validity of a transaction after its
completion. These qualities help prevent fraud.

3) Intuitive Operations - the use of the card follows a logical
sequence able to be performed without training.

4) Cost Performance - the cost of providing the U.S. CARD must be
no more than a few dollars per citizen per year with costs
recoverable through reengineering services to much lower total
service delivery costs enabled by the U.S. CARD and its
infrastructure.

5) Improved Service to Citizens - easy to use 24-hour service
electronic access to government services.

8)Single Face to Citizens (One Card) - consolidated operations to
lower costs and maintain an ease of use.

9) Expandable for New Uses - existing or upgradeable capacity to
handle new applications or increased functionality.

10) International Acceptance - a standard U.S. CARD that can be
used by U.S. citizens overseas and interoperable with similar
foreign systems where advantageous.

[*Note: Items 6 & 7 were missing from the copy that was sent to
me by the Postal Service.]

[Page 5]

1.3 DESIGN

1.3.1 SMARTCARD ONBOARD FUNCTIONS

Some onboard capabilities may need to be resident off the card
initially until an economical card with sufficient capacity is
available. A high quantity buy of 100-200 million U.S. CARDs,
necessary for government services, will drive the price of the
card downward and serve to accelerate technological innovations
to further assist in driving costs down on any subsequent orders.

1) Digital Signature Generation and Use - Generation of the
user's Digital Signature key pair will take place on the U.S.
CARD with only the public half of the key able to be read from
the card.  Software functions requiring use of the private key
must happen on the card to keep the private key from being read.

2) PIN Activation - Basic security for using the smartcard will
be through entry of a PIN before data can be accessed. Repeated
entry of a non-valid PIN to access the card will result in
locking up the card or erasure of its data. The PIN will be
installed on the  card in space unaddressable from outside the
card in the same manner as the private key. The cardholder should
be able to select their own PIN for ease of use. However, it may
be more practical to generate the PIN at time of chip manufacture
and to store it on the chip at that time. Depending upon the
types Of threats placed against the card, it may be advantageous
to not store the PIN on the card but to use the PIN (input by the
cardholder each time the card is used at the start of the service
session) to generate an encryption key to decrypt the card's data
as needed. If a certain functional area's data is the subject of
the service session, then the PIN plus some trailer related to
the function (such as H for health care, F for finance, LE for
law enforcement or none for reading the card's index) may be used
to generate an unique key for each functional area to prevent
someone from browsing unrelated areas. As threats become more
sophisticated, the prevention methods will also have to evolve to
stay a step ahead.

3) Identification Certificate - an X.509 format certificate
issued by a trusted certificate granting authority that contains
an electronic signature/digital signature of the U.S. CARD holder
as well as other data such as name and address will be stored on
the card for identifying the cardholder and to digitally sign
electronic transactions.

4) Attribute Certificates - certificate issued by a company or
industry representative that identifies the U.S. CARD holder as
having certain credentials or status's such as government
contracting authority, government driver's license, pilot's
license or benefits entitlement. Attribute certificates will also
be accessed for entities requesting access to application data on
the card to verify their logical need for the data.

5) Applications Support - industry or application specific data
storage for a set of records unique to a functional area or
industry such as records for financial accounts, identification

[Page 6]

of physicians for health care or military service id for access
to veterans benefits. An applications program interface (API)
will be resident on the card to control access to the onboard
records and to help link it to external systems.

6) Transaction Log - chronological log of transactions that the
U.S. CARD holder can copy or, print off the card for maintaining
a transaction history. A standardized format for the transactions
will identify parties to the transaction, date, time, type of
transaction, etc.

1.3.2 SUPPORTING INFRASTRUCTURE

1) Off-Card Database Linkages - the U.S. CARD will maintain
minimal data on the card itself but will enable and authorize
secure electronic linkage to databases that contain the data such
as bank accounts, health files including digital medical records,
driving records, employee history, etc. Data will be maintained
in an updated state by those applications rather than relying on
the U.S. CARD to always have the most recent data and to store
the large volume of data required. The U.S. CARD holds an index
accessible via the API that identifies, and opens access and logs
activity to the U.S. CARD holder's data.

2) U.S. CARD Central Authority - operation for issuing and
reissuing the U.S. CARD, maintaining the central database,
establishing a card access device network and creating the API
for interfacing with the card.

3) Card Access Devices - terminals such as personal computers,
transaction phones with screen displays or public accessible
devices such as kiosks to provide the U.S. CARD holder with the
ability to access data on the card and in some cases update it.
The ability of the card holder to review their data will give
them greater control on maintaining the accuracy and completeness
of their data.

4) Standards - a standards setting process with input from all
interested parties, both domestic and international, is necessary
to help ensure the widest possible acceptance of the U.S. CARD.
Standards need to cover such aspects as access methods, data
formats and storage, and architecture.

5) Directory Services - database of U.S. CARDs including all
active cards, invalid cards and information needed to administer
the U.S. CARD program. On-line real-time inquiries will be
supported to validate the card's use in a manner similar to
today's credit card process. The directory services will at least
initially be provided in a centralized manner. This will enable
rapid system updates as it evolves quickly during its initial
period of operation. Efforts will then be concentrated on
extending the central system, by distributing some of the
functiona where advantageous. Future distribution or replication
of the database would be based upon X.500 standards. A
centralized system will assist in providing fast inquiry speeds
necessary for real-time transaction systems rather than having to
perform multiple searches to find the right database for
processing the inquiry.

[Page 7 is blank]

[Page 8]

1.4 OPERATIONS

1.4.1 Acquiring and Activating the U.S. CARD

a. individual receives a U.S. CARD through the mail and in a
separate mailing receives a control number for initial use of the
card and to enter the PIN (or the actual PIN for the card if the
PIN needs to be preloaded for security) that they desire to use.

b. Individual takes their U.S. CARD with personal identification
to a post office and after proving their identity to a postal
employee, several things happen using a card access device.

1. public - private key pair is generated on the card
2. public key is encapsulated in an X.509 certificate on the card
that may require additional data entry by the Postal Service or
the cardholder
3. X.509 certificate is added to the national database
4. individual uses the mailed control number to initialize their
U.S. CARD PIN unless PIN was preloaded

1.4.2 Granting Limited Access To Others

When conducting basic transactional functions, the U.S. CARD can
be enabled by entering the user's PIN in a manner similar to that
used for debit cards today, For higher level functions, the
following steps are anticipated:

a. Cardholder enters card into card access device and activates by
entry of the PIN. b. Card's API displays directory of functions
possible from the card.
c. Cardholder selects the appropriate function and opens by
reentering the PIN, the DES key unique to that application is
unlocked for the API to use for the selected function.
d. Activity happens corresponding to the selected function, and if
asked for the identity of the person or business that is the
second party to the activity is captured . If attribute
certificates should be available for the second party then they
are verified prior to granting access.
e. A log record is stored on the card representing the activity before
the activity is completed, if the activity is later canceled the log
will be updated accordingly. f. If the card is extracted from the
card access device or an eritry made to close the activity, the
process would need to start over from the beginning.

1.4.3 Maintaining Application Support Data

The U.S. CARD will contain an operating system capable of
allocating protected areas for discrete applications. A standard
record for each industry/function will be adopted (X.I2 and X.435
record formats to be considered for use) and used to enable
interoperability of

[Page 9]

the card. The identity certificate and attribute certificate of
any party updating the onboard record will be verified against
the national database before the record can be updated. The
update activity will be logged on the card and the database
inquiry will be logged in the national file. Application records
on the card will be each encrypted with a different DES key that
is unlocked usirig a combination of the user's PIN and the
selection of an existing or new application area.

The DES keys can be reset at any time by the cardholder by
selecting a "Security Refresh" operation from the API while the
card is in a card access device.


1.4.4 Transaction Audit Trail

The cardholder through use of the U.S. CARD log file and access
to it via the card's APT can view and transfer the transaction
log. The U.S. CARD support system will be able to receive and
handle electronic messages from disputed card transactions and
will resolve any problems. The cardholder may need to forward a
copy of a portion of their transaction log from a government
controlled card access device that will have an application that
will do an initial verification [approx half line illegible]
Recreation of the application records will be the responsibility
of the cardholder unless privacy interests can be satisfied with
keeping a master index of application record on a card or an easy
method is devised for inquiring application owners on behalf of
the cardholder to identify the application records that should be
recreated on the new card

A periodic replacement of the U.S. CARD is anticipated to
introduce new technology and to maintain low failure rates on the
cards. When the old and new card are both available, a transfer
of information utility will be available via an API provided
option using a card access device.

1.5 CONCLUSION

A PIN will be used to unlock the U. S. CARD. Basic debit card
type transaction will then be capable. By selecting an
application area and then reentering the PIN and verifying any
necessary attribute certificates of the second party, a DES key
will be provided for retrieving application specific records.
Logs will be maintained for auditability and a national database
for verification of the status of individual U.S. CARDs and card
users.

[Page 10]

Graphical page containing a graphic of a card mock-up.

[Page 11]

Graphical page showing a directory diagram.

[Page 12]

Graphical page outlining the requirements of the citizen and
government. (This is just a shortened version of the requirement
section of the document.)

[Page 13]

Graphical page outlining the infrastructure requirements. (Once
again, the same material as in the document.)

[Page 14]

Graphical page outlining the system of controls

[Page 15]

Graphical page diagramming the Postal Certification Authority
(PCA)

[Page 16]

Graphical page diagramming the card issuance scenario

[Page 17]

Graphical page showing the digital signature initialization.

[Page 18]

Graphical page showing the adavanced card usage scenario

[end of document]


------------------------------------------------
(This file was found elsewhere on the Internet and uploaded to the
Patriot FTP site by S.P.I.R.A.L., the Society for the Protection of Individual Rights and Liberties. E-mail alex@spiral.org)
