Has Bluetooth Become Secure?

Bluetooth has a bad reputation when it comes to security. Many vulnerabilities have been found over the years in the technology, and many successful attacks have been demonstrated against it. But the Bluetooth specification has also changed much over the years, and each revision of the specification has made substantial changes to the Bluetooth security protocols. Whether the latest protocols are secure is a question open to debate. This question is especially important when Bluetooth is used in emerging medical and Internet-of-Things applications where security flaws have safety implications. But it has also come up recently in the context of the Derived Credentials being standardized by NIST for authentication of Federal employees who use mobile devices.

(This is a continuation of the last two posts, which reported on the recent NIST Workshop on PIV-Related Special Publications. It is also the last of a seven-part series of posts discussing the public comments on Draft 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.)

Before tackling the question of whether Bluetooth is secure today, Continue reading “Has Bluetooth Become Secure?”

NIST Looks at EMV to Speed up Physical Access with PIV Contactless Cards

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 Continue reading “NIST Looks at EMV to Speed up Physical Access with PIV Contactless Cards”

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. Continue reading “Highlights of the NIST Worshop on PIV-Related Special Publications”

Biometrics and Derived Credentials

This is Part 4 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.

As reviewed in Part 3, a PIV card carries two fingerprint templates for off-card comparison, and may also carry one or two additional fingerprint templates for on-card comparison, one or two iris images, and an electronic facial image. These biometrics may be used in a variety of ways, by themselves or in combination with cryptographic credentials, for authentication to a Physical Access Control System (PACS) or a local workstation. The fingerprint templates for on-card comparison can also be used to activate private keys used for authentication, email signing, and email decryption.

By contrast, neither the draft version nor the final version of SP 800-157 consider the use of any biometrics analogous to those carried in a PIV card for activation or authentication. Actually, they “implicitly forbid” the storage of such biometrics by the Derived PIV Application that manages the Derived PIV Credential, according to NIST’s response to comment 30 by Precise Biometrics.

But several comments requested or suggested the use of biometrics by the Derived PIV Application. In this post I review those comments, and other comments expressing concern for biometric privacy. Then I draw attention to privacy-preserving biometric techniques that should be considered for possible use in activating derived credentials.
Continue reading “Biometrics and Derived Credentials”

Biometrics in PIV Cards

This is Part 3 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.

After Part 1 and Part 2, in this Part 3 I intended to discuss comments received by NIST regarding possible uses of biometrics in connection with derived credentials. But that requires explaining the use of biometrics in PIV cards, and as I delved into the details, I realized that this deserves a blog post of its own, which may be of interest in its own right. So in this post I will begin by reviewing the security and privacy issues raised by the use of biometrics, then I will recap the biometrics carried in a PIV card and how they are used.

Biometric security

When used for user authentication, biometrics are sometimes characterized as “something you are“, while a password or PIN is “something you know” and a private key stored in a smart card or computing device is “something you have“, “you” being the cardholder. However this is only an accurate characterization when a biometric sample is known to come from the cardholder or device user, which in practice requires the sample to be taken by, or at least in the presence of, a human attendant. How easy it was to dupe the fingerprint sensors in Apple’s iPhone (as demonstrated in this video) and Samsung’s Galaxy S5 (as demonstrated in this video) with a spoofed fingerprint shows how difficult it is to verify that a biometric sample is live, Continue reading “Biometrics in PIV Cards”

NIST Omits Encryption Requirement for Derived Credentials

This is Part 2 of a series of posts reviewing the public comments received by NIST on Draft SP800-157, Guidelines for Derived Personal Identity Verification (PIV) Credentials, their disposition, and the final version of the document. Links to all the posts in the series can be found here.

In the first post of this series I discussed how NIST failed to address many concerns expressed in the 400+ comments that it received on the guidelines for derived credentials published in March of last year as Draft Special Publication (SP) 800-157, including concerns about insufficient discussion of business need, lack of guidance, narrow scope, lack of attention to embedded solutions, and security issues. But I postponed a discussion of what I think is the most critical security problem in SP800-157: the lack of security of the so-called software tokens, a concern that was raised in comments including 111 by the Treasury, 291, 311 and 318 by ICAMSC, 406 by PrimeKey AB, 413 by NSA, and 424 by Exponent. This post focuses on that problem.

The concept of a software token, or software cryptographic module is defined in Draft NISTIR 7981 (Section 3.2.1) as follows:

Rather than using specialized hardware to store and use PIV keys, this approach stores the keys in flash memory on the mobile device protected by a PIN or password. Authentication operations are done in software provided by the application accessing the IT system, or the mobile OS.

What does it mean for the keys to be “protected by a PIN or password“?
Continue reading “NIST Omits Encryption Requirement for Derived Credentials”

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). Continue reading “NIST Fails to Address Concerns on Derived Credentials”

Protecting Derived Credentials without Secure Hardware in Mobile Devices

NIST has recently released drafts of two documents with thoughts and guidelines related to the deployment of derived credentials,

and requested comments on the drafts by April 21. We have just sent our comments and we encourage you to send yours.

Derived credentials are credentials that are derived from those in a Personal Identity Verification (PIV) card or Common Access Card (CAC) and carried in a mobile device instead of the card. (A CAC card is a PIV card issued by the Department of Defense.) The Electronic Authentication Guideline, SP 800-63, defines a derived credential more broadly as:

A credential issued based on proof of possession and control of a token associated with a previously issued credential, so as not to duplicate the identity proofing process.

A PIV/CAC card may carry a PIV authentication credential, a digital signature credential, a current key management credential and up to 20 retired key management credentials, each credential consisting of a private key and an associated certificate that contains the corresponding public key. The digital signature private key is used for signing email messages, and the key management keys for decrypting symmetric keys used to encrypt email messages. The retired key management keys are needed to decrypt old messages that have been saved encrypted. The PIV authentication credential is mandatory for all users, while the digital signature credential and the current key management credential are mandatory for users who have government email accounts.

A mobile device may similarly carry an authentication credential, a digital signature credential, and current and retired key management credentials. Although this is not fully spelled out in the NIST documents, the current and retired key management private keys in the mobile device should be able to decrypt the same email messages as those in the card, and therefore should be the same as those in the card, except that we see no need to limit the number of retired key management private keys to 20 in the mobile device. The key management private keys should be downloaded to the mobile device from the escrow server that should already be in use today to recover from the loss of a PIV/CAC card containing those keys. On the other hand the authentication and digital signature key pairs should be generated in the mobile device, and therefore should be different from those in the card.

In a puzzling statement, SP 800-157 insists that only an authentication credential can be considered a “derived PIV credential”:

While the PIV Card may be used as the basis for issuing other types of derived credentials, the issuance of these other credentials is outside the scope of this document. Only derived credentials issued in accordance with this document are considered to be Derived PIV credentials.

Nevertheless, SP 800-157 discusses details related to the storage of digital signature and key management credentials in mobile devices in informative appendix A and normative appendix B.

Software Tokens

The NIST documents provide guidelines regarding the lifecycle of derived credentials, their linkage to the lifecycle of the PIV/CAC card, their certificate policies and cryptographic specifications, and the storage of derived credentials in several kinds of hardware cryptographic modules, which the documents refer to as hardware tokens, including microSD tokens, UICC tokens, USB tokens, and embedded hardware tokens. But the most interesting, and controversial, aspect of the documents concerns the storage of derived credentials in software tokens, i.e. in cryptographic modules implemented entirely in software.

Being able to store derived credentials in software tokens would mean being able to use any mobile device to carry derived credentials. This would have many benefits:

  1. Federal agencies would have the flexibility to use any mobile devices they want.
  2. Federal agencies would be able to use inexpensive devices that would not have to be equipped with special hardware for secure storage of derived credentials. This would save taxpayer money and allow agencies to do more with their IT budgets.
  3. Mobile authentication and secure email solutions used by the Federal Government would be affordable and could be broadly used in the private sector.

The third benefit would have huge implications. Today, the requirement to use PIV/CAC cards means that different IT solutions must be developed for the government and for the private sector. IT solutions specifically developed for the government are expensive, while private sector solutions too often rely on passwords instead of cryptographic credentials. Using the same solutions for the government and the private sector would lower costs and increase security.

Security

But there is a problem. The implementation of software tokens hinted at in the NIST documents is not secure.

NISTIR 7981 describes a software token as follows:

Rather than using specialized hardware to store and use PIV keys, this approach stores the keys in flash memory on the mobile device protected by a PIN or password. Authentication operations are done in software provided by the application accessing the IT system, or the mobile OS.

And SP 800-157 adds the following:

For software implementations (LOA-3) of Derived PIV Credentials, a password-based mechanism shall be used to perform cryptographic operations with the private key corresponding to the Derived PIV Credential. The password shall meet the requirements of an LOA-2 memorized secret token as specified in Table 6, Token Requirements per Assurance Level, in [SP800-63].

Taken together, these two paragraphs seem to suggest that the derived credentials should be stored in ordinary flash memory storage encrypted under a data encryption key derived from a PIN or password satisfying certain requirements. What requirements would ensure sufficient security?

Smart phones are frequently stolen, therefore we must assume that an adversary will be able to capture the mobile device. After capturing the device the adversary can immediately place it in a metallic box or other Faraday cage to prevent a remote wipe. The contents of the flash memory storage may be protected by the OS, but in many Android devices, the OS can be replaced, or rooted, with instructions for doing so provided by Google or the manufacturer. OS protection may be more effective in some iOS devices, but since a software token does not provide any tamper resistance by definition, we must assume that the adversary will be able to extract the encrypted credentials. Having done so, the adversary can mount an offline password guessing attack, testing each password guess by deriving a data encryption key from the password, decrypting the credentials, and checking if the resulting plaintext contains well-formed credentials. To carry out the password guessing attack, the adversary can use a botnet. Botnets with tens of thousands of computers can be easily rented by the day or by the hour. Botnets are usually programmed to launch DDOS attacks, but can be easily reprogrammed to carry out password cracking attacks instead. The adversary has at least a few hours to run the attack before the authentication and digital signature certificates are revoked and the revocation becomes visible to relying parties; and there is no time limit for decrypting the key management keys and using them to decrypt previously obtained encrypted email messages.

To resist such an attack, the PIN or password would need to have at least 64 bits of entropy. According to Table A.1 of the Electronic Authentication Guideline (SP 800-63), a user-chosen password must have more than 40 characters chosen appropriately from a 94-character alphabet to achieve 64 bits of entropy. Entering such a password on the touchscreen keyboard of a smart phone is clearly unfeasible.

SP 800-157 calls instead for a password that meets the requirements of an LOA-2 memorized secret token as specified in Table 6 of SP 800-63, which are as follows:

The memorized secret may be a randomly generated PIN consisting of 6 or more digits, a user generated string consisting of 8 or more characters chosen from an alphabet of 90 or more characters, or a secret with equivalent entropy.

The equivalent entropy is only 20 bits. Why does Table 6 require so little entropy? Because it is not concerned with resisting an offline guessing attack against a password that is used to derive a data encryption key. It is instead concerned with resisting an online guessing attack against a password that is used for authentication, where password guesses can only be tested by attempting to authenticate to a verifier who throttles the rate of failed authentication attempts. In Table 6, the quoted requirement on the memorized secret token is coupled with the following requirement on the verifier:

The Verifier shall implement a throttling mechanism that effectively limits the number of failed authentication attempts an Attacker can make on the Subscriber’s account to 100 or fewer in any 30-day period.

and the necessity of the coupling is emphasized in Section 8.2.3 as follows:

When using a token that produces low entropy token Authenticators, it is necessary to implement controls at the Verifier to protect against online guessing attacks. An explicit requirement for such tokens is given in Table 6: the Verifier shall effectively limit online Attackers to 100 failed attempts on a single account in any 30 day period.

Twenty bits is not sufficient entropy for encrypting derived credentials, and requiring a password with sufficient entropy is not a feasible proposition.

Solutions

But the problem has solutions. It is possible to provide effective protection for derived credentials in a software token.

One solution is to encrypt the derived credentials under a high-entropy key that is stored in a secure back-end and retrieved when the user activates the software token. The problem then becomes how to retrieve the high-entropy key from the back-end. To do so securely, the mobile device must authenticate to the back-end using a device-authentication credential stored in the mobile device, which seems to bring us back to square one. However, there is a difference between the device-authentication credential and the derived credentials stored in the token: the device-authentication credential is only needed for the specific purpose of authenticating the device to the back-end and retrieving the high-entropy key. This makes it possible to use as device-authentication credential a credential regenerated on demand from a PIN or password supplied by the user to activate the token and a protocredential stored in the device, in a way that deprives an attacker who captures the device of any information that would make it possible to test guesses of the PIN or password offline.

The device-authentication credential can consist, for example, of a DSA key pair whose public key is registered with the back-end, coupled with a handle that refers to a device record where the back-end stores a hash of the registered public key. In that case the protocredential consists of the device record handle, the DSA domain parameters, which are (p,q,g) with the notations of the DSS, and a random high-entropy salt. To regenerate the DSA key pair, a key derivation function is used to compute an intermediate key-pair regeneration key (KPRK) from the activation PIN or password and the salt, then the DSA private and public keys are computed as specified in Appendix B.1.1 of the DSS, substituting the KPRK for the random string returned_bits produced by a random number generator.

To authenticate to the back-end and retrieve the high-entropy key, the mobile device establishes a TLS connection to the back-end, over which it sends the device record handle, the DSA public key, and a signature computed with the DSA private key on a challenge derived from the TLS master secret. (Update—April 24, 2014: The material used to derive the challenge must also include the TLS server certificate of the back-end, due to a recently reported UKS vulnerability of TLS. See footnote 2 of the technical report.) The DSA public and private keys are deleted after authentication, and the back-end keeps the public key confidential. An adversary who is able to capture the device and extract the protocredential has no means of testing guesses of the PIN or password other than regenerating the DSA key pair and attempting online authentication to the back-end, which locks the device record after a small number of consecutive failed authentication attempts that specify the handle of the record.

An example of a derived credentials architecture that uses this solution can be found in a technical report.

Other solutions are possible as well. The device-authentication credential itself could serve as a derived credential, as we proposed earlier; SSO can then be achieved by sharing login sessions, as described in Section 7.5 of a another technical report. And I’m sure others solutions can be found.

Other Topics

There are several other topics related to derived credentials that deserve discussion, including the pros and cons of storing credentials in a Trusted Execution Environment (TEE), whether biometrics should be used for token activation, and whether derived credentials should be used for physical access. I will leave those topics for future posts.

Update (April 10, 2014). A post discussing the storage of derived credentials in a TEE is now available.

Techniques for Implementing Derived Credentials on Mobile Devices

Update (April 3, 2013). There is a more recent blog post with important new information on the topic of derived credentials.

Update (September 25, 2012). We made a presentation on this topic at the Cryptographic Key Management Workshop that was held on September 10-11 at NIST.

We live in the Age of Mobile, and US Federal agencies, like all enterprises, want their employees to use smart phones and tablets. But they face a serious obstacle: how to authenticate users on mobile devices securely.

As I noted in the previous post, ordinary passwords are even less secure on mobile devices than on desktops and laptops, and one-time passwords provide only limited security because they can be intercepted or observed and they remain valid for several minutes. Authentication of federal employees requires the much stronger cryptographic and biometric security provided by Personal Identity Verification (PIV) smartcards in civilian agencies and Common Access Cards (CAC) in the Department of Defense.

It is difficult to use a smartcard to authenticate a user who is accessing an application on a mobile device. A contactless card could communicate with the device via Near Field Communication (NFC), but some mobile devices, including the iPhone, are not equipped with NFC today. A card reader could communicate with the mobile device via Bluetooth or WiFi, but that requires the user to carry three pieces of equipment: the card, the phone and the card reader.

NIST is working on a better authentication solution: derived credentials, which would provide the same security strength as PIV credentials but would be stored in the mobile device rather than in a separate smartcard. The Electronic Authentication Guideline defines a derived credential as a credential issued based on proof of possession and control of a token associated with a previously issued credential, so as not to duplicate the identity proofing process.

Derived credentials are a very good idea, but they present several challenges. One challenge is the cost of verifying a client certificate chain, in terms of bandwidth, latency and battery life. Another challenge is the lack of tamper resistant storage for credentials and biometric data in mobile devices. Yet another challenge is the complexity of cryptographic and biometric technology, which most app developers are not familiar with.

I believe that these challenges can be addressed using three techniques used in the mobile authentication methods that we described in the white paper

which I summarized in the previous post. We have written another white paper,

that describes each technique separately.

The first technique eliminates the costs associated with verifying client certificate chains by using public key cryptography without certificates. The device demonstrates knowledge of a private key, and the application verifies that the hash of the associated public key matches a field of a device record stored in an enterprise directory. The device record, in turn, contains a reference to a user record, identifying the user as the owner of the device.

The second technique obviates the need for tamper-resistant storage. Tamper-resistant storage is usually needed when a PIN and/or a biometric sample is used to enable the use of a key pair, so that an attacker cannot extract the key pair and use it without providing the PIN and/or the biometric, or extract the biometric template, or mount an offline attack against the PIN. We avoid the need for tamper resistance by regerenating the key pair from the PIN or from a biometric key derived from a biometric sample and an auxiliary string. An attacker who tampers with the device gains no advantage because the only way to know if a regenerated key is the correct one is by using it for online authentication.

The third technique shields app developers from the complexities of cryptography and biometrics by encapsulating the cryptographic and biometric computations in a Prover Black Box, which can be provided as a separate native app on the mobile device, and a Verifier Black Box, which can implemented as a server appliance. The application, which may interact with the user via a browser or via a native front-end, outsources authentication to the black boxes using interapp communication facilities available at least in iOS and Android.

The white paper has figures and more details.