Highlights of the NIST Worshop on PIV-Related Special Publications

This is Part 5 of a 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.

On March 3-4, NIST held a Workshop on Upcoming Special Publications Supporting FIPS 201-2. The FIPS 201 standard, Personal Identity Verification (PIV) of Federal Employees and Contractors, leaves out many details to be specified in a large number of Special Publications (SPs). The purpose of the workshop was to discuss SPs being added or revised to achieve alignment with version 2 of the standard, FIPS 201-2, which was issued in September 2013. An agenda with links to the presentations and an archived webcast of the workshop are now available.

I attended the workshop, via webcast, mostly because some of the topics to be discussed were related to derived credentials. In this post I report on some of those topics, plus on three other topics that were quite interesting even though not directly related to derived credentials: (i) the resolution of a controversy on whether to use a pairing code to authenticate a computer or physical access terminal to the PIV card; (ii) the security of methods for physical access control, including new methods to be introduced in the next version of SP 800-116; and (iii) the difficulties caused by having to certify cryptographic modules to FIPS 140. I will leave two other topics for the next two posts in this series: (i) why it takes four seconds to gain physical access using the asymmetric Card Authentication Key, and what to do about it; and (ii) whether Bluetooth has a role to play in connection with derived credentials.

The pairing code controversy

FIPS 201-2 introduced “secure messaging” as an optional feature of contactless PIV cards. Secure messaging (SM) refers to the establishment of a cryptographically secure channel between the card and a Physical Access Control System (PACS) terminal, a workstation, or a mobile device, over an underlying NFC channel. The key establishment phase of the secure channel protocol is based on “a simplified profile of OPACITY with Zero Key Management” according to Revised Draft SP 800-73-4, Section 4.1.

A shared secret is established between the card and the terminal (or computer) using the Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) primitive specified in SP 800-56A, Section 5.7.1.2. The card uses a static (i.e. long term) Diffie Hellman (DH) key pair, while the terminal or computer uses an ephemeral key pair; this means that the key establishment phase authenticates the card to the terminal, not the terminal to the card; and that there is no forward secrecy. The static public key of the card is certified by a Card Verifiable (CV) Certificate. CV certificates, standardized in Part 8 of ISO/IEC 7816, are easier to parse than X.509 certificates, and are used for other purposes, notably in ePassports. Notice that, although it is “card verifiable“, the certificate is verified by the terminal rather than the card.

(OPACITY, which stands for Open Protocol for Access Control, Identification, and Ticketing with privacY, has been registered as an ISO/IEC 24727-6 authentication protocol, and is specified in INCITS 504, a.k.a. ANSI 504 or GICS, but does not seem to be in actual use. The key establishment protocol of SM is a simplification of the one in OPACITY in that it omits a session resumption feature known as “persistent binding“. OPACITY has a vulnerability, described in the paper A Cryptographic Analysis of OPACITY by Dagdelen et al. (See the 2nd and 3rd paragraphs of Appendix A.1). The NIST announcement of Revised Draft SP 800-73-4 stated that the key establishment protocol in the initial draft was modified for purposes including addressing security issues raised in the paper; however the vulnerability involves persistent binding, and thus does not affect the NIST SM protocol. Actually, the NIST SM protocol was modified so that the card would send the GUID card identifier in the clear rather than encrypted under a session key. Since the terminal does not authenticate, such encryption would be useless, because an attacker could trivially decrypt the identifier with the session key after establishing a session. Comments NSA-2 and NSA-3 allude to this in the table of comments on the initial draft of SP 800-73-4.)

Table 2 in the Revised Draft of SP 800-73-4 Part 1 (pages 14-15) lists the “access rules” for reading data stored in a PIV card. The entry “PIN” in a row for a data item means that the card must be activated by entering a PIN in order to read the item. The entry “PIN or OCC” means that the card must be activated by entering a PIN or a fingerprint used in an on-card comparison (OCC) to a template stored in the card. The entry “Always” means that the item can be read even if the card is not activated. The table shows that all the X.509 certificates in the card can be read without activating the card. Those certificates include the PIV Authentication certificate, the Card Authentication certificate, the Digital Signature certificate, the Key Management certificate used for email encryption, and up to 20 Retired Key Management certificates whose associated private keys are used for decrypting older emails. Except for the Card Authentication certificate, all these X.509 certificates contain personally identifiable information (PII). To prevent that PII from being read over NFC through mere proximity of a reader to the card, NIST added a mechanism for authenticating the NFC reader to the card after the SM key establishment phase. Without such a mechanism, an attacker could read certificates from a card carried in a federal employee’s pocket without a protective sleeve, simply by stepping into close proximity of the employee, something which could be achieved without raising suspicions in a crowded public space such as the Washington DC Metro.

The added mechanism for achieving mutual authentication is a “pairing code“, consisting of 8 decimal digits, which is generated at random by the card issuer and stored in the card. The cardholder pairs the card to a mobile device by entering the pairing code into the device, where it may be cached indefinitely and used to authenticate the device to the card after each SM connection establishment. (It is not clear how the pairing code would be entered into an NFC terminal near a door or turnstile.) When the pairing code is used in conjunction with SM to achieve a secure channel over NFC with mutual authentication, the contactless interface of the card is referred to as the “Virtual Contact Interface (VCI)“. (Confusingly, the term “contact interface” is sometimes used to refer both the physical and the virtual contact interfaces. This is the case, in particular, in the above-mentioned Table 2 of SP 800-73, according to Footnote 11.)

The pairing code cannot be changed by the cardholder. To mitigate the burden of having to memorize a random 8-digit pairing code in addition to the 6-to-8 digit card activation PIN, SP 800-73 suggests printing the pairing code on the back of the card. There is no prohibition against letting the cardholder use the pairing code as the PIN, which less security-conscious cardholders may be tempted to do.

The introduction of the pairing code in the first draft of SP 800-73-4 drew a very strong negative reaction from the federal agencies, as noted in the announdement of the revised draft and as seen in a large number of strongly worded public comments on the draft. In response to these comments, NIST announced at the workshop that it is planning to make a further change to SP 800-73, discussed in Slide 9 of Hildegard Ferraiolo’s presentation PIV Card Specification Update (SP 800-73-4). The card issuer will be allowed to remove the pairing code requirement. This will require approval by a Designated Approving Authority and unspecified compensating controls.

I may be missing something, but I don’t see why X.509 certificates should be readable without card activation. Card activation is required for using the private keys associated with the certificates, so why not require it for reading the certificates? Any comments suggesting an explanation would be appreciated. If card activation were required for reading certificates, the pairing code might not be necessary.

Physical access security

As I pointed out in Part 3 of this series, SP 800-116, A Recommendation for the Use of PIV Credentials in Physical Access Control Systems (PACS), is out of date; it has not been revised since it was issued in November 2008. At the workshop, a talk by Ketan Mehta with slides by David Cooper discussed changes that NIST is planning to make to this publication, including the addition of new authentication mechanisms and deprecation of insecure ones.

A level-of-assurance (LOA) table in slide 3 summarizes and classifies no less than 13 mechanisms that are or will be available in PIV cards for use in physical access control. The table greatly overestimates the security provided by some of these mechanisms. In particular, the last row of the table, labeled “VERY HIGH confidence” (in the identity of the cardholder), includes seven mechanisms with widely different security postures, some of them quite weak.

The first row of the LOA table, labeled “LITTLE or NO confidence“, includes two mechanisms, VIS and CHUID, in a dim font that suggests that they are or will be deprecated. CHUID was indeed deprecated by FIPS 201-2. Presumably VIS will be deprecated by the upcoming version of SP 800-116. In CHUID, the PACS reads and verifies the signature on a signed data structure of same name, which contains two identifiers (FASC-N, and an encoding of the Card UUID known as GUID) and the card’s expiration date. CHUID cannot be fabricated because of the signature, but can be cloned by reading it from a valid card and storing it in a fake card. VIS refers to the visual inspection of the card by a guard.

If VIS is depecrated, then BIO-A, listed in the last row of the LOA table as providing two-factor authentication, should be downgraded to one-factor authentication. In BIO-A the PACS reads a signed fingerprint template after the cardholder activates the card by entering a PIN, and compares the template off-card to a fingerprint entered by the cardholder in the presence of a human attendant; BIO is like BIO-A, without the attendant. As I pointed out in Part 3, the current version of SP 800-116 classifies BIO as one-factor authentication because the card is not authenticated and, consequently, the PIN provides no security if the card is fake. BIO-A is classified as two-factor because the attendant will visually inspect the card in addition to collecting the fingerprint; but if VIS is depecrated, such visual inspection should not be deemed to provide additional security, and may not even be performed.

The LOA table includes four authentication mechanisms that are not in the current version of SP 800-116: SM-AUTH, SM-AUTH + PIN, SM-AUTH + BIO, and OCC-AUTH.

SM-AUTH is a new mechanism that is not mentioned in FIPS 201-2. It relies on the authentication of the card that takes place during the SM key establishment phase. The PACS terminal tries to establish an SM connection to the card, and deems the card to be authenticated if the connection is successfully established. The cardholder is indirectly identified by the GUID encoding of the Card UUID, which is present in the CV certificate that binds the card’s static DH public key. In SM-AUTH + PIN the cardholder activates the card with a PIN over SM. In SM-AUTH + BIO the terminal retrieves a fingerprint template or an iris image from the card for off-card comparison to a fingerprint or iris image collected from the cardholder, over SM, after the card has been activated with a PIN.

Two drawbacks of SM-AUTH (and its extensions SM-AUTH + PIN and SM-AUTH + BIO) were pointed out by Mehta and Ferraiolo. Slide 6 of Mehta’s presentation on physical access control says that SM-AUTH does not include revocation checking. It is not clear why this is the case. SM uses a CV certificate rather than an X.509 certificate, but I don’t see why a CV certificate would not be revocable. Slide 7 of Ferraiolo’s PIV card specification update states that, because SM-AUTH is optional, it is not a candidate for use at an inter-agency access point; i.e., it cannot be used to allow entrance to a building of a federal agencies to employees of other federal agencies.

In OCC-AUTH, a PACS terminal establishes an SM channel to the card, thus authenticating the card, and sends a fingerprint collected from the cardholder to the card, where it is compared against a template. I discussed the weaknesses of OCC-AUTH in Part 3: there is no revocation checking, no PIN is required, no human attendant is required, and only an easy-to-spoof fingerprint biometric can be used. (There may be an iris biometric in the card, but it cannot be used.) OCC-AUTH cannot be said to provide very high security, contrary to what is suggested by its classification in slide 3 of the physical access control presentation. More generally, any authentication method that does not include a revocation check should not be deemed to provide very high security. That includes BIO-A, OCC-AUTH, SM-AUTH + PIN, SYM-CAK + BIO and SM-AUTH + BIO, all of which appear in the last row of the LOA table.

It should be noted that some authentication methods may provide high confidence in the identity of the cardholder, and yet provide little security. An example is SM-AUTH + BIO which provides three-factor authentication by PIN, fingerprint, and proof of possession of a cryptographic credential, and is included in the last row of the LOA table as providing very high confidence in the identity of the cardholder. Another example is SM-AUTH + BIO-A, not mentioned in the LOA table, which provides even higher confidence because it is harder to spoof a fingerprint in the presence of a guard. These mechanisms provide little security because they do not check for revocation, and thus allow any former federal employee who has refused to surrender his or her PIV card to continue entering government buildings for an indefinite period of time.

Confidence in the identity of the cardholder is not an appropriate security criterion for access control. Access control security requires both authentication security and authorization security, and authorization security requires a check for credential revocation.

Coping with FIPS 140

FIPS 140, Security Requirements for Cryptographic Modules is a NIST standard that is used by NIST-accredited laboratories to certify cryptographic modules used in products sold to the federal government. The standard and the certification program have been so successful that they are widely used internationally to certify products not necessarily intended for the US government.

But FIPS 140 is an old standard, which has not been revised since FIPS 140-2 was issued in May 2001. The evolution of technology over the last 14 years has caused not just the details but also the underlying philosophy of the standard to become out of date.

FIPS standards are supposed to be revised every five years. An effort to revise FIPS 140-2 was initiated in 2005 and led to a draft of FIPS 140-3 being published in 2009; but the effort was later abandoned. There are rumors that ISO 19790:2012 is a candidate to succeed FIPS 140-2. But neither the draft of FIPS 140-3 nor ISO 19790:2012 seem to embody the fundamental rethinking needed to catch up with current technologies. Meanwhile, in the absence of a revised version of FIPS 140, adherence to the old FIPS 140-2 is causing difficulties for the implementation of both derived credentials and PIV cards.

One difficulty caused by FIPS 140-2 is that it requires power-up and run-time self-tests. In measurements made by the General Services Administration (GSA) and reported at the workshop in a presentation by Chi Hickey of GSA (see slide 5, “Crypto Pre-Checks“) and another presentation by Apostol Vassilev of NIST (see the entry “FIPS 140-2 POST” in slide 2, where POST stands for Power-On Self-Test), those self-tests contributed between 0.6 and 1.0 seconds to the four seconds it takes to gain physical access using the asymmetric Card Authentication Key stored in a PIV card. (The four-second delay is a topic that was extensively debated at the workshop and that I plan to discuss in the next post.)

Self-tests also affect derived credentials in several ways. One of the comments on Draft SP 800-157, comment 360 by Giesecke & Devrient, noted that they could conflict with UICC performance requirements, if derived credentials were to be stored in a UICC chip within a mobile device; that point was also made in a presentation by Giesecke & Devrient at the workshop, discussed below. Frequent computationally expensive self-tests of cryptographic algorithms, of doubtful security value, could also severely affect battery life. Self-tests need to be thoroughly rethought in preparation for the long-overdue revision of FIPS 140-2.

A second difficulty caused by FIPS 140-2 is the need to recertify a cryptographic module after every minor change. Another one of the comments on Draft SP 800-157, comment 252 by Emergent LLC, pointed out that this is unfeasible for derived credentials, as the rate of change in mobile device hardware and software far exceeds the rate at which recertification is possible. The same point was made in a comment during a question-and-answer exchange at the workshop, and in a USDA pilot presentation, discussed below. But recertification has also become a problem for PIV cards, as the rate of card firmware changes accelarates. This was addressed at the workshop by Ketan Mehtan in his talk on INCITS 504, a draft standard of the InterNational Committee for International Technology Standards, also known as ANSI 504 or GICS. Slide 8 proposes, as “Use Case 1” for the standard, to “Maintain FIPS 140-2 Certification“. The idea is to implement a PIV card by installing a PIV application on a GICS platform implemented in the card and certified against FIPS 140-2. It seems that this makes it allowable to modify the card without having to recertify it, but I did not understand how. Any comments explaining that would be appreciated.

A third difficulty caused by FIPS 140-2 is specific to derived credentials. FIPS 140-2 relies exclusively on physical tamper resistance for protection of a cryptographic module in a mobile device against physical capture of the device by an adversary. By contrast, mobile devices protect data today by encrypting it. The next version of FIPS 140 should allow encryption as an alternative or supplement to physical tamper resistance for the protection of sensitive security parameters and data kept in a cryptographic module. I argued that derived credentials should be encrypted in Part 2.

Derived Credentials

Most of the second day of the workshop was dedicated to derived credentials. Sadly, there was no discussion of the main outstanding issue concerning derived credentials: the obvious security gap created by storing them in “software tokens” without encryption or physical tamper resistance. But the workshop did discuss other topics related to derived credentials, and provided interesting information.

The portion of the workshop concerned with derived credentials started with a presentation on SP 800-157 by Hildegard Ferraiolo, and a presentation on a forthcoming certificate policy for derived credentials by Matt King and Wendy Brown of the Federal Public Key Infrastructure Policy Authority (FPKIPA). The latter was not one of the presentations ignoring the narrow-scope policy. On the contrary, it emphasized that only some uses of derived credentials are allowed and specifically highlighted uses that are prohibited.

The presentation listed in the agenda as Derived PIV Credential Test Requirements and Conformance, by Ramaswamy Chandramouli, was a status update on a new NIST Special Publication, SP 800-166, whose first draft is expected to be published on April 24, 2015. The publication will provide guidelines for the testing of the Derived PIV Applications that will store and manage derived credentials, but will only be concerned with “non-embedded tokens” such as microSD, USB or UICC tokens, the testing of “embedded tokens” (which include software tokens, TEE tokens, and Embedded-Secure-Element tokens), being deemed a hard problem.

The presentation listed as Derived PIV Credential Issuer Accreditation, also by Ramaswamy Chandramouli, provided an overview of Draft SP 800-79-2, published in June 2014. (The slides say June 2015, but that must be a typo.) This revision of SP 800-79 adds 74 “controls“, 53 of them specifically related to derived credentials. Publication of the final version of SP 800-79-2 is expected soon.

The presentation listed as NCCoE Proof of Concept for Derived PIV Credential, by Jeffrey Cichonsky, described plans for a proof of concept implementation of derived credentials. NCCoE is the National Cybersecurity Center of Excellence. The slides include a Derived PIV Lifecycle chart (slide 9) and a workflow for the issuance of derived credentials at Level Of Assurance (LOA) 4 (slide 10).

The NCCoE talk was followed by two presentations describing ongoing derived credential pilots at the Department of Defense (DoD) and the Department of Agriculture (USDA).

Greg Youst of the Defense Information Systems Agency (DISA) discussed a DoD iOS Soft Certificate Pilot involving 14 users. The pilot uses software tokens, NSA having told DISA that keeping derived credentials in the key store is “good enough for iOS and Samsung“. Initially, credentials were generated, certified and installed manually, but that took 2.5 hours per device and required a 70-slide presentation for training Registration Authority (RA) personnel. An over-the-air (OTA) provisioning flow is now being implemented for iOS, to be followed by OTA provisioning flows for Samsung devices, and “down the road” for Windows and Blackberry devices. The presentations listed on the agenda as Side Loading Software Certificates on CMDs and Purebred were not presented; I believe the first one describes the initial provisioning method and the second one the OTA method.

The USDA pilot was described by Adam Zeimet. The talk included a wealth of information that is not in the slides, so I recommend watching the presentation in the archived webcast if interested (at the end of Day 2, Part 2). A summary follows.

The number of mobile devices in use at the USDA has doubled over the last year to more than 15,000. Mobile devices allow USDA employees doing field work to spend up to 4 days in the field, instead of 1-2 days in the field followed by 3-4 days of data entry in the office. But when using mobile devices they have to log in to USDA servers with username or password rather than a PIV card.

The initial goal of the pilot was to provide secure authentication on mobile devices, for three purposes: to access Exchange ActiveSync servers; to log in to an eAuthentication portal that provides access to more than 450 USDA web apps; and for native apps to access their remote backends. But another important goal has emerged: to use a smart phone as a PIV backup for user authentication on a laptop or desktop. This would help achieve full PIV compliance, and would address recurring complaints of employees whose card is lost, stolen, or forgotten when leaving for a field trip, and are then unable to do their work for several days. (Notice that this is one of “prohibited” uses of derived credentials.)

The pilot uses a software implementation of derived credentials. The first phase of the pilot is a proof of concept in a lab environment. 75-80% of target use cases have been successfully tested, but authentication to an Exchange ActiveSync server is not working yet. A second phase will extend testing to USDA subagencies or bureaux, and a third phase will reassess the technology before deploying it throughout the agency.

Challenges include: integrating many native apps that are not PIV-enabled or even PKI-enabled today; finding device-agnostic solutions that work across iOS, Android and Windows devices; and keeping FIPS 140 level 1 validation up-to-date in a rapidly changing mobile environment. On the other hand the PIV backup work looks promising. It relies on a Bluetooth connection between the phone and the laptop or desktop, using dongles that provide “extra layers of encryption” on top of Bluetooth.

The pilot presentations were followed by two private-sector talks on Derived PIV Credentials token form factors. In his presentation, Christopher Goyet of Oberthur compared the pros and cons of PIV cards and derived credentials stored in embedded security elements, UICC chips, and microSD cards. He made the interesting point that a card features a fallback authentication mechanism for physical access (visual inspection of the card by a guard) when electronic verification becomes unavailable. In his presentation, Werner Ness of Giesecke & Devrient recapitulated the concept of Derived PIV Credentials and the form factors that are being considered for carrying them, including a software key store, a Trusted Execution Environment, a USB token, a UICC chip, a secure microSD card, and an embedded secure element. Then he described the products and activities of Giesecke & Devrient related to derived credentials. Both speakers mentioned a variety of use cases for derived credentials, including use cases such as physical access that are prohibited by NIST and FPKIPA, as discussed above.

The workshop concluded with a most interesting talk but Bill Burr on Future Tokens for Derived PIV Credentials, including an in-depth discussion of Bluetooth and whether it should play a role in connection with derived credentials. But I leave that for the blog post after next. In the next post I intend to discuss the the four-second physical access problem.

See also:

• 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 6: NIST Looks at EMV to Speed up Physical Access with PIV Contactless Cards
• Part 7: Has Bluetooth Become Secure?
• Pomcor’s Derived Credentials page