Cryptography – Page 6

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”

Virtual Tamper Resistance is the Answer to the HCE Conundrum

Host Card Emulation (HCE) is a technique pioneered by SimplyTapp and integrated by Google into Android as of 4.4 KitKat that allows an Android app running in a mobile device equipped with an NFC controller to emulate the functionality of a contactless smart card. Prior to KitKat the NFC controller routed the NFC interface to a secure element, either a secure element integrated in a carrier-controlled SIM, or a different secure element embedded in the phone itself. This allowed carriers to block the use of Google Wallet, which competes with the carrier-developed NFC payment technology that used to be called ISIS and is now called SoftCard. (I’m not sure if or how they blocked Google Wallet in devices with an embedded secure element.) Using HCE, Google Wallet can run on the host CPU where it cannot be blocked by carriers. (HCE also paves the way to the development of a variety of NFC applications, for payments or other purposes, as Android apps that do not have to be provisioned to a secure element.)

But the advantages of HCE are offset by a serious disadvantage. An HCE application cannot count on a secure element to protect payment credentials if the device is stolen, which is a major concern because more then three million phones where stolen last year in the US alone. If the payment credentials are stored in ordinary persistent storage supplied by Android, a thief who steals the device can obtain the credentials by rooting the device or, with more effort, by opening the device and probing the flash memory.

Last February Visa and MasterCard declared their support for HCE. Continue reading “Virtual Tamper Resistance is the Answer to the HCE Conundrum”

Implementing Virtual Tamper Resistance without a Secure Channel

Last week I made a presentation to the GlobalPlatform 2014 TEE Conference, co-authored with Karen Lewison, on how to provide virtual tamper resistance for derived credentials and other data stored in a Trusted Execution Environment (TEE). I’ve put the slides online as an animated PowerPoint presentation with speaker notes.

An earlier post, also available on the conference blog, summarized the presentation. In this post I want to go over a technique for implementing virtual tamper resistance that we have not discussed before. The technique is illustrated with animation in slides 9 and 10. The speaker notes explain the animation steps.

Virtual tamper resistance is achieved by storing data in a device, encrypted under a data protection key that is entrusted to a key storage service and retrieved from the service after the device authenticates to the service using a device authentication credential, which is regenerated from a protocredential and a PIN. (Some other secret or combination of secrets not stored in the device can be used instead of a PIN, including biometric samples or outputs of physical unclonable functions.) The data protection key is called “credential encryption key” in the presentation, which focuses on the protection of derived credentials. The gist of the technique is that all PINs produce well-formed device authentication credentials, Continue reading “Implementing Virtual Tamper Resistance without a Secure Channel”

Smart Cards, TEEs and Derived Credentials

This post has also been published on the blog of the GlobalPlatform TEE Conference.

Smart cards and mobile devices can both be used to carry cryptographic credentials. Smart cards are time-tested vehicles, which provide the benefits of low cost and widely deployed infrastructures. Mobile devices, on the other hand, are emerging vehicles that promise new benefits such as built-in network connections, a built-in user interface, and the rich functionality provided by mobile apps.

Derived Credentials

It is tempting to predict that mobile devices will replace smart cards, but this will not happen in the foreseeable future. Mobile devices are best used to carry credentials that are derived from primary credentials stored in a smart card. Each user may choose to carry derived credentials on zero, one or multiple devices in addition to the primary credentials in a smart card, and may obtain derived credentials for new devices as needed. The derived credentials in each mobile device are functionally equivalent to the primary credentials, and are installed into the device by a device registration process that does not need to duplicate the user proofing performed for the issuance of the primary credentials.

The term derived credentials was coined by NIST in connection with credentials carried by US federal employees in Personal Identity Verification (PIV) cards and US military personnel in Common Access Cards (CAC); but the concept is broadly applicable. Derived credentials can be used for a variety of purposes, Continue reading “Smart Cards, TEEs and Derived Credentials”

Forthcoming Presentation at the GlobalPlatform TEE Conference

I’m happy to announce that I’ll be making a presentation at the forthcoming GlobalPlatform 2014 TEE Conference (September 29-30, Santa Clara, CA). Here are the title and abstract:

Virtual Tamper Resistance for a TEE

Derived credentials are cryptographic credentials carried in a mobile device that are derived from credentials carried in a smartcard. The term was coined by the US National Institute of Standards and Technology (NIST) in connection with US Federal employee credentials, but the concept is generally applicable to use cases encompassing high-security enterprise IDs, payment cards, national identity cards, driver licenses, etc.

The Trusted User Interface feature of a TEE can protect the passcode that activates derived credentials from being phished or intercepted by malware, the user being instructed to only enter the passcode when a Security Indicator shows that the touchscreen is controlled by the Secure OS of the TEE. Besides protecting the passcode, it is also necessary to protect the derived credentials themselves from an adversary who physically captures the device. This requires resistance against tampering. Physical tamper resistance can be provided by a Secure Element accessed from the TEE through the TEE Secure Element API, thus combining protection of the passcode against malware with protection of the credentials against physical capture.

Derived credentials can also be protected against physical capture using cloud-based virtual tamper resistance, which is achieved by encrypting them with a key stored in a secure back-end. The device uses a separate credential derived in part from the activation passcode to authenticate to the back-end and retrieve the encryption key. A novel technique makes it possible to do so without exposing the passcode to an offline guessing attack, so that a short numeric passcode is sufficient to provide strong security.

Physical tamper resistance and virtual tamper resistance have overlapping but distinct security postures, and can be combined, if desired, to maximize security.

Identity-Based Protocol Design Patterns for Machine-to-Machine Secure Channels

Cryptography is an essential tool for addressing the privacy and security issues faced by the Web and the Internet of Things. Sadly, however, there is a chronic technology transfer failure that causes important cryptographic techniques to be underutilized.

An example of an underutilized technique is Identity-Based Cryptography. It is used for secure email, although not broadly. But, to my knowledge, it has never been used to implement secure channel protocols, even though it has the potential to provide great practical advantages over traditional public key infrastructure if put to such usage. We pointed this out in our white paper on TLS. Now we have also shown the benefits of identity-based cryptography for machine-to-machine communications, in a new paper that we will present at the Workshop on Security and Privacy in Machine-to-Machine Communications (M2MSec, San Francisco, October 29, 2014). Machine-to-machine communications fall into many different use cases with very different requirements. So, instead of proposing one particular technique, we propose in the paper four different protocol design patterns that could be used to specify a variety of different protocols.

Update (August 4). I should point out that there is a proposal to use Identity-Based authenticated key exchange in conjunction with MIKEY (Multimedia Internet KEYing), a key management scheme for SRTP (Secure Real-Time Transport Protocol), which itself is used to provide security for audio and video conferencing on the Internet. The proposed authenticated key exchange protocol is called MIKEY-IBAKE and is described in RFC 6267. This is an informational RFC rather than a standards-track RFC, so it’s not clear if the proposed authenticated key exchange method will be eventually deployed. Interestingly, MIKEY-IBAKE uses identity-based encryption rather than identity-based key agreement. This is also what we do in the M2MSec paper, but with a difference. MIKEY-IBAKE uses identity-based encryption to carry ephemeral Elliptic Curve Diffie-Hellman parameters, and thus does not reduce the number of roundtrips. We use identity-based encryption to send a secret from the initiator to the responder, and we eliminate roundtrips by simultaneously sending application data protected with encryption and authentication keys derived from the secret. This gives up replay protection and forward secrecy for the first message; but replay protection, as well as forward secrecy in two of the four patterns, are provided from the second message onward.

Invited Talk at the University of Utah

I’ve been so busy that I haven’t had time to write for more than three months, which is a pity because things have been happening and there is much to report. I’m trying to catch up today.

The first thing to report is that Prof. Gopalakrishnan of the University of Utah invited Karen Lewison and myself to give a joint talk at the University, on May 29. We talked about the need to replace TLS, which I’ve discussed earlier on this blog. The slides can be found at the usual location for papers and presentations at the bottom of each page of this web site.

The University of Utah has a renowned School of Computing and it was quite stimulating to meet with faculty and discuss research after the talk. We were happy to discover common research interests, and we have been exploring the possibility of doing joint research work with Profs. Ganesh Gopalakrishnan, Sneha Kasera, and Tammy Denning; we are thrilled that the prospects look promising.

Other things to report include that we had papers accepted at the forthcoming M2MSec workshop and the forthcoming GlobalPlatform TEE conference. I will report on that in the next two posts.

Derived Credentials in a Trusted Execution Environment (TEE)

In the previous post I discussed the storage of derived credentials (Federal credentials carried in a mobile device instead of a PIV/CAC card) in a software token, i.e. in a cryptographic module implemented entirely in software, whose contents are stored in ordinary flash memory. In this post I will discuss the storage of derived credentials in a Trusted Execution Environment (TEE).

Malware Attacks

As discussed in the previous post and in a technical report, it is possible to protect derived credentials stored in ordinary flash storage by encrypting them under a high entropy key-wrapping key kept in a secure back-end, which the mobile device retrieves by authenticating to the back-end with a key pair regenerated from a protocredential and an activation passcode.

This provides effective protection against an adversary who captures the device while the software token is not active, preventing the adversary from extracting or using the credentials. But it does not provide protection against malware running on the device while the legitimate user is using the device. Such malware can carry out the following attacks:

It can use the derived credentials, by issuing instructions to the software token after it has been activated by the legitimate user.
It can read the plaintext derived credentials from the flash storage after the software token has been activated, and transmit them to the adversary responsible for the malware, who can then use them at will on a different machine.
It can capture the activation passcode by phishing or intercepting it. In a phishing attack, malware prompts the user for the passcode while masquerading as legitimate code that needs the passcode, such as token activation code. In an interception attack, malware gets the passcode after it has been obtained from the user by legitimate code.

The first of these attacks may be impossible to prevent once privileged malware is running on the mobile device without the user being aware of it. But the second and third attacks can be prevented using a TEE as we shall see below; and preventing them is important because they are more damaging than the first attack.

The second attack, extracting the credentials and sending them to the adversary, is more damaging than the first because it cannot be stopped by recovering or wiping the stolen device. Use of an authentication or signature private key cannot be stopped until the associated certificate is revoked and relying parties become aware of the revocation. Correspondents should avoid sending messages encrypted under a symmetric key wrapped by a “key management” public key after becoming aware that the key management certificate has been revoked. But there is no time limit for using a key management private key to decrypt earlier messages that the adversary may have previously captured or may capture in the future, e.g. by breaching the security of a MS Exchange server containing older encrypted messages.

The third attack is even more damaging for several reasons. First, it enables the first two attacks, because once it has the passcode, malware can activate the software token and use and extract the plaintext derived credentials. Second, if the adversary captures the device after using malware to obtain the passcode, the adversary can use the device, or install more comprehensive malware that is able to extract the credentials. Third, the passcode may be independently exploitable because it may be used for other purposes.

A TEE has security features that make it possible to prevent the second and third attacks.

Features of a TEE

A TEE is a computing environment provided by a secure OS running on the same processor as a normal OS. One or more trusted applications (TAs) run under the secure OS. A hardware bus architecture ensures that a portion of the flash storage can only be accessed by the secure OS. Both OSes can access the touchscreen, but a security indicator lets the user know when the screen is controlled by the secure OS and the user interface can be trusted. GlobalPlatform is developing TEE specifications, including a Trusted User Interface API specification, which can be downloaded from the GlobalPlatform site. TEEs are provided by ARM Cortex-A processors, where a TEE is also referred to as a TrustZone. A TA running in a TEE can be used to implement a cryptographic module in which derived credentials can be stored and used.

Using a TEE to Protect Derived Credentials

Derived credentials stored and used in a cryptographic module implemented within a TEE can be protected against the second malware attack discussed above by making their private keys unextractable from the cryptographic module. The ability to mark private keys as being unextractable is a typical feature of cryptographic modules. The PKCS #11 cryptographic module API, for example, allows private keys to be made non-extractable by setting the value of their CKA_EXTRACTABLE attribute to CK_FALSE. The forthcoming TEE Functional API, mentioned in the TEE white paper, will no doubt allow private keys stored in a cryptographic module within a TEE to be made non-extractable as well.

Furthermore, derived credentials stored in a cryptographic module within a TEE can be protected against the third malware attack using the Trusted User Interface feature of the TEE. The passcode can be prompted for by the TA that implements the cryptographic module, and the user can be instructed to only enter the passcode when a Security Indicator shows that the touchscreen is controlled by the Secure OS of the TEE. The passcode is then protected against phishing and interception by malware, assuming that all TAs can be trusted and that the secure OS is not infected by malware. The latter assumption is motivated by the fact that the secure OS is simpler than the normal OS and presents a much smaller attack surface.

Virtual Tamper Resistance

Using the same processor and a portion of the same storage for the secure OS as for the normal OS has important benefits. It provides greater performance for the secure OS than would typically achieved by a secondary processor located in a secure element, and it saves the cost of the secure element. On the other hand, it means that a TEE is not expected to provide much, if any, tamper resistance. Indeed, the TEE Secure Element API, available at the GlobalPlatform site, is concerned with using together a TEE and a secure element, with the TEE providing a Trusted User Interface, and the secure element providing tamper resistance.

(BTW, some secure elements do provide serious tamper resistance, but tamper resistance is never absolute. A fascinating description of the elaborate anti-tampering countermeasures in a family of Infineon chips, and how they were defeated by an attacker with no insider knowledge, can be found in an 80-minute video demonstration—broken down into ten eight-minute segments—presented at Black Hat 2010.)

But the lack of tamper resistance in a TEE can be remedied using the same technique that I described in the previous post as a solution to the problem of protecting derived credentials stored in a software token. Encrypting the derived credentials under a high entropy key-wrapping key, kept in a secure back-end and retrieved by authenticating to the back-end with a key pair regenerated from a protocredential and an activation passcode, can be viewed as a form of cloud-based virtual tamper resistance.

Combining such virtual tamper resistance with the TEE Trusted User Interface feature would make it possible to implement a cryptographic module that would protect both the derived credentials and their activation passcode.

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,

NISTIR 7981, Mobile, PIV, and Authentication, and
NIST Special Publication 800-157, Guidelines for Derived Personal Identity Verification (PIV) 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:

Federal agencies would have the flexibility to use any mobile devices they want.
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.
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.

Tag: Cryptography