It takes US Federal employees four seconds to get a green light to enter a building after presenting a contactless PIV card to a reader, when using asymmetric cryptography for authentication. NIST is trying to speed this up, and is looking at EMV contactless payment cards for inspiration.
(This is a continuation of the previous post, where I reported on the recent NIST Workshop on PIV-Related Special Publications, and Part 6 of the ongoing series discussing the public comments on Draft NIST SP 800-157, Guidelines for Derived Personal Identity Verification (PIV) Credentials and the final version of the publication. Links to all the posts in the series can be found here.)
Federal employees have been using PIV cards to enter buildings for many years, and it has not been taking them four seconds to get the green light. But agencies are now transitioning from using a symmetric Card Authentication Key (CAK) to using an asymmetric CAK with an associated public key certificate, the asymmetric CAK being the private key component of an RSA or ECDSA key pair. Inclusion of the asymmetric CAK and associated certificate in PIV cards became mandatory in August 2013 with the publication of version 2 of the FIPS 201 standard (FIPS 201-2).
The motivation from transitioning from a symmetric to an asymmetric CAK is not to use fancier cryptography or to improve security, but rather to allow an employee of one agency to use his or her card to enter the buildings of a different agency. A symmetric key is a shared secret between the card and the agency that issued the card and therefore cannot be used at a different agency, whereas the Federal PKI allows any agency to verify a certificate issued by any other agency for the public key associated with an asymmetric CAK.
As can be seen in the agenda, the afternoon of the first day of the PIV workshop was dedicated to discussing the four-second problem, with many speakers and panelists reporting on investigations of the problem and proposing solutions. The four-second delay was attributed to multiple causes, including:
- The preprocessing done by the card, including the power-on self test (POST) mandated by FIPS 140-2. Speakers reported that the POST is sometimes done twice, for various reasons.
- The transmission of the CAK certificate from the card to the reader. This takes a long time because certificates are bulky, and cannot be substantially compressed, since a certificate contains an incompressible public key and an incompressible signature. Also, I suppose the CAK certificate is backed by a certificate of the agency that issued the card, signed by the Federal Bridge CA, and that certificate has to be transmitted along with the CAK certificate.
- The validation of the CAK certificate by the Physical Access Control System (PACS). Validation includes verifying the signature in the certificate and checking that the certificate has not been revoked. I suppose the agency certificate that backs the CAK certificate is validated as well.
- The signing of a challenge by the card, using the asymmetric CAK.
Several ways of reducing the delay were discussed:
- The time taken by the POST can be reduced by doing fewer or no self-tests. In particular, agencies could take advantage of the Multiple Modes of Operation provision of Section 1.7 of the Implementation Guidance for FIPS 140-2, which authorizes the testing of only those cryptographic algorithms used for one particular mode of operation. (IMO, the 15-year old FIPS 140-2 should be thoroughly revised, and the security benefits of repeatedly testing the implementations of cryptographic algorithms in a cryptographic module against inputs and outputs stored in the cryptographic module itself should be questioned.)
- The need to transmit CAK certificates can be minimized by caching the certificates at the reader.
- The need to validate certificates at authentication time can be minimized by caching the status of certificates in a so-called “caching status proxy” which retrieves, caches, and periodically rechecks the status of certificates. However, the security implications of using such a proxy were not discussed. Infrequent rechecks could substantially extend the period of time during which an adversary could gain unauthorized access to a Federal building with a stolen PIV card.
- The time that the card takes to sign the challenge can be reduced by using an ECDSA signature rather than an RSA signature.
Another idea for reducing the delay is to look at the EMV specification for contactless payment cards. This was proposed in slides authored by Steve Weymann of InfoGard and presented by Hildegard Ferraiolo of NIST, who later referred to the idea in one of her own presentations.
EMV relies primarily on symmetric cryptograms for transaction authorization by the issuing bank. But EMV has an optional offline data authentication feature that allows the merchant terminal to verify the card. (According to Section 3.4 of Book C-2 of the EMV contactless specification, which is concerned with MasterCard contactless cards, offline data authentication is available in the contactless EMV mode but not in the contactless mag-stripe mode which I described in this post.) As I explained in this post, offline data authentication comes in three flavors (SDA, DDA and CDA), and in two of these flavors (DDA and CDA) the card performs an asymmetric RSA signature. Thus an EMV contactless card that uses DDA or CDA authenticates to a merchant terminal in a manner similar to how a PIV card authenticates to a PACS. Furthermore, the PIV and EMV specifications both rely on the ISO 14443 standard for NFC communication. Thus it makes sense to look at the EMV contactless specifications when trying to improve the performance of contactless PIV cards that use asymmetric cryptography.
Although both PIV and EMV follow ISO 14443, there are two important differences in how they profile the standard that have consequences for the speed of physical NFC performance.
First, the EMV specification requires correct operation only up to a distance of 4 cm between the card and the reader, whereas the PIV specification suggests an operating distance of up to 10 cm. (The suggestion can be found in Section 2.3.10 of SP 800-96, where it is peculiarly phrased as follows: “The reader shall not be able to read a PIV card more than 10cm from the reader”.) Higher distance means lower transmission speed for a given amount of RF power. Furthermore, since the card gets its power from the reader (the combination of card and reader acting as a transformer, as nicely explained in Section 2.1 of Book D of the EMV contactless specifications), higher distance also means less power available in the card for cryptographic processing, and hence lower processing speed.
Second, the PIV Card to Reader Interoperability Guidelines, SP 800-96, refer to ISO 14443 but do not specify any procedures for physical testing of cards against readers and readers against cards. By contrast, Book D of the EMV contactless specifications includes procedures for testing cards against an EMV TEST PCD and readers against an EMV TEST PICC (where PCD stands for Proximity Coupling Device, which means reader, and PICC stands for Proximity Integrated Circuit Card). This ensures that cards and readers from different manufacturers can not only interoperate, but also achieve good RF coupling, allowing high transmission speeds and sufficient power in the card for fast cryptographic processing.
- Part 1: NIST Fails to Address Concerns on Derived Credentials
- Part 2: NIST Omits Encryption Requirement for Derived Credentials
- Part 3: Biometrics in PIV Cards
- Part 4: Biometrics and Derived Credentials
- Part 5: Highlights of the NIST Worshop on PIV-Related Special Publications
- Part 7: Has Bluetooth Become Secure?
- Pomcor’s Derived Credentials page