Emerging standard secures contactless smart card communications
OPACITY – the Open Protocol for Access Control Identification and Ticketing with privacy – is designed to provide mutual authentication, privacy and confidentiality for contactless transactions.
“It’s primary goal is to enable secure contactless communication with a level of performance required for building entry or transportation and a level of security in line with the latest guidelines from the National Security Agency,” explains Jerome Becquart, vice president of Product Marketing and Identity Assurance for HID Global.
It is the result of a joint effort between HID Global and the U.S. Department of Defense.
What it does
The OPACITY protocol is designed to protect contactless communication between an identity credential, such as a smart card or mobile phone, and an end point device such as a door reader, tablet, computer or mass transit gate.
“With OPACITY, performance is improved by a factor of approximately four for critical tasks,” says Becquart. “The secure wireless communications capability enables the use of PIN and biometrics on the contactless interface, further strengthening authentication alongside PKI for both logical and – in the future – physical access.”
The driving force behind the multi-year effort is to protect the contactless interface on the Common Access Card.
This interface is subject to eaves dropping, which lead the NSA to considerably restrict what can be done via the interface rendering it virtually unusable in all but a few limited use cases.
“It was necessary to define a secure contactless protocol with the appropriate level of performance to solve that security challenge and address privacy issues,” says Becquart. “Defense Department involvement meant that compliance with the most recent cryptographic guidelines was an essential requirement.”
HID developed OPACITY with support from the Defense Department and worked closely with a number of standards bodies to ensure openness and compliance. It is standards-based and open for anyone to use. It is also being considered by the National Institute of Standards and Technology for possible inclusion into FIPS 201-2.
The result is a mutual authentication protocol with shared key establishment for confidential, end-to-end transport and integrity protection, says Becquart. “In short, the secure session is established over the contactless interface in a single command before any identifiable data is exchanged,” he explains.
OPACITY has two modes of operation: Full Secrecy and Zero Key Management. “Full Secrecy mode ensures that identity of the cardholder is never compromised with end-to-end protection even after the transaction or the session is completed,” explains Becquart.
For older, deployed readers that cannot support the requirements of Full Secrecy mode, the Zero Key Management mode can be used. “This mode does not require storage of secret keys in end point terminals,” explains Becquart. It provides card authentication but does not authenticate the terminal and such should only be used in environments where readers are known and trusted.
The objective for the OPACITY protocol is to enable the contactless interface to be used for a larger number of use cases, expanding the contactless applications for the Common Access Card.
According to Becquart, current contactless protocols can leak personal identifiable information, and they also may fail to verify that the reader is a genuine party to be trusted. They simply aren’t cryptographically strong enough to weather the next 20 to 30 years of authentication, he suggests.
At present, OPACITY is being tested in limited pilots at the Defense Department, but its inclusion in the next generation FIPS 201-2 specifications could dramatically expand its use throughout the U.S. government.
At the Mark Center in Virginia, a group of Defense Manpower Data Center employees are using OPACITY-enabled Common Access Cards to gain access to offices via doors protected by HID pivCLASS, PKI-enabled readers.
In a mobile access proof of concept, a group of Defense Department employees are trialing OPACITY-enabled Common Access Cards to securely access e-mail from NFC-enabled phones, sign and encrypt e-mail and access secure web sites.
“This proof of concept requires no additional piece of hardware to interface between the card and phone, yet maintains a high level of privacy and security,” says Becquart. The solution addresses the Bring Your Own Device challenge without having to deploy an expensive and cumbersome smart card reader to connect your phone to your Common Access Card, he explains.
As authentication for physical and logical access continues to evolve and permeate more sectors of society, it will be imperative to install a solution to safeguard these actions when they occur over a contactless interface. It is HID and the U.S. Government’s hope that OPACITY will provide a clear choice.
Defining OPACITY’s two modes of operations
Full Secrecy mode is best applied to situations where it is necessary to establish a session consisting of many transactions and where the material communicated is sensitive, such as in administrative or key life cycle management or when the information communicated will remain critical and must be protected over a long period of time.
In this mode, OPACITY requires a mutual authentication between the card and terminal and the presence of a Secure Application Module to store the secure materials involved in this mode of the protocol.
Leveraging Full Secrecy, previously transmitted secrets cannot be revealed in the clear even if the static terminal authentication key has been compromised.
Zero Key Management
Zero Key Management mode is a lightweight option suited when off-card applications – the terminals – are not always capable of supporting a security module, operating secrets and the corresponding key life cycle management, such as in legacy physical access control or logical access control deployments.
Zero Key Management does not require any secrets to be stored on a terminal.
Zero Key Management provides card authentication but not terminal authentication and is to be used only in environments where terminals are known and trusted.