 |
 |
 |
 |
November 2006 • Volume 11 Number 11
|
 |
|
Feature of the Month Migrating Physical Access Control Systems to FIPS 201 Compatibility With the planned issuance of millions of PIV cards to government employees and contractors in the near future, agencies now need to consider the changes needed to existing physical access control systems to achieve compatibility with the PIV card. This article, extracted from the Smart Card Alliance Physical Access Council white paper, "Considerations for the Migration of Existing Physical Access Control Systems to Achieve FIPS 201 Compatibility," provides guidance for how agencies can migrate and upgrade their current PACS to align them with the requirements of HSPD-12 and FIPS 201 end state compatibility. PACS Inventory There are many considerations for physical access control systems (PACS) under HSPD-12 and FIPS 201. One important consideration affecting organizations is the migration from existing PACS to new FIPS 201-compatible systems. What happens when some employees have PIV cards and some do not? How can the existing PACS accommodate the migration to FIPS 201 compatibility? Can systems be upgraded or must new systems be acquired? What security considerations are there? An important first step in PACS migration is the development of a detailed understanding of the capabilities of current PACS components. Agencies should evaluate their current systems and compile an inventory of the PACS equipment currently in use, including:
With this information, each component can be assessed for its ability to meet FIPS 201 requirements and to work with FIPS 201-compliant PIV cards and back-end authentication systems. PACS Assessment: Server Questions Can the current PACS server database be integrated with the agency PIV IT infrastructure? For physical access to facilities, an individual's identity has traditionally been authenticated locally by using paper or other non-automated, hand-carried credentials, such as driver’s licenses and ID badges. With few exceptions, PACS servers and cardholder databases are updated manually by a local PACS operator. FIPS 201 defines procedures for the PIV card lifecycle activities including identity proofing, enrollment, PIV card issuance, and PIV card usage. A wide range of mechanisms are employed to authenticate identity, maintain identity information and certificates, and implement revocation procedures to ensure that only authorized individuals have access to government resources. To automate FIPS 201 processes, PACS server databases must be integrated with the other components of agency PIV IT infrastructure. Modern PACS databases are often upgradeable. Several PACS suppliers and system integrators offer upgrade packages and services to facilitate integration to external IT resources. Agencies may also require the development of procedures to comply with the Federal Information Security Management Act (FISMA) before allowing a local PACS server to be connected to the agency IT network. The primary concerns that need to be addressed are: database structure; administrator and operator access policies; implementation of operating system security patches; system upgrades and change management. Agencies should contact the IT department for policy clarification prior to initiating PACS server upgrades. Can the current PACS server hardware be upgraded to interface with the agency PIV IT infrastructure? FIPS 201 provides detailed technical specifications to support interoperability among Federal departments and agencies. It is important to note, however, that the link from the reader to the server and server functionality is not specified; user agencies have the responsibility to implement the reader-to-server link and PACS server functions, as long as compatibility with FIPS 201 is achieved. Does the current PACS server database support multiple card formats for one single user? During a transitional period, existing as well as new FIPS 201-compliant readers may co-exist in one system. Until all existing equipment (e.g., cards and readers) is updated or replaced, one person may have both an existing card and a PIV card. The consequence in a PACS server is that each cardholder may have to be entered into the PACS database twice, once with the data read from the existing card and once with the data read from the PIV card (the Federal Agency Smart Credential Number (FASC-N)). Some PACS server databases are capable of registering multiple credentials for the same individual, while others may require a separate record for each card, even when they belong to the same individual. PACS Assessment: Control Panel Questions Does the current control panel require a facility code? PACS manufacturers often embed an 8-bit facility code number, 0-255, in their system control panels. The facility code precedes a 16-bit sequential or unique number, 0-65535, for the card. As a user presents the card to a PACS card reader, the card's facility code and sequential, or unique, number are read and transmitted to the PACS control panel for verification and authentication. When the facility code from the card matches the facility code stored in the PACS control panel, the sequential, or unique, number is verified and the system makes a decision to grant or deny access. When the facility code does not match, the PACS regards the card as alien to the system. The PACS then generates an error message and denies access. No further processing occurs. Can the current control panel accept the defined reader output from PIV cards as specified in the GSA FIPS 201 Evaluation Program? The most common data stream produced by PACS readers for current access cards is 26 bits of Wiegand data (8-bit facility code, 16 bits of data, 2 parity bits). A reader included on the GSA Approved Product List (APL) must produce 75 bits of data (48-bit FASC-N, 25-bit expiration date, 2 parity bits). An approved PIV reader must, at a minimum, transmit the 75 bits of data to the control panel. The PACS reader, panel, or server must process the 75 bits of data received from the card and reader. The 48-bit FASC-N (the unique ID number) and 25-bit expiration date must be checked for every access transaction. However, the expiration date may be parsed out of the data and checked either at the reader using card data or at the panel or server using the PACS database. The reader to control panel communication protocol and link are not specified by FIPS 201 and may be specific to a control panel. However, the GSA FIPS 201 Evaluation Program requires that PIV card data only be sent using Wiegand, RS232, RS485 or TCP/IP protocols. Existing PACS control panels must be updated to receive and process the longer data streams, or must be replaced. Can the current control panel accommodate both existing cards and PIV compliant cards? Initially, the card population at each site will consist primarily of existing PACS cards. As the number of people who are issued PIV cards increases, the number of existing cards will gradually decrease until all are replaced with PIV cards. During this transition period, it may be necessary for the PACS to process data from existing cards as well as from PIV cards. Does the current control panel have sufficient memory to support the additional data? Cardholder records stored in the control panel will require additional memory space to accommodate the larger amount of data required for each user in FIPS 201-compatible systems. In many cases, this may not cause a problem since control panels are seldom used to capacity. However, the difference between current memory consumption per cardholder record and memory required in a FIPS 201-compatible environment is significant. Each manufacturer has its own unique method for storing, accessing and utilizing cardholder-specific data. Control panels with complex feature sets also require additional memory space for each cardholder. The PACS system manufacturer should be contacted to determine the capacity offered in the specific PACS environment. PACS Assessment: Reader Questions Can current readers read the required data elements from the PIV cards? For contactless operation, FIPS 201 and SP 800-73 specify the use of ISO/IEC 14443 contactless smart card technology (readers and cards) for Federal agency PACS applications. According to the GSA Evaluation Program’s test protocol, all GSA APL-listed readers must be capable of producing a minimum of 75 bits of data (48-bit FASC-N, 25-bit expiration date, 2 parity bits), when reading a PIV card. It is important to note that, for PIV cards, the reader produces the same minimum 75 bits of data (48-bit FASC-N, 25-bit expiration date, 2 parity bits) whether it is a card-only reader or a multi-factor reader (card plus personal identification number (PIN), card plus biometric, or card plus PIN and biometric). Conclusion Migrating to a FIPS 201-compatible PACS is a significant undertaking that will be a long process for most Federal agencies. Smart cards and readers are just the tip of the iceberg in FIPS 201 deployments. Government agencies need to consider new enrollment and issuance systems, as well as PACS changes and integration with back-end authentication systems. This article covered the first phases of PACS migration to provide support for the new PIV cards that are being issued. By assessing current system capabilities and understanding the changes needed to support FIPS 201, agencies can develop a plan for migration – including what components can be upgraded and what components need to be replaced. The full white paper, "Considerations for the Migration of Existing Physical Access Control Systems to Achieve FIPS 201 Compatibility," includes worksheets, flowcharts and other tools designed to help agencies to develop a solid foundation for their migration plans. About this Article This article is an extract from the Physical Access Council white paper, "Considerations for the Migration of Existing Physical Access Control Systems to Achieve FIPS 201 Compatibility," published in September 2006. This white paper was developed to assist government agencies with the development of the initial PACS migration plan to support new PIV cards. Participants involved in the development of the white paper included: Actcom Security Solutions, a Diebold Company; BearingPoint; Booz Allen Hamilton; CoreStreet; Fargo Electronics; HID Corporation; Hirsch Electronics; Honeywell; ID Technology Partners; Integrated Engineering; LEGIC Identsystems; Lenel Systems International; Northrop Grumman; Precise Biometrics; Saflink; SCM Microsystems; U.S. Department of Defense/Defense Manpower Data Center (DMDC); U.S. Department of State. Additional information about smart cards and the role that they play in identity 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 is one of several Smart Card Alliance Technology and Industry Councils, which are focused groups within the overall structure of the Alliance. The Physical Access Council 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. Additional information on the Physical Access Council can be found at http://www.smartcardalliance.org/pages/activities-councils-physical-access.
|
|
