NIST Fails to Address Concerns on Derived Credentials

This is the first of a series of posts reviewing the comments received by NIST on Draft SP800-157, their disposition, and the final version of the document. Links to all the posts in the series can be found here.

In March 2014, NIST released the drafts of two documents on derived credentials, Draft NISTIR 7981 and Draft SP800-157, and requested comments. Last month it announced that it had received more than 400 comments and released a file with comments and their dispositions.

The file is hard to read, because it contains snippets of comments rather than entire comments (and snippets of comments by the same organization are not always consecutive!). But we have made the effort to read it, and the effort was worth it. The file contains snippets from companies, individuals, industry organizations, and many US Federal government organizations, including the Consumer Financial Protection Bureau (CFPB), the Coast Guard, the Department of Justice (DOJ), the Department of the Treasury, the Department of Agriculture Mobility Program Management Office (USDA MPO), the Department of State (DOS) the Social Security Administration (SSA), the National Aeronautics and Space Administration (NASA), the Department of Homeland Security (DHS), the Air Force Public Key Infrastructure System Program Office (AF PKI SPO), the Identity, Credential, and Access Management Subcommittee (ICAMSC), the Centers for Disease Control and Prevention (CDC), the Federal Public Key Infrastructure Certificate Policy Working Group (FPKI CPWG) and the Information Assurance Directorate of the National Security Agency (NSA).

Given the number and depth of the comments, it would have been a good idea to issue a revised draft and ask for a second round of comments (as NIST has recently done, for example, in connection with NISTIR 7977), or to call a conference, or both. Instead, NIST issued a final version of SP800-157 that fails to address serious concerns expressed in the comments. As of this writing the draft of NISTIR 7981 has not been revised. (No revised version can be found in the NISTIRs page.)

Here are some concerns that were not addressed.

1. Insufficient discussion of business need

Draft SP800-157 asserted that it is impractical to use a PIV card in conjunction with a mobile device. Comments 68 by the Treasury and 299 by ICAMSC asked for specific use cases in which such usage is deemed impractical. The ICAMSC comment said:

Please add clarification language and/or provide examples that agencies can leverage when determining if the use of a PIV Card is impractical.

NIST replied that both comments were resolved by comment 41; comment 41 is unrelated, but the response to comment 41 states that it is up to agencies to decide when the use of the PIV card is impractical.

Regarding the same assertion in Draft SP800-157, comment 22 by Precise Biometrics Inc submitted that currently available form fitted cases for mobile devices (in which a PIV card can be inserted) are practical. NIST rejected this comment as out-of-scope, saying that the topic is covered in NISTIR 7981. It should be noted, however, that NISTIR 7981 and SP800-157 are companion documents, they have the same set of authors, their drafts were issued on the same day, and comments were requested for both of them, to be sent to the same email address; and Draft NISTIR 7981 does not contemplate the use of form-fitted cases.

2. Lack of guidance

The issuance, management and usage of derived credentials is related to areas of modern mobile technology including screen locking and device encryption, device and application management, and BYOD policy. Yet Draft SP800-157 provided no guidance in any of these areas. Comments including 164 by DOS, 235 by DHS, 260 by Emergent LLC, 414-415 and 418 by NSA asked for guidance in these areas, but no guidance has been provided in the final version.

Comment 194 by the Smart Card Alliance asked whether it is the intention that the Distinguished Name (DN) for the Derived PIV authentication certificate should be the same as the DN for the original PIV authentication certificate. NIST declined to provide guidance arguing that requirements for the subject DNs in certificates are specified in Section 3.1.1 of the Common Policy. However, the requirements in Section 3.1.1 of the X.509 Certificate Policy For The U.S. Federal PKI Common Policy Framework Version 1.23 do not fully determine the DN; in particular they provide leeway on how to set the structural_container organizational unit, which might be used to distinguish the kind of token containing a credential if desired. Moreover, just as alternate OMB guidance on the Control Remote Access requirement of OMB Memorandum M-07-16 has been requested to accommodate integrated tokens, a modification of the common policy framework could be requested, if necessary to accommodate derived credentials.

Appendix A pointed out that a digital signature private key and certificate in a mobile device must be different from those in a PIV card, because the private key in the card is not exportable. In comments 205-206, NASA noted that some certificate authority products do not allow multiple active digital signature certificates for the same DN. NASA asked for guidance as to whether products should be required to allow for the issuance of multiple certificates or whether it would be acceptable to use certificates having different distinguished names or issued by different certificate authorities. NASA also asked for guidance on the challenges resulting from identity duality, and on the appropriate usage of different certificates that might be issued under different certificate policies. Comment 186 by DOS referred to the same issue. NIST declined to provide guidance in the final version of SP800-157.

Comment 206 was specifically concerned with the possible use of multiple digital signature certificates issued under different certificate policies resulting in “a mix of digital signature assurance levels being used for digital signing for the same individual”, and with “allowing an alternative signature certificate with relaxed policies”. NIST responded to comment 206 as follows:

Declined. It is up to Departments and Agencies to consider this risk as they create their digital signature certificate issuance and usage policies.

Thus NIST deemed that the issues raised in the comment create a risk that agencies should consider, but declined to mention the risk in the final version of SP800-157.

In comment 360, Giesecke & Devrient noted that SP800-157 requires hardware tokens to be cryptographic modules validated to FIPS140 L2 or higher, and that FIPS 140 requires a cryptographic module to perform self-tests. (Indeed, Section 4.9 of FIPS 140-2 requires self-tests to be performed when the cryptographic module is powered up and when certain critical functions are performed.) Giesecke & Devrient pointed out that these self-tests might conflict with performance requirements of UICC tokens. (This is indeed a concern because UICCs are used by the mobile network operator for unrelated purposes critical to the functionality of a mobile device.) The comment suggested that “a special FIPS140 scheme for UICCs should be developed which improves the concept of self tests in terms of performance”. NIST responded by saying that “this would be an issue for the Cryptographic Module Validation Program, not for SP 800-157” and declined to mention this difficulty in the final version of SP800-157. (It should be noted that the Cryptographic Module Validation Program is concerned with validating modules, and is unlikely to be concerned with the performance impact that using a UICC to store derived credentials could have on mobile device performance.)

3. Narrow scope

Many comments complained about SP800-157 having a narrow scope and failing to take advantage of desired functionality that could be provided by derived credentials.

A PIV card includes a private key for user authentication, a private key for signing email messages, a current private key for decrypting new email messages, and a set of retired private keys for decrypting old email messages. (Private keys for decrypting email messages are called key management keys by NIST.) SP800-157 discusses the storage of an equivalent set of credentials in a mobile device (each comprising a private key and the associated public key certificate), but insists that only the user authentication credential is a “derived PIV credential”. Email-related credentials are discussed in Appendix A, which is labeled as informative rather than normative. Comment 61 by Gemalto and our own comment 6 argued that email is the most important use case for derived credentials, and hence email-related credentials should have the same status as authentication credentials. In comment 227, Apple asked: “Is the Derived Credential solely for remote user authentication and nothing else? If this is indeed restricted to just user authentication, it severely limits the scope of use and value add to the mobile device.” NIST responded to these comments by saying that email-related credentials are not less important, but “they are not within the scope of this particular publication”.

Other comments suggested uses of derived credentials besides authentication and email on a mobile device.

PIV cards are used for physical access to government facilities, and derived credentials could be used for the same purpose. This functionality was requested in comments 15 and 17 by Oberthur Technologies, 62-63 by Gemalto, 187 by SSA, 250 by DHS, and 359 by Giesecke & Devrient. But it was ruled out, as stated in the response to comment 15, because “based on current policy, the Derived PIV Credential should only be used where use of a PIV Card is not practical”.

Many comments requested a scope extension to allow derived credentials to be stored and used in devices other than the smart phones, tablets and e-readers mentioned in the definition of a mobile device in Footnote 1. Comment 212 by Wave asked for the definition in Footnote 1 to be extended to include laptops, smart glasses and smart watches. Comments 236 by DHS, 325 by CDC and 356 by Giesecke & Devrient asked for allowing derived credentials to be stored in Trusted Platform Modules within computers such as laptops, desktops or workstations, or in hardware tokens connected to such computers. The responses from NIST seem to allow derived credentials on laptops on the grounds that “it is up to the agencies to decide what types of devices fall into the mobile category” (as stated in the response to a request to disambiguate Footnote 1 made in comment 41, referenced in the responses to comments 212 and 236), but rule them out on desktops and workstations on the grounds that “in their current state Derived PIV credentials are restricted to authentication of mobile devices to remote systems” (as stated in the response to comment 15, referenced in the responses to comments 325 and 356). But NIST declined to disambiguate Footnote 1 in the final version of SP800-157, left in place other language that makes it clear that laptops are not considered mobile devices (e.g. the assertion in the Executive Summary that “mobile devices lack the integrated smart card readers found in laptop and desktop computers”), and declined to provide any indication that derived credentials could be used in laptops or other computers, thus in effect rejecting the scope extension requests.

Instead of storing derived credentials in a personal computer, they could be carried in a mobile device and used by a personal computer that would access the mobile device over a wireless connection. This functionality was requested in comment 62 by Gemalto, which also requested physical access functionality, and was rejected by the same reference to comment 15, the response to which states that “based on current policy, the Derived PIV Credential should only be used where use of a PIV Card is not practical”.

Other uses of derived credentials were requested by Apple, DHS and Giesecke & Devrient. In comment 227 Apple requested using derived credentials to protect data at rest, besides using them for authentication and email. DHS requested using them for workstation logon, in the same comment 250 where it requested physical access functionality. In comment 357 Giesecke & Devrient requested using derived credentials for encrypted voice communication, encrypted cloud storage and Windows logon. All these requests were rejected with reference to comment 15.

The above-mentioned response to comment 15 includes the following blanket prohibition on allowing the PIV Derived Application to use the NFC interface of a mobile device:

Based on current policy, the Derived PIV Credential should only be used “where use of a PIV Card is not practical.” Thus, the PIV Derived Application should not be accessed over the mobile device’s NFC interface, as any use case involving accessing the PIV Derived Application over an NFC interface (e.g., getting access to buildings) would be a use case in which it would be practical to use the PIV Card.

This prohibition precludes a convenient method of obtaining a derived credential for an NFC-enabled mobile device, by authenticating to the issuer on the mobile device itself with a PIV card through the NFC interface. This convenient issuance method was proposed by Giesecke & Devrient in comment 358, which requested examples of issuance methods. In response to the comment, NIST didn’t explicitly reject the method; but it referred to comment 83, whose response referred in turn to an appendix added to the final version of SP800-157, which contains examples of issuance methods, but not the one proposed by Giesecke & Devrient.

4. Lack of attention to embedded solutions

Section 3.3.1 of Draft SP800-157 referred to three specific kinds of removable hardware tokens: Secure Digital (SD) Cards, Universal Integrated Circuit Cards (UICC) and Universal Serial Bus (USB) tokens. Section 3.3.2, on the other hand, referred very briefly to embedded tokens as comprising hardware and software tokens, without mentioning any specific kind of hardware tokens. Removable tokens were thus emphasized in spite of the substantial drawbacks of SD Cards, UICCs and USB tokens discussed in sections 3.2.1 and 3.2.2 of Draft NISTIR 7981, and in spite of the fact that the motivation for using derived credentials is the supposed inconvenience of using PIV Cards, which are themselves removable tokens. (Additional drawbacks of removable devices were surfaced in comments 360 by Giesecke & Devrient and 410 by NSA regarding UICCs, and comment 11 by Oberthur Technologies regarding SD cards.)

The lack of attention to embedded solutions could be explained by the following puzzling statement in Draft NISTIR 7981, lines 361-363, which is clearly untrue:

While some mobile devices have a form of an embedded hardware security module, currently they are either unavailable for use or do not provide the specific set of features needed to support PKI credentials.

In comment 417, NSA strongly objected to the lack of attention paid to embedded tokens:

Overall, we are concerned by the amount of attention paid to various removable hardware token solutions compared to the level of discussion surrounding the embedded tokens. We believe that due to the costs, usability, lack of commercial market viability, and incompatibility of using hardware tokens, most agencies are going to opt for an embedded solution, and the comparative lack of guidance in this area will make this solution more difficult to implement. We recommend solutions be usable, commercially sustainable, and secure.

Many other comments asked for better guidance on embedded tokens. Comments 204 by NASA, 211, 213 and 214 by Wave, and 223-224 by Microsoft emphasized the availability and advantages of Trusted Platform Modules (TPM). Comment 232 by Apple referred to the section on embedded cryptographic tokens as being extremely weak. Comment 361 by Giesecke & Devrient asked whether a Trusted Execution Environment (TEE) is an embedded hardware token. Comment 419 by Global Platform called attention to the availability of embedded Secure Elements (SE). Comments 420-421 also by Global Platform described the advantages of a TEE, including the fact that it provides a Trusted User Interface. (In our own comments we discussed the pros and cons of a TEE for implementing derived credentials; unfortunately that portion of our comments was not included in the file of comments and dispositions released by NIST. The full version of our comments can be found in our site.)

The responses to these comments were inconsistent. On one hand, in response to comment 361, NIST stated that embedded hardware solutions are not commercially available at this time. On the other hand, the response to comment 204, which requested that TPMs be mentioned, was as follows:

Resolved by including a pointer to the NISTIR in Section 3.3.2. (TPM, TEE, OS key store, SE).

NISTIR 7981, however, makes no explicit mention of any TPM, TEE, OS key store or SE.

In the final version of SP800-157, NIST added a mention of “a hybrid approach where the key is stored in hardware, but a software cryptographic module uses the key during an authentication operation”. But it did not discuss the kind of hardware that the key is stored in, and it continued to omit any mention of a TPM, a TEE or a SE.

5. Security issues

SP800-157 allows the original PIV credential and the derived PIV credential to be issued by different organizations. This creates creates two security problems:

  1. An adversary could obtain a derived credential using a compromised original credential before the compromised original credential has been revoked, and, if no precautions are taken, the fraudulently issued derived credential could survive revocation of the original credential. This risk exists even if the original and derived credentials are issued by the same organization, but is much easier to mitigate in that case.
  2. If no precautions are taken, a derived credential could unintentionally remain valid after the original credential has been terminated.

To address the first problem, Draft SP800-157 required the revocation status of the original credential to be rechecked seven days after issuance of the derived credential. But, obviously, seven days is plenty of time for the adversary to carry out attacks. The requirement was changed to a recommendation (“shall” was changed to “should”) in the final version. The final version also added Footnote 9, recommending to investigate, when a PIV card is reported lost or stolen, whether it might have been used to fraudulently issue derived credentials, but only in cases where the issuer of the PIV card is also the issuer of derived credentials.

To address the second problem, Draft SP800-157 required the issuer of the derived credential to track the status of the PIV card containing the original credential; and it pointed out that it is not sufficient to track the status of the PIV Authentication certificate, because the certificate is not necessarily revoked when the PIV card is terminated.

In cases where the issuer of the derived credential is different from the issuer of the PIV card, Draft SP800-157 suggested using the Federal Backend Attribute Exchange (BAE) or a Uniform Reliability and Revocation Service (URRS) to obtain the termination status of the PIV card. The final version more specifically suggested checking the status every 18 hours, after noting that Section 2.9.4 of FIPS 201-2 requires PIV Card termination to be performed within 18 hours for cases where the PIV card cannot be collected. It is not clear why the periodicity of the status check should be the same as the delay in performing termination; that may double the time during which a credential that should no longer be valid can be used fraudulently, making it 36 hours.

Comment 309 by ICAMSC pointed out that the BAE does not maintain revocation information for PIV Credentials, and NIST acknowledged that a new attribute would have to be created to support the termination status check functionality.

The concept of a Uniform Reliability and Revocation Service was proposed in NISTIR 7817, but we have seen no indication that such a service has been implemented.

As an alternative way of tracking the status of the PIV card when the issuer of the derived credential is different from the issuer of the PIV card, the draft suggested that the latter send a notification to the former when the PIV card is terminated. (In response to comment 198 by the Smart Card Alliance, the final version added a suggestion that the issuer of the derived credential notify the card issuer when the derived credential is created.) But relying on notification of card termination raises the issue of how to deal with an attack where the adversary prevents the notification from reaching the derived credential issuer.

Comment 174 by DOS (and duplicate comment 339 by FPKI CPWG) questioned whether different issuers should be allowed to issue the PIV card and the derived credential, and comment 182 by DOS said that it is unlikely that such a situation, allowed by the document, would occur. Comments 365 and 386-387 by CertiPath argued that the issuers should be the same. Comment 380 by CertiPath added that requiring the issuers to be the same could mitigate risks associated with the issuance of multiple derived credentials mentioned in the draft. Comments 86 by the Treasury, 150 by USDA, 238 by DHS, and 376 by CertiPath questioned the efficacy of a recheck after seven days. Comment 304 by ICAMSC and 377 by CertiPath asked what action should be taken if the seven-day recheck showed that the original credential had been revoked. In spite of all these comments, the final version of SP800-157 continues to allow the original PIV credential and the derived PIV credential to be issued by different organizations.

As noted in comment 168 by DOS (and duplicate comment 335 by FPKI CPWG), the idea of allowing different organizations to issue an original credential and a derived credential can be traced to Section 5.3.5 of the Electronic Authentication Guideline (SP800-63), which includes the recommendation to recheck the status of the original credential a week after issuing the derived credential. But SP800-63 is concerned with any kind of credentials, not just PIV credentials issued to Federal employees. In that broad context, for the sake of generality, it makes sense to consider the possibility that an organization, Federal or otherwise, would issue credentials for some particular purpose derived from original credentials issued for some other purpose by a different organization. But there is no such motivation in the case PIV credentials. In response to comment 365, NIST argued that “the capability of external issuers to issue Derived PIV Credentials allows these organizations to support other Agency employees on detail”. But PIV credentials issued by an agency, original or derived, are supposed to be verifiable by a different agency. Therefore an employee on detail to an agency should be able to use a derived credential issued by the employee’s own agency to authenticate to information systems of the agency to which the employee is detailed.

Other security problems were identified by other comments.

Comment 292 by ICAMSC and 423 by Exponent warned that malware on a computer with access to a PIV card might be able to initiate the issuance of a derived credential fraudulently. In response to comment 292, NIST stated that “verifying intent is addressed in SP 800-79-2 with issuer control # SP (DC)-1 for Derived PIV Credentials”. But Draft SP800-79-2 contains “Guidelines for the Authorization of Personal Identity Verification Card Issuers (PCI) and Derived PIV Credential Issuers (DPCI)” and control SP(DC)-1, on page 112, only says the following: “A Derived PIV Credential is issued only upon request by proper authority. Assessment Determine that: (i) the process for making a request is documented (review); (ii) A request from a valid authority is made in order to issue a Derived PIV Credential (observe)”. Thus it fails to address the specific security issue identified in the comments.

Comment 410 by NSA explained that:

While a carrier may offer a security domain on a UICC that is separate from other domains, that security domain will never be fully under the explicit control of the issuing agency. The carrier, in order to perform network operations, will control the card management key, which will allow (possibly undetected) modification of the card, the card’s firmware, and security domains on the card.

and concluded that UICC Cryptographic Modules should be removed as an acceptable solution. NIST failed to remove UICC tokens from the final version, and responded to the comment saying only that “there may need to be an SLA and level of trust involved when using an MNO’s UICC”.

But the most daunting security problems identified by the comments are those concerning software tokens. We will examine them in the next post of this series.

See also:

1 thought on “NIST Fails to Address Concerns on Derived Credentials”

  1. Nist is making a good mess of all of this by standing solidly in the way of innovation. let’s use an example.
    CAC cards the original model for smart cards in government when deployed forgot a critical piece of the smart card infrastructure. The READER. EMV the European smartcard payment spec is secure because half the system is in the card “the credential and PIN patching” the other half of the system is in the reader “secure display of the transaction and secure input of the user pin to signify Intent.”
    the DOD in it’s cybersecurity best forgot the card reader due to cost considerations. The result is that a tiny bit of malware on a government PC can steal the general’s pin number and then the card is left plugged in during the whole comput session so that Malware could execute any number of remote authentications or signing or orders operations and just supply the pin silently.
    Today Intel offers IPT on the last 18 months of supplied pcs. it provides the tools to store a Derived Credential in the PC that could be used to authenticate to the network and it support a secure User interface that assures the PIN number when entered can’t be copied it is orders of magnitude more secure. There are many ways this could be combined with the Smartcard as a token to require both technologies but it would provide finally secure pin entry for a CAC transaction. The sam exists now on Android with TUI. it is time that NIST get out of the way on preventing the advancing of cybersecurity and celebrates innovation instead. It is an organization that needs to be rebuilt. Either bigger with a bigger budget to do the job. or significantly smaller but the current system is a mess.
    Steven Sprague

Leave a Reply

Your email address will not be published. Required fields are marked *