Developing Trust with Credentials

• By Kim Rahfaldt
• Aug 21, 2012

When the National Institute of Standards and Technology (NIST) developed the FIPS 201 standard, the government was using Wiegand wire, magnetic stripe, proximity or barcode credentials as part of their physical access control systems (PACS).  Each of these technologies could be easily duplicated, making it virtually impossible to distinguish between a government-issued or forged credential.  There was limited “trust” in the authenticity of these cards. In this context, “trust” refers to the reasonable expectation that the card had been issued by a known entity, the status of the user had not changed with the issuer since issuance, and the card itself was authentic. NIST needed to establish trust in the validity and authenticity of the credential presented at the door, and that this was the same credential issued to the user.  Relying on the card number was not sufficient; therefore, NIST adopted an IT standard called Public Key Infrastructure (PKI), which required a digital certificate on the credential.  The card includes a pair of numbers:  a private key and a public key, and supports many other applications.   The private key is just that, private.  No one knows the private key.  The public and private keys are generated using a certified algorithm. Smart cards are the only cards that will support PKI requirements and digital certificates to enable trust and bidirectional communication.

Chain of Trust
The chain of trust starts with a known entity certifying or trusting a system to issue smart cards to its employees.  Often, a Federal entity is responsible for establishing this trust.  That entity, federal or otherwise, will then review the requesting department’s smart card issuance system to ensure it meets the necessary standards and protections so the system cannot be compromised.  FIPS 201 defines how card issuance should operate in a trusted manner.  If trusted, the department is granted a digital certificate.  All of the cards that are subsequently issued by that department will have personalized digital certificates that point back to the issuing system.  The chain of trust can be followed by validating the issuer’s digital certificate and following it back and so forth. 

The department continues the chain forward by tying identity and access control to the trusted credential.  An access control system, such as AMAG’s Symmetry™ Security Management System, validates the trust of the card.  It captures the card’s PKI and periodically checks to verify the digital certificate is still trusted by the issuing agency.  It pushes forward the chain of trust. If trust is broken in the future, the system stops trusting that card and denies access. The chain of trust must always remain intact.

Smart Card Benefits
Counterfeiting or duplicating a smart card credential is difficult due to the private and public keys associated with the card.  A digital signature is a piece of information associated with every data object on the card.  The card uses its private key to encrypt data that users want to read and stores the digital signature with the data itself.  Digital signatures prevent both unintended (communication errors) and unauthorized card modifications. 

For example, putting a different fingerprint on a card is difficult.  The card is still trusted by the chain of trust, and the authentication will still work, but when a relying system (an access control reader, for instance) reads the fingerprint template from the card it will recognize that the digital signature doesn’t match and should deny access or otherwise create an alarm.
           
The smart card can have multiple identifiers and multiple data storage units on it, which enables a single card to host multiple applications.  A smart card can be used for physical and logical access control, single sign on (store username and password data), to store electronic wallet information for transit functions, purchase items in a cafeteria, check out books or materials, etc., limiting the number of cards a person has to carry and the cost associated with maintaining multiple credentials.

How to Mitigate Attacks
Smart cards mitigate security attacks, making them the intelligent choice for government programs.

• Clone Card- The card authentication private key can never be re-created.  The clone attempt will fail the challenge/response, making it virtually impossible to clone a card. 
• Modify Card- When the digital signature does not match it identifies the card has been modified and disrupts the integrity of the chain of trust.
• Revoked Card/ Certificate Validation Response- A revoked digital certificate will be seen during periodic validity checks and, in case of a PACS, the card will be made inactive and the individual not allowed access.
• Man in the Middle (Future encrypted communications) – By using encrypted data, it prevents devices from stealing card information.  PIV cards are also supposed to be issued with special badge holders to absorb RF transmissions eliminating unexpected communication with external systems.

Card Comparison
Throughout the numerous branches of government, there are several different programs using smart cards with PKI.

The Personal Identity Verification (PIV) program is the largest program.  Issued by the federal government to employees and long-term contractors, the PIV program supports approximately two million government employees, two million federal government contractors and four million enlisted service men.  PIV is trusted per FIPS 201 and utilizes the Federal Agency Smart Credential Number (FASC-N) as its primary unique identifier.  PIV credentials are authenticated via the Federal Bridge.

Personal Identity Verification Interoperable (PIV-I) cards are issued to non-federal employees requiring a trust connection to government, but that do not warrant a PIV card, many of which may be working under the support of government contracts that are anticipated to be less than six months in duration.  PIV-I uses the Global Unique Identifier (GUID) as its primary unique identifier.  The PIV-I program is capable of expanding to municipal and state governments, and the commercial sectors, could eventually contain hundreds of millions of cards.  PIV-I credentials can also be authenticated through the Federal Bridge and trusted per Federal Bridge certification (certificate authority or CA).

The Transportation Workers Identity Credential (TWIC) is used at Ports and an estimated 1.5 million people have been issued the card.  TWICs are issued by the Transportation Security Administration (TSA) through a FIPS 201 compliant process.  TWICs also include an encrypted fingerprint template that can be accessed via the contactless interface.

The First Responder Authentication Credential (FRAC), which is based on the PIV-I model, is issued to firemen and emergency medical crews who respond to accident, explosions or mass casualty situations.  The police create a perimeter to keep people out of the area.  FRAC identifies who can pass through a perimeter, and what their role is at the scene of the incident.

The Commercial Identify Verification (CIV) card is similar to PIV-I and compatible with PIV hardware, but the certificate chain of trust may not reach back beyond the local, let alone to the federal government.  The CIV allows commercial enterprises to forgo the federal connection which saves a lot of money, but comes with the benefits of the PIV-I credential.  It can be used on all GSA APL equipment that supports PIV-I, but is only trusted locally.

For airports the Biometric Airport Security Identification Consortium (BASIC) and Aviation Credential Interoperable Solution (ACIS) are two programs that are currently being defined. Both programs are based on PIV-I model and will most likely be trusted by the federal government.

All programs utilize smart cards with PKI.  While some programs are connected with the federal government, others are not.  They all were built on the FIPS 201 formulation, therefore, the same types of hardware can be used.  A large percentage of the population falls into one of these categories, therefore hundreds of millions of cards will be needed as programs develop.  

Challenges
There are many challenges to PACS and LACS that are not presently designed to use PKI or otherwise support the PIV program.

Long Card Numbers.  PIV-I and all card programs based on PIV-I, are not going to use the FASC-N as the global unique identifier.  Many systems used the FASC-N as the identifier because it was unique within the federal government.  Now the GUID is the new identifier on PIV-I cards. The GUID is much larger than the FASC-N.  The identifier grew from 56 bits of data to 128 bits of data, and the GUID number is 32 digits.  Many database applications were not designed for such a large number so modifications of existing systems are going to be required to support the GUID identifier.

When do you use the GUID or FASC-N?  If it’s a PIV-I card it’s easy because the FASC-N is encoded with several 9’s and not a unique number, so you would use the GUID.  The Federal government uses PIV cards that have a FASC-N and GUID, therefore, it is going to be on a site by site basis.  They may choose to use one or the other.

Deprecation of the CHUID.  The first version of the standard allows the card number, called the FASC-N to be read without any kind of encryption between the card and the reader.  Many PACS on the market today read the FASC-N and grant access.  FIPS 201-2, which is currently in draft form and under industry review, is expected to state that a free read of the FASC-N will provide little or no assurance. 

The FIPS 201 standard is changing, making it difficult for interoperability, which is the cornerstone of the whole PIV program.  In the upcoming version of the FIPS 201 standard, FIPS 201-2, the card authentication key (CAK), which is another digital certificate stored on the card, will be mandatory.  In the past it was optional and not often used, therefore, users can’t count on the data being available on all cards. 

Variants of the Card Authentication Key (CAK). There are different types of the CAK, Symmetric and Asymmetric, and they are not compatible.  To rely on the CAK, the reader has to support both capabilities. However, cards issued by an agency using Symmetric CAK will not be authenticated at another agency (no matter whether they are using Symmetric or Asymmetric CAK) because with Symmetric CAK the secret key is not shared.

Inconsistencies exist with use of the CAK and the PAK (PIV authentication key).  There are many digital certificates on the PIV card.  Two that are used most for authentication are the PAK and the CAK.  Often times, the choice to use one or the other is based on whether the card is read through the contact or contactless interface.  However, the Identity Management System that issued the cards does not treat them the same. To trust a card, use the CAK.  To trust a person, use the PAK. The PAK is used when someone is first registered in the PACS, however, at the same time PACS need to authenticate the card.  The industry is seeing a learning curve on how to use the CAK and the PAK. 

So the question becomes, how does the hardware know what to do and how to go forward?  Those are some of the challenges facing the security industry, and it is taking some federal government agencies and manufacturers longer than others to understand and implement.