From the Radio Free Michigan archives ftp://141.209.3.26/pub/patriot If you have any other files you'd like to contribute, e-mail them to bj496@Cleveland.Freenet.Edu. ------------------------------------------------ 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 Radio Free Michigan site by the archive maintainer. All files are ZIP archives for fast download. E-mail bj496@Cleveland.Freenet.Edu)