A protocol to link access control systems such as card and fingerprint readers suffers from multiple issues around how it handles encryption, according to security researchers.
In a BlackHat talk and accompanying blog post this week first reported by Ars Technica, security firm BishopFox outlined five exploitable vulnerabilities in the Open Supervised Device Protocol (OSDP); an access control communications standard used to secure facilities such as data centers and government sites.
OSDP provides a framework for connecting access control systems such as card readers, fingerprint scanners, and other types of peripheral devices to control panels that check the collected credentials against a database of valid personnel.
Developed by the Security Industry Association (SIA) to improve interoperability among access control and security products. OSDP was approved as an international standard by the International Electrotechnical Commission in May 2020.
OSDP’s predecessor, a protocol with roots in the 1980s known as Wiegand, was shown to be insecure back in 2008 after researcher Zac Franken demonstrated that all communications sent to and from the control panel could be intercepted due to the information being sent in plaintext. Cheap devices to compromise Wiegand devices are now available for sale online.
However, while OSDP supports 128-bit AES encryption, BishopFox’s research suggests the protocol remains vulnerable to attackers.
All but four of the vulnerabilities can be effectively eliminated, but mitigations require configuration settings that aren’t described in the official OSDP specification and vary by device manufacturer.
“Always remember not to trust something just because 'it’s encrypted.' Security is hard, and encryption is not magic fairy dust,” said Dan Petro, senior security engineer at Bishop Fox.
Petro warned that, while OSDP supports it, it doesn’t strictly require encryption. Some ‘OSDP-supported’ devices may not actually support the security/encryption aspects of the standard. Petro recommends doing your research and sticking with OSDP-verified devices certified by the SIA.
Petro also noted that in the initial handshake between a reader and the OSDP controller to exchange information, an intercepting device in the wire can modify this initial ‘capability message’ to lie about the reader’s capabilities and claim that it does not support encryption, and then steal badge numbers. Companies should try to make sure that the OSDP controller refuses any connections from readers that are not encrypted.
While many devices of types will feature an insecure setup step to allow configuration, another issue is many OSDP controllers are configured to remain in “install mode” persistently, allowing attackers to request encryption keys. Make sure that “install mode” is not enabled except when actually installing a new reader.
Some non-verified OSDP controllers may come with hardcoded encryption keys, rather than randomly generated ones. While these are technically 128-bit AES keys, they are simple known patterns that attackers can relatively quickly brute force through.
Finally, OSDP has no secure in-band mechanism for key exchange – i.e. other than the wires connecting readers to controllers – and there are currently no out-of-band mechanisms for key exchange. This means attackers that may already have access to the wires connecting physical readers could intercept base keyset messages and compromise the encryption.
Petro notes this final issue is “hard to protect against," as there’s no simple configuration change to remedy it.
“One piece of advice would be to never ignore tamper alarms from readers. Treat all tampers as if you’re under attack. Similarly, if a reader suddenly goes offline and needs replacing, be on high alert,” he said. “If you would like to be extra paranoid, what you could do is invent your own out-of-band key exchange mechanism: Never configure a reader on the production wiring.”
