Access Credentials a Mixed Bag
Access control credentials range from magnetic stripe to 125kHz proximity credentials that output an identifier and do not provide authentication, to contactless credentials providing differing authentication strengths to biometrics and smartphone-based solutions.

There are standards such as the ISO 7816 (parts 1-15) and ISO 14443 (parts 1-4) for smart cards and ANSI/INCITS 378 for fingerprints. Specifications such as Bluetooth Low Energy (BLE) and Near Field Communications (NFC) exist for mobile devices. Cryptographic standards include symmetric Advanced Encryption Standard (AES) and 3DES or Triple DES (Data Encryption Standard), both of which succeeded the initial DES and asymmetric encryption such as in the case of Federal Information Processing Standard (FIPS) 201.

The effort here has only gone part of the way. The technology can be unique to the embedded security chip manufacturers and, for instance, where FIPS 201 usability requirements needed in physical access control use cases have not been fully addressed. The NFC spec leveraged the ISO 14443 standard and looked like it might be a general way forward to compatibility with many reader vendors and ISO 14443 contactless cards; unfortunately it was not adopted across smartphone vendors (e.g. not by Apple) and as a result created a barrier to the network effect. BLE is present across smartphones but requires an additional radio to be added to existing readers and is not compatible with card-based technology.

OSDP Expands Readers’ Reach
PACS readers sit between access credentials and door controllers/panels. Interoperability is dependent on the interfaces to both of these. Given the silos of credentials interoperability is limit
ed to the extent there is a common credential set. One workaround is the use of multi-technology readers, which offers greater functionality but not true interoperability.

In terms of reader-to-controller interoperability, the industry in the 1990s benefited from the Wiegand standard that provided a common means of defining the bits on an access credential (parity, facility and identifier) and the wiring for interfacing readers and door controllers. However, it was also open to interpretation and modification, and only provides one-way communication. The protocol also has overhead on the order of 2 milliseconds per bit. While not an issue with smaller deployments this begins to enter into play as Wiegand gets expanded up to 200 bits in the case of the U.S. government (a 400-millisecond delay). Plus a one-direction protocol does not allow for standards-based encryption or remote upgrading of firmware.

Bidirectional serial communications is the first step up. This typically has been the RS-485 standard. Even here different duplexing approaches have been taken to increase transmission speeds and distances. Wiring may also vary in the number of wires, circuits and resistance and impedance values. Furthermore the standard does not extend to the message set. This resulted in a lack of interoperability even though there was an underlying communication protocol standard.

To address the variety of implementations, recently the Open Supervised Device Protocol (OSDP) began to take hold. OSDP leverages RS-485 but also includes command sets to enable the reader-to-controller application to be interoperable. Depending on the extent of and the level of information provided in a standard, conformance may not be sufficient to enable interoperability. OSDP provides a sufficient level of detail. The serial OSDP profile includes both an open and encrypted version of the protocol. OSDP has also been expanded to include Transport Layer Security (TLS), which widens the applicability of the protocol to include TCP/IP-capable device interfaces (see sidebar above).

The protocol has the flexibility to include a variety of devices interfacing with door controllers – this includes biometric devices and can be extended to things like sensor and perimeter devices such as instrumented fences and other barriers – and even nonsecurity-related devices.

Door Controllers, Servers Show Promise
In terms of standards, door controllers are reader dependent and depending on the readers and architecture, OSDP and TCP/ IP (and TLS 1.2) can have a significant role. As a result it is an area where you do see OEM controller vendors since there exists downstream (initially Wiegand and now OSDP) and upstream TCP/IP standards.

Other IT standards can also come into play. One example is the Simple Network Monitoring Protocol (SNMP) that can be leveraged to monitor devices on a network. In addition to controls this applies to IP readers, cameras, intercoms, servers, virtual machines and other devices.

Servers sit between door controllers and enterprise services, importantly identity management systems as well as client applications. Downstream is TCP/IP and again hopefully TLS 1.2 to the controller. The server itself should be able to run on a variety of hardware or virtual machines. Given their complexity and feature set, there really is no interoperability among servers and their associated databases and client application support.

There are standards for interfacing to identity management systems, other enterprise services and for the application programming interfaces (APIs), and many PACS servers do interface to third-party hardware and applications. However, most of these connectors are proprietary. Standards do exist for the data exchange, such as XML and more recently JSON (Javascript Object Notation Language) and for API authentication such as OAuth.

ID Management & Looking Forward
PACS servers need identity management system interoperability. There are two options: developing a specification or trying to leverage IT standards. A substantial identity and access management (IAM) industry exists for authentication and authorization logical applications. One early example is Public Key Infrastructure (PKI), which continues to be an important component of many security solutions though enterprises have a mixed record on adoption and make use of SAML (Security Assertion Markup Language) probably more than they do PKI. Enterprise IAM does leverage directories such as LDAP (Lightweight Directory Access Protocol) and AD (Active Directory), and many enterprise PACS have developed interfaces for these services.

Very few PACS have adopted the same schemas as these directories. More recently the SCIM (System for Cross-domain Identity Management) spec has evolved to address shortcomings in LDAP and legacy AD (which is evolving to include SCIM) and is backed by major IAM providers.

In contrast the PLAI (Physical-Logical Access Interoperability) specification being pursued by larger PACS providers seems to be targeted at legacy LDAP and AD. So in many ways the industry continues to behave as it has in the past. There are other developments in the identity and access control world such as OpenID Connect and the User Managed Access (UMA) protocol, which builds on OAuth and in the case of UMA allows a distributed as opposed to a centralized approached to access control.

One wonders at what point enterprise identity, cloud-friendly services and increasingly intelligent end points and mobile devices might eclipse the physical security industry. Fortunately for the industry the physical access control use case is complicated … but as the Internet of Things (IoT) becomes more a part of the enterprise the IAM solution may soon cover these use cases. While nothing happens overnight, technology moves pretty quickly. We shall see if the horizon can lead to true interoperability.

…

Bio: Salvatore D’Agostino is CEO of IDmachines. Reach him at [email protected].

If you enjoyed this article and want to receive more valuable industry content like this, click here to sign up for our FREE digital newsletters!

Related Content