The final installment of my three-part series covering interoperability standards focuses on The Security Industry Association (SIA)’s Open Supervised Device Protocol (OSDP) — a communications protocol that allows peripheral devices such as card readers and biometric readers to interface with control panels and/or other security management systems. To read my previous columns in the series on ONVIF and PSIA, see the links at the end of this article.
SIA developed OSDP to foster interoperability among security devices, and it is the focus of a Working Group within the SIA Standards Committee. Since SIA is an ANSI standards development organization, OSDP is on track to eventually become a true ANSI standard. This effort should continue to be embraced by the access control community, and is one protocol I would bet on.
Inside OSDP’s Development
For years, the dominant means of communication from an access control reader to a panel has been the venerable Wiegand protocol, for which several variants exist. The protocol is uni-directional, essentially unsupervised and vulnerable to physical hacking by removing a reader and using equipment to capture signals and record them for later spoofing. Many readers do not even have a simple tamper switch.
Some manufacturers moved to proprietary-format communications using 2-wire or 4-wire RS-485 communications protocol. One such effort was undertaken by Mercury in 2003 and was known as the Peripheral Device Protocol (PDP). According to Frank Gasztonyi, Mercury’s co-Founder and now CTO, “PDP was intended to be a thin protocol requiring very little overhead for very cost sensitive devices, namely readers.”
While several other third-party protocols have emerged, Mercury’s intent was to create a shell that others could easily use — particularly as new devices (e.g., biometric readers) emerged. HID was one of the first non-Mercury implementers of PDP. According to Gasztonyi, it took quite a while for others to get on board, but one of those was Codebench (acquired by HID in 2013), specializing in physical identity management applications for the Federal Government. During a smartcard proof of concept demonstration in 2011, the effort came to the attention of SIA, which approached the parties to determine their interest in sharing it with the industry.
Mercury, HID, and Codebench agreed that broad-based acceptance was more likely if the protocol was controlled by the industry association and not by a manufacturer; thus, in early 2012, the intellectual property was transferred to SIA without monetary consideration.
The SIA Access Control and Identity Standards Sub-Committee, co-chaired by Perry Levine, formerly of Siemens and now Senior VP Business Development at BluB0X Security, created an OSDP Working Group, led by Gasztonyi to collaborate to further develop OSDP to enhance and improve, as well as work towards an ANSI standard.
How OSDP Works
OSDP is a message structure carried via RS-485 communication. “OSDP is a terse and efficient message set, for which RS-485 is both suitable and inexpensive medium, but RS-485 does not inherently provide data security,” Gasztonyi explains.
The main improvement in SIA’s release of OSDP 2.0 was the definition of OSDP Secure Channel based on the 128 bit AES encryption engine. OSDP’s security implementation was derived from the Global Platform’s Secure Channel Protocol 3. OSDP’s version was optimized for RS-485, yet it still retains all essential elements of the original work — mutual authentication of the devices, message authentication, and data security.
Rodney Thayer of RSG Modelworks — a recognized industry cyber expert — has been involved in this effort, even though it currently only deals with RS-485 protocol. “Lots of those people involved know how to get UL approval, and that’s a big deal,” Thayer explains. “The technology and players around this have a great deal of value. Further, the fact that this is bi-directional offers up a range of possibilities.”
Does that mean that it will extend to IP network transmission? It appears so. Protocols offer different “wrappers” to enable effective end-end communication. Everyone I spoke with confirmed that no matter the communications medium, the underlying message structure is basically the same. If the end-equipment has already been engineered to understand those messages, it becomes a matter of implementing the unwrapping process.
Now and in the Future
Since the protocol has been designed to work in access control environments from the get-go and has been plugged into the policy-decision process, it should play nicely with future systems and facilitate easy implementation by manufacturers. The first implementation will involve Transport Layer Security (TLS) — basically providing for an encrypted VPN (Virtual Private Network) on the fly. This means that the currently used Secure Channel will give way to TLS in IP implementations. Security is enhanced because TLS is based on certificates.
Thayer believes that we will eventually see certificates on all communicating components. What’s required to kick this off, according to Gasztonyi, is a situation or application which demands it. A consensus view is 12 to 18 months to an OSDP IP standard.
As part of the effort to adapt to emerging technologies and applications, OSDP provides for certain applications profiles, with the goal of interoperability between devices conforming to a given profile — which define the set of OSDP messages that a device must implement to perform a specific application.
“We are now focused on the other things that we can include within OSDP, including advanced encryption, support of biometrics as well as communications over TCP/IP,” Levine says. “It is critical that this is implemented in a standard way so that any access control PACS manufacturer can use any Card Reader/Biometrics device, allowing the flexibility to create solutions to meet end-user requirements.”
OSDP has evolved from real products in the marketplace, interoperating successfully in real installations. SIA has pulled together broad-based manufacturer participation to deal with questions of common interest, such as LED activation, and expansion into biometric data.
Read Mr. Coulombe’s other columns in this series: ONVIF (www.securityinfowatch.com/12084509); and PSIA (www.securityinfowatch.com/12094477).
Ray Coulombe is Founder and Managing Director of SecuritySpecifiers.com and RepsForSecurity.com. He can be reached at [email protected], through LinkedIn at www.linkedin.com/in/raycoulombe or followed on Twitter, @RayCoulombe.
