1. 11/18/2003 Smart Card Authentication Mechanism Tim W. Baldridge, CISSP Marshall Space Flight Center Office of the Chief Information Officer

2. 11/18/2003Page 2 Overview o A Token must provide interoperable, enhanced security compared to magnetic stripe and similar serial data transmission security technologies o The Token encoding must be highly tamper, counterfeit and cloning resistant o The Token Unique Identifier (UID) and Identification data are free read and may be optionally validated and authenticated o Identification data is formatted as 25 byte packed SEIWG 012 string for legacy compatibility o A Token UID and data is validated using a free read Message Authentication Code (MAC) o Optional internal token authentication is for high security protection profiles and applications

3. 11/18/2003Page 3 Overview (cont.) o A Token is issued to a Holder by a home of record Issuer in an Enrollment process following the Federal Identity Credential model o Issuer policy defines a level of assurance associating a Token to a Holder o The Issuer manages the data structure and contents of issued Tokens o The Issuer maintains and does not reveal master Token and application write access secrets to a holder or other party.

4. 11/18/2003Page 4 Overview (cont.) o A Holder initiates an Access Transaction to a Physical Access Control System (PACS) application which has free read to Token identification (SEIWG) and validation (MAC) data o A Holder initiates a Enrollment Transaction to access a PACS or related support system in cooperation with or independent of the Issuer according Issuer policy and token configuration o An Enrollment Transaction is distinct from an Access Transaction

5. 11/18/2003Page 5 Assumptions o No change to existing PACS except field replaceable readers compatible with new Token technology o Validation and Authentication is optional and may be performed at the reader, panel or system o Validation and Authentication data must not interfere with PACS authorization mechanisms o Three protection profile levels are described: Low, Medium and High

6. 11/18/2003Page 6 Protection Profiles o Low – Basic Interoperability o Free read SEIWG string o no validation or authentication o Medium – Validated Data o Free read SEIWG String o Free read MAC, reader computes and validates MAC o High – Authenticated Token o Free read SEIWG String o Free Read MAC, reader computes and validates MAC o Token Authentication from MAC derived token key

7. 11/18/2003Page 7 High Security Use Case Constraints o High security function, i.e. authentication, is optional for both tokens and readers o Higher security tokens can be used transparently in lower security profiles o High works with both Medium and Low o Medium works with Low o High security profiles require o Token key write and key export prevention o Reader true random number generator (for cryptographic challenge)

8. 11/18/2003Page 8 Message Authentication Code (MAC) o By design a MAC is unique to every Token for every PACS secret o The Token must store a separate MAC for each PACS secret to validate the Token UID and Holder Identification SEIWG string o A MAC is used only to validate a Token UID and Identification data and is not used to determine authorization for access o Each PACS may have one or more secret keys that are unknown to any other system or authority, these secrets must be used to generate the unique MACs for every Token that will be validated and authenticated by a PACS

9. 11/18/2003Page 9 Message Authentication Code (MAC) o The MAC is generated by concatenating the Token Unique Identifier (7 bytes) and the SEIWG string (25 bytes) then performing a 3DES CBC – Send Mode Enciphering with a initial vector of 8 X 0x00 and a 16 byte secret key o The MAC value is the first 4 bytes from the last stage of the CBC enciphering o In an optional high security profile the token key is a 3DES enciphering of the applicable MAC o In a high security profile a PACS may use the same or different 3DES key to encipher the MAC for the token Key

10. 11/18/2003Page 10 MAC Data Model o Managed MACs are stored as a concatenated list under a single TLV in the same EF (elementary file) as the SEIWG o Security MACs, if present, are managed by the Issuer and are stored with additional token specific data under a single TLV in a separate EF o Un-managed MACs, if permitted by policy, are stored as a concatenated list under a single TLV in a separate EF. o If Security or Un-managed MACs exist on the token the EF FIDs are specified with a TLV in the same EF as the SEIWG to enable chaining to both the Security and the Un-managed MACs

11. 11/18/2003Page 11 MAC Data Model o Managed and Security MACs are only written by the Issuer and are protected from otherwise unauthorized modification o Un-managed MACS are free write to the maximum size of the EF and are written cyclically in a FIFO replacement o Both the Managed and Un-Managed MAC TLV lists are always n X 4 bytes where n is the number of MACs in the list o The Security MAC list is (n+m) X 4 bytes where n is the number of MACs in the list and m is the number of token specific authentication bytes (i.e. AID, FID, and key number as required)

12. 11/18/2003Page 12 Access Transaction - Medium o REQA o RATS – Returns UID o Select File (0007 or 3000) o Read Binary o SEIWG o Managed MACs o Secured MACs FID + Token type + Algorithm (optional) o Un-Managed MACs FID (optional) o The reader internally generates a MAC from the Token UID and SEIWG, then compares for a match in managed MAC list o If no match is found in the Managed MAC List and If a Secured MAC FID TLV exists it is checked first in the High Security Access Transaction o If the Secured MAC FID TLV does not exist or the reader generated MAC does not match an entry on the Secured MAC list then o Select File (Unmanaged MACs FID) o Read Binary o Reader compares internally generated MAC to the Un-Managed MAC list, o If no match on any of the three lists, validation fails o Authorization is determined by the PACS using SEIWG identification data

13. 11/18/2003Page 13 Access Transaction - High o REQA o RATS – Returns UID o Select File (0007 or 3000) o Read Binary o SEIWG o Managed MACs o Secured MACs FID + Token type + Algorithm (optional) o Un-Managed MACs FID (optional) o The reader internally generates a MAC from the Token UID and SEIWG, then compares for a match in the managed MAC list and fails, and if the Secured MACs TLV exists o Select File (Secured MACs FID) o Read Binary o Secured MAC List (MAC + AID + FID + key no) o Reader compares internally generated MAC to the Secured MAC list, o If no match or the Secure list does not exist, the Secure validation fails and the Un-Managed MAC list is processed according to the Medium level Access Transaction o If a match on the Secure MAC list exists, a reader key is used to encipher the reader generated MAC creating the token specific internal key o Reader internally authenticates token using the generated token key o Authorization is determined by the PACS using SEIWG identification data

14. 11/18/2003Page 14 Managed Enrollment Transaction o The Holder contacts Issuer for validated access to the requested remote system o The Issuer proxies the request, including Token UID and SEIWG, to remote system; if accepted the remote system returns MAC to the Issuer o The Issuer records pertinent data and writes MAC to managed MAC list on Token o The remote system authorizes access as appropriate using the SEIWG for identification

15. 11/18/2003Page 15 Un-Managed Enrollment Transaction o The Holder presents card for non-Issuer enrollment to a remote system o The Holder presented identity is verified by a remote system security officer o The MAC is generated from Token UID and SEIWG and written to the Un-managed MAC list if present o If the Un-managed MAC list is not present then the Token UID and SEIWG identification data validation is not possible o The Remote system authorizes access as appropriate using the SEIWG for identification with or without validation

16. 11/18/2003Page 16 Secure Enrollment Transaction o The Holder contacts Issuer for authenticated access to the requested remote system o The Issuer proxies the request, including Token UID and SEIWG, to remote system; if accepted the remote system returns the MAC to the Issuer o The Issuer records pertinent data and writes the MAC and token specific data to the Secure MAC list on the Token o The Issuer creates an EF (AID, FID and Key Number) on the token and provides a key to the remote system for Token specific key injections access the specified EF o The remote system verification officer verifies Holder identity and injects token key to complete enrollment o The remote system authorizes access as appropriate using SEIWG for identification

17. 11/18/2003Page 17 Risks o Generating a MAC cannot prevent token cloning. However the MAC is an effective measure against data tampering of an issued credential. o The only effective measure against token cloning is an internally computed token response to a random external challenge o Internal token authentication for contact-less token technology remains proprietary o Contact-less Token authentication technology interoperability cannot be guaranteed or mandated at this time and may require matched contact-less tokens and readers