Implementing a FIPS 201-Compliant Physical Access Control System

A physical access control system (PACS) has many benefits, foremost among which is the use of mature and proven technologies that can strengthen the trust relationship between an organization and an employee and enhance the security for personnel entering, leaving, or working within a building. As a result of Homeland Security Presidential Directive 12 (HSPD-12) and the publication of the Federal Information Processing Standard Publication 201 (FIPS 201), Personal Identity Verification (PIV) of Federal Employees and Contractors, Federal agencies are moving quickly to implement FIPS 201-compliant identification processes and systems. This article summarizes the components and operation of a typical FIPS 201-compliant PACS.

A typical FIPS 201-compliant PACS is composed of the following components:

PIV card
PIV card reader/keypad
Biometric reader [1]
Control panel
Access control server
Cardholder data repository
Control points [2]

Essential to the understanding of a FIPS 201-compliant PACS is an understanding of the basic card used to request physical access. The PIV card is the physical artifact issued to an individual that allows the claimed identity of the cardholder to be verified. The PIV card stores a cardholder photograph, cryptographic keys, biometric data and the cardholder unique identifier (CHUID). The card allows the identity of the cardholder to be verified. The card is presented to a card reader to initiate an authentication transaction and to request access authorization.

FIPS 201 requires that the PIV card be a smart card. The card body is similar to a bank credit card and conforms to the ISO/IEC 7810 specification. The card must contain both contact and contactless interfaces, which may be provided by two separate integrated circuit chips (ICC) or by one dual-interface ICC. The contact interface must conform to the ISO/IEC 7816 specification, and the contactless interface must conform to the ISO/IEC 14443 specification. In most cases, physical access applications will use the contactless interface, although there are special cases in which the contact interface will be used for physical access.

The card reader provides power to the card's interface and reads the electronically stored cardholder information from the card. This information may be the entire CHUID or portions thereof. Certain cardholder information may be read-protected and require a personal identification number (PIN) for read access. Once the data is read, the reader sends the information to the control panel.

The control panel is clock-synchronized and connected to the access control server, card reader/keypad, and control point hardware. The control panel receives the information from the card reader and compares it to data stored in its database. After the control panel determines that the data is valid, it compares the information to the access privileges in the local database registered to the cardholder and makes an access decision. This decision is based on criteria such as credential status, expiration date, day of the week, time of day, and control point location. The control panel sends the decision to the access control server to be displayed and logged. The door lock (or other control point) receives a signal from the control panel to unlock the door or inform the PIV cardholder and system that access has been denied. All successful and unsuccessful access attempts are typically logged by the PACS.

FIPS 201 assurance levels specify verification of the authenticity of both the card and the encoded data stored on the card. This is different and separate from verifying the authenticity of the person holding the credential. The assurance levels, titled some confidence, high confidence and very high confidence, represent different authentication processes. The process above describes the some confidence level.

The FIPS 201 high confidence level requires biometric comparison of a fingerprint captured and encoded on the credential during the card-issuing process and a fingerprint scanned at the physical access point. [3] If the biometric data stored on the card is the fingerprint image, then this data is only accessible through the PIV card's contact interface. Image data is also PIN-protected and requires the individual to enter a PIN before the reader can access the data on the card. For PACS implementations that use biometric templates (instead of images) stored on the PIV card or in an agency-specific data repository, agencies can set their own policies for biometric access.

The very high confidence level requires that the process described above is completed at a control point attended by an official observer. In addition, site-specific asymmetric keys in both the card and reader are required to authenticate the encoded data. Agency-specific PKI keys are verified after the PIN is entered and before any further data exchange occurs between the credential and reader.

The access control server is an administrative tool used to register and enroll a cardholder's name, access privileges, and expiration date in the cardholder data repository. The cardholder data repository manages PIV cardholder physical access privileges. The server downloads the CHUID (or portion thereof), access level, and authorized functions to the access control panel. It also allows a system operator to temporarily assign a credential and access privileges to visitors or employees who forgot or misplaced their cards. Other data, such as a control point description (e.g., "Door 412, Communication equipment room") is entered and displayed to the system operator. The server maintains an active history (log) file of all events that occur in the PACS.

The access control server can also be used as a situation awareness tool. Different manufacturers offer different PACS features. Some systems integrate functions such as event-triggered closed-circuit TV (CCTV) cameras and video recordings. In these systems attempts at unauthorized entry would activate CCTV cameras for real-time assessment. Some systems can display the cardholder's digitally stored photograph on an operator console when the card is presented to selected readers. This allows an operator to compare the live person using the credential with a photograph of the cardholder recorded at the time of issuance. The operator, often a guard, can then manually provide access through a control point for the individual.

Revocation or temporary suspension of physical access privileges can be triggered by the local PACS, by a central identity management system (IDMS) database, by the card management system (CMS), by a system operator, or by an automatic event such as an expired card. Whatever the trigger, processes that update and synchronize credential status in affected databases and systems must be in place to ensure that PIV card status is accurate and valid.

The following figure illustrates the components in a typical PACS.

PACS Enrollment and Privilege Granting

An individual's PIV card must be enrolled in an agency's PACS before the individual can use the card for access. Agencies and departments will have different implementation approaches to PIV card enrollment, depending on their security requirements, their PACS, and their use of credential data. Different approaches can be taken in a variety of areas, ranging from how cards are enrolled and registered for physical access privileges to what data is entered in the PACS server database, to what data is used at the control points (e.g., doors, gates).

For example, one department may require data to be "pushed down" from the central identity management system to the PACS server's user database, with pre-registration for physical access privileges. Another agency may simply need to know that the new PIV card will work in the current system, while a third agency may want simply to read the serial number of the PIV card.

All of these implementations reflect different realities and unique agency perspectives. The only requirement common to all implementations is that they include the capability to remove and revoke registered access privileges centrally, should a person move or leave the organization.

In general, enrollment into a PACS requires the following activities:

Cardholder demographic data must be entered into the PACS as required by the local security manager.
The CHUID or a portion thereof must be entered into the PACS.
The PIV chain of trust must be validated to the level required by the agency.
Access privileges must be assigned.

Each of these activities can be accomplished in different ways, depending upon factors such as the following:

Was the PIV card issued by the organization that owns the PACS?
Was the PACS used as part of the PIV issuance process, or was issuance done as part of a separate IDMS?
Was the PIV card issued by a different agency or department?
What are the data input/output/sharing capabilities of the specific PACS?

For enrollment within an agency, the necessary demographics and PIV card information can be entered into the PACS by either pushing the information from the agency's IDMS to the PACS at time the PIV card is issued, or by the PACS pulling the information from the IDMS when the individual presents himself to the security manager for assignment of access privileges following card issuance. The data could also exist in the PACS prior to issuance, if the PACS is used as a front-end for card issuance.

For cardholders from outside the agency (visitors), the local security manager could receive the needed data in advance of the visit by e-mail and then import it into the PACS or read it directly from the PIV card when the person arrives. As an alternative, visitors could upload the information themselves through a secure web site, using their PIV card PKI certifications for validation. In any case, the individual and the card are validated and local access privileges are assigned. The level to which the chain of trust for a card is validated is determined by the security and risk policies for a particular agency and a specific facility.

Conclusion

FIPS 201 and its associated special publications define many aspects for an interoperable Federal identity card. However, the standard also provides a variety of options for implementation and permits individual agencies to define their own approaches to meeting agency-specific access requirements. Federal agencies and vendors of products and systems are working together to develop migration plans that meet specific agency's needs and also meet the Office of Management and Budget (OMB) requirement for compliance with FIPS 201, Part 2, by October 27, 2006.

Notes

[1] A biometric reader is optional, but is required for high or very high confidence levels.

[2] A control point is defined as any device that is controlled by a physical access system (for example, doors, turnstiles, gates, lights, cameras, elevators). There may be multiple control points for a single access requirement.

[3] It is important to note that there is currently no final decision as to how the biometric data is to be formatted when stored on the PIV card. OMB has issued guidance that agencies may defer storing biometric data on the PIV card until NIST SP 800-76, Biometric Data Specification, is finalized.

About this Article

This article is an extract from the Smart Card Alliance Physical Access Council white paper, "FIPS 201 and Physical Access Control: An Overview of the Impact of FIPS 201 on Federal Physical Access Systems," researched and written by the Physical Access Council and published in September 2005.

Individuals from 36 organizations were involved in the development of this white paper. Lead contributors included representatives from: AMAG Technology, Anteon, Booz Allen Hamilton, Competech Smart Card Solutions, CoreStreet, Ltd., EDS, Fargo Electronics, GTSI Corp., HID Corporation, HIRSCH Electronics Corporation, IBM, Identification Technology Partners, Inc. (IDTP), InfoGard, Integrated Engineering, International Biometric Industry Association (IBIA), LEGIC Identsystems, Lenel Systems International, Inc., Lockheed Martin, MAXIMUS, MDI, NASA, Northrop Grumman Corporation, Precise Biometrics, SAFLINK Corporation, SAIC, SCM Microsystems, Shane-Gelling Company, Tyco Safety Products, U.S. Department of Homeland Security, XTec, Inc.

The full white and additional information about smart cards and the role that they play in secure identification and other applications can be found on the Smart Card Alliance web site at www.smartcardalliance.org .

About the Physical Access Council

The Physical Access Council [link to http://www.smartcardalliance.org/about_alliance/councils_pa.cfm ] is focused on accelerating the widespread acceptance, usage, and application of smart card technology for physical access control. The group brings together, in an open forum, leading users and technologists from both the public and private sectors and works on activities that are important to the physical access industry and that will address key issues that end user organizations have in deploying new physical access system technology. Physical Access Council participation is open to any Smart Card Alliance member who wishes to contribute to the Council projects.