“Build it, and they will come” does not always work out for standards. Case in point: the sad state of physical access implementations for the US government PIV (Personal Identity Verification) card. Specified by NIST publication SP800-73 lays out an ambitious vision, supporting both logical and physical access control. The first category is access to buildings, restricted areas such as airport tarmacs. In the second category are scenarios such as smart-card logon for computers, connecting to a wireless network that uses 802.1x authentication or creating a VPN tunnel to the corporate network. The standard defines multiple public/private key-pairs and associated X509 certificates that a card can carry, intended for different purposes such as encryption or document signing. It even has some limited flexibility in choosing algorithms, supporting both RSA and ECDSA.
Strong authentication with public-key cryptography
The capabilities outlined in the PIV specification lend to a straightforward physical access protocol with high-level assurance. A very rough sketch of the interaction between card and compatible readers would run like this:
- Cardholder presents their card into a badge reader
- The reader queries the PIV card for one of the digital certificate.
- It verifies the certificate up to a trust root and performs revocation checking.
- Then the reader extracts the public-key from the certificate and issues a cryptographic challenge to the card that can only be answered with the corresponding private key.
- Card computes the response to the challenge.
- Reader uses the public-key to verify that the card response is correct. If this step fails, the protocol terminates with failure.
- If the response is correct, the reader has successfully verified the identity of the cardholder.
- This is not quite the end of the story however, since we still have to determine whether that person is allowed access to the restricted space. Typically that involves querying a back-end system that keeps track of access rules. These rules can be arbitrarily complex. For example some users may only be granted access to restricted area during business hours. But such policies are independent of the authentication scheme used between card and reader.
Reality: static data, no authentication
In reality many readers that claim to support PIV cards however do not implement anything near this level of security assurance. To take one example: the RP40 is a widely-deployed contactless reader from HID’s multiCLASS family of readers. Along with legacy 125Khz used for supporting the flawed and broken HID iClass protocol, the reader supports the modern 13.56Mhz band associated with NFC.
The PIV card also happens to be dual-interface, meaning that it can be used either by bringing the reader into contact with the metal plate on the card surface or wirelessly, by holding the card in the induction field generated by an NFC reader. The standard goes to great lengths to distinguish between NFC and contact-based usage, describing which operations are permitted in both cases. Of the different key-pairs specified in the PIV standard, only one– the card authentication key– can be used over NFC. The others are only accessible over the contact interface. (This restriction correlates with requirement for PIN entry: any key that requires PIN entry prior to use can only be invoked over the contact interface.)
RP40 specifications state that these readers support the “US Government PIV” standard. In principle then RP40 readers could have implemented a sound public-key based cryptographic protocol, compliant with the PIV standard by using the card-authentication key along the lines sketched above. But it turns out they don’t. Much like other early generation of PIV-compatible readers, they rely one of two pieces of static data:
- UID associated with the card. This operates at the NFC layer, independent of PIV standard. UID supposed to be a unique identifier for NFC tags. In reality it is neither guaranteed to be unique across all tags or stable. Some cards deliberately emit a random UID that changes on each NFC activation, as a privacy measure designed to deter tracking. NFC standard only depends on UID to be unique for multiple tags introduced into the reader field at the same time, so-called “anti-collision” purposes. It is not intended to be used for authentication. While genuine NFC tags are required to have globally unique identifiers burnt-in at the factory, counterfeit chips exist that allow changing the UID to masquerade as any other tag.
- CHUID, or card-holder unique identifier. Despite the name similarity, CHUID is a data object defined by the PIV standard. This is just a static piece of information stored on the card. It may have its own signature or other integrity protection but this signature is also static. CHUID can be trivially copied to another card and replayed. (Incidentally an update to FIPS201, the basis for PIV standard, clarified this further and deprecated use of CHUID for access control.)
In neither case is there a challenge-response protocol to verify that this static data emitted from the card was not cloned from a legitimate one. In fairness HID also has a new line of readers called PIVclass which does have proper authentication using either card-authentication key over NFC or the PIV authentication key with card slot & numeric keypad for PIN entry. But this is a relatively recent offering, specifically targeted at the government sector. Many commercial office buildings– including this blogger’s current and previous office locations– have an installed base of HID multiCLASS readers. Ripping out readers and installing new ones is a difficult proposition. Until they are upgraded, physical access with PIV falls short of its full potential.