As physical access control systems (PACS) constantly evolve, there are a number of functional requirements to support standards-based strong authentication and industry best practices.
Physical Access Control Systems (PACS) are constantly evolving. As networked information technology systems, PACS take advantage of Moore’s Law and the continuously improving price/performance of computer systems. PACS are constantly incorporating improvements in communications and security technologies. PACS and physical security systems use wide area, local, fixed and wireless networks at a range of frequencies across a wide range of devices from mobile phones to millimeter wave radars. In the 1990s, Internet protocol (IP) technologies were incorporated in servers, controllers and network devices. More recently, cloud and smart phone and tablet technologies have been driving industry to incorporate new technologies and solutions. During this period, SIA has established a longstanding record of leveraging standards to promote safety, security and interoperability.
Since 2005, Personal Identity Verification (PIV) credentials have provided a high level of identity assurance. These high-assurance credentials have been incorporated in a variety of ways into PACS. SIA has issued guidance on cryptography and its use in security systems, and there are now more than 5 million government users who should be strongly authenticating for access every day.
HSPD-12 and FIPS 201 involve a two-step process. In creating and binding PIV cards to more than 5 million people, the government and NIST have accomplished much. These Level 42 high-assurance credentials meet the highest practical national and global standards. It is understandably a requirement to have systems authenticate users in a way that leverages a high-assurance identity credential.
High-assurance authentication
Current PACS controllers and other edge devices implement PIV, PIV Interoperability (PIV-I) and other forms of strong authentication. This is not at issue. What is at issue is that the APL to date enables manufacturers to gain listing without meeting the requirement to do the high-assurance authentication that was the point of making the PIV investment. In addition, agencies have acquired APL-listed PACS that don’t perform high-assurance authentication.
Manufacturers have taken a variety of approaches, from minimum compliance to significant investment in solutions that meet the goals and requirements for the use of PIV credentials and a wide range of smart card technologies for federal and other high-security PACS deployments. Going forward, industry and end-users will pursue solutions that provide the best value for the lowest total installed cost, lowest lifecycle cost and high availability, reliability, security, usability, flexibility and scalability.
There is no single architecture or topology offered by manufacturers to meet the value propositions. Current solutions cover a wide range of processors, operating systems and components. Given the breadth of technology, rate of innovation and commercial-off-the-shelf-options, there is no specific approach, and prescribing one would stifle innovation. PACS need to adapt to new technology and incorporate upgrades over their lifecycle, be it as a traditional five-plus-year capital expenditure or a more modern three-year IT lifecycle.
Test and conformance
Accordingly, test and conformance standards cannot dictate a single approach. Rather, they must establish functional requirements and perform tests to ensure that these are met. This typically cannot be achieved in a lab by examining individual components configured in a specific or limited manner. The real world does not break down into a limited number of configurations, even within a given federal enterprise. Further, any federal PACS deployment will require compliance with the Federal Information Security Management Act where system testing will take place. In order to leverage functional testing of PIV authentication capabilities, the user, integrator and solution provider need to make sure the PACS is configured correctly in the context of an installed and operating system.
There are many existing testing and conformance processes in place in industry and in government. Redundant tests, particularly those referred to as PACS tests, which are overly focused on authentication and PKI are counterproductive. That is not to say that functional PIV authentication testing does not need to take place but it should be recognized and organized as such, and in fact, this already exists in the APL authentication categories. This is a completely separate issue from the need for agencies to understand their requirements, be able to procure systems that meet the requirements and have an ability to test systems to make sure they are configured and operated and maintained to do so.
Regardless of whether it is functional testing or system certification, any testing program must have as a counterpart the enforcement of requirements, not simply memoranda that refer to, but do not implement, enforcement.
Security countermeasure
PACS are a particular type of access control system used as an electronic security countermeasure. They are access control systems, just like logical and network access control systems, and are specific to their context. The granularity and ability to enforce policy across access control systems continues to evolve. From access control lists (ACLs) to role-based access control (RBAC) to attribute-based access control (ABAC)5 and policy-based access control, the components of authorization continue to combine in multiple ways and, thus, need to be topology-agnostic.
PACS infrastructures up till now have typically handled the identity, authentication and authorization components of physical access control. HSPD-12 and the associated FIPS 201 PIV standards have effectively separated the identity component and FICAM required PACS to leverage identity and authentication as enterprise services. PACS must leverage the FIPS 201 identity and public key infrastructure in making authorization decisions. In this sense, the PACS is no longer the authoritative source for identity.
Extracted as Figure 1, the FICAM functional workflow of identity verification depicts a functional topology that may not necessarily match the PACS topology of any particular manufacturer. The drawing is problematic in that it calls out a box as the agency PACS and limits its capabilities to only access control rules, when, in fact, everything in the drawing except the certificate authority is the agency PACS. Further, most access control decisions are actually made by the logic in distributed controllers. The only hint of a controller is the mention of a ‘door panel with reader’. Perhaps the most critical component of a PACS – the controller – is not represented anywhere in the drawing. The figure also states that, ‘Authentication mechanisms are based on assurance levels’. Yet, SP 800-116 points out ‘there is not a simple one-to-one mapping between FSLs and PACS Identity Authentication Assurance Levels at access control points; generally, higher-risk areas will need stronger identity assurance’.
As an alternative to this approach, Figure 2 separates the functionality of the “agency PACS” into a distributed architecture. This drawing, like a contemporary PACS, uses robust, self-sufficient, embedded devices in the field, which enforce the necessary policies and implement the specific level of authentication required for the security area being accessed. Authentication mechanisms can take place at various locations in the architecture including at the reader, at the controller, or at the head-end.
Recognizing the limitations on innovation that are imposed by illustrating specific product topologies, a more functional approach would better serve the interests of testing, compliance and creating a stable reference model. An identity, credential and access control abstract paradigm of adjacent functions with predefined input and output characteristics would be a better way to represent the functional requirements.
A FICAM reader must be able to provide not only an authentication process, but also provide information necessary for the PACS to determine what authentication mechanisms were used and what type of credential was presented.
Contactless card to reader
Effective interaction between a card and a reader is a function of both components. In fact, there may not be sufficient specifications in place today for the card. There should be a requirement to test the card for proper operation with a reader. This cannot be offset with more stringent testing of the reader or by putting additional constraints on the reader.
Where there is a need for a suite of test cards to test a reader for its ability to operate on the cards data model, there may well need to be a suite of readers to test cards for their ability to perform effective radio frequency (RF) communications, especially as related to distance, metallic environment and operating frequency of the card. The EP establishes minimum and maximum operating distances that dictate the need for additional testing for the cards prior to finalizing test procedures for the readers. Of particular concern is the unreasonable and conflicting requirement for operation at 7 cm and non-operation at 10 cm.
It is typical for an ISO 14443-4 card and reader interaction to work in the 1-inch (2-3 cm) range. 125 kHz proximity cards and readers, which were used by government prior to PIV, set an expectation for longer read ranges (sometimes up to 6 inches away) and instant results, but they did not have crypto operations, large payloads or the challenges of a metallic environment that are encountered at 13.56MHz. Read range is a card issue just as much as a reader issue, and it is critical to understand the science if there is ever to be success with PIV cards or smart phones, derived credentials, and NFC card emulation modes, especially since phones likely will have a smaller antenna than cards. Further, use of phones will be driven by EMV (contactless credit card) standards that limit the maximum distance to 4 cm.
Tests must be performed by moving a card quickly to the target distance, and then waiting, and waiting, and waiting – without moving the card. Cards must be tested with readers of various sizes which have different sizes and shapes of antennae. Reader size is a result of where it will be mounted, with thin readers commonly used on aluminum mullions, switch-plate size readers on walls, and sometimes larger readers where greater range and performance is desired.
Consideration should be given to card-to-reader interoperability testing, such as ICAO performs (ISO 10373-6). This approach places responsibility for operation on both the card and the reader. With this said, it is SIA’s recommendation that there be no stated requirement for read distances at this time.
OSDP implementation
OSDP is a vendor-agnostic protocol designed to enable devices to exchange security information. OSDP is functionally similar to other device interface protocols such as SCSI and USB. Originally designed by HID Global and Mercury Security (subsequently joined by Codebench), OSDP had as an objective to enable control panels to provide control and supervision of readers, door controllers and other attached security components (referred to as peripheral devices). Its bidirectional qualities enable it to be leveraged by identity and credential authentication applications and make it an obvious successor to unidirectional Wiegand.
To improve security, OSDP defines an implementation that provides encryption between control panels and peripheral devices using AES-128 encryption. OSDP supports extensions to the protocol for use with truly transparent readers to authenticate FIPS 201 credentials, thereby eliminating the risks associated with attack-side decision-making. Readers that do not make security-related decisions are inherently less expensive because they do not require the processing power needed to perform cryptographic operations that can be performed by another system component, such as the controller.
PACS manufacturers can use OSDP to configure and use readers of various assurance levels with their own applications, and the detailed result of each transaction can be sent to the PACS through its standard peripheral device interfaces. OSDP allows reader and panel manufacturers to independently develop high-assurance applications around a robust, extensible standard geared to the best practices of the physical security industry.
The natural evolution of Physical Access Control Systems (PACS) has led to manufacturers incorporating more sophisticated technologies to meet end-user demand for better risk management solutions in today’s cyber and physical threat environment. Cryptographic techniques, such as the use of a Public Key Infrastructure (PKI) and biometrics, often in combination, have been used for well over a decade. Eight years after the government first published FIPS 201 to define the Personal Identification Verification (PIV) card to comply with HSPD-12, generational upgrades to contemporary PACS have assimilated these newer technologies into competitive offerings to meet government and commercial access control market needs.
The Security Industry Association (SIA), an ANSI Standards Developing Organization, strongly believes in industry standards and has published a specification for communication between a reader and a controller called the Open Supervised Device Protocol (OSDP). We believe in industry development of standards that allow flexibility for innovation and value. There is great concern that the new testing approval procedures for Spiral 1 of GSA Approved Product List 2.0 defines a restrictive, singularly-focused approach with a specific topology that is not in the best interests of the customer or the advancement of the market. As it embraces a “proof-of-concept” topology developed years ago, the APL constrains and unduly influences industry pursuit of competitive, scalable products for government applications and does not offer an economically sound or performance-oriented approach.
Accordingly, the SIA recommends a more functional approach to GSA APL testing that determines the processes that a PIV or PIV-I card can implement when used with a PACS and related services, regardless of topology. Topology flexibility is critical since no two enterprises, facilities, buildings or even doors and related environments are identical. The testing and approval procedures should focus on confirming that specific, desired processes can be achieved, and not focused, explicitly or implicitly, on how a system is built.
by SIA Standards Access Control & Identity and the Personal Identity Verification Working Groups
Security Industry Association