Identity – Page 3

Storing Cryptographic Keys in Persistent Browser Storage

Update (March 5, 2025): This post, and the presentation at ICMC 2017, show how to use a browser as a credential wallet for same-device presentation. Section 12.4 in Chapter 12 of a book I'm writing with Sukhi Chuhan and Veronica Wojnas shows how it can also be used for cross-device presentation, and how a WebView component of a native app can be combined with a native code component to further support proximity presentation over BlueTooth or NFC.

This blog post is a companion to a presentation made at the 2017 International Cryptographic Module Conference and refers to the presentation slides, revised after the conference. Karen Lewison is a co-author of the presentation and of this blog post.

Slide 2: Key storage in web clients

Most Web applications today use TLS, thus relying on cryptography to provide a secure channel between client and server, and to authenticate the server to the client by means of a cryptographic credential, consisting of a TLS server certificate and its associated private key. But other uses of cryptography by Web applications are still rare. Client authentication still relies primarily on traditional username-and-password, one-time passwords, proof of possession of a mobile phone, biometrics, or combinations of two or more of such authentication factors. Web payments still rely on a credit card number being considered a secret. Encrypted messaging is on the rise, but is not Web-based.

A major obstacle to broader use of cryptography by Web applications is the problem of where to store cryptographic keys on the client side. Continue reading "Storing Cryptographic Keys in Persistent Browser Storage"

Comments on the Recommended Use of Biometrics in the New Digital Identity Guidelines, NIST SP 800-63-3

NIST is working on the third revision of SP 800-63, which used to be called the Electronic Authentication Guideline and has now been renamed the Digital Identity Guidelines. An important change in the current draft of the third revision is a much expanded scope for biometrics. The following are comments by Pomcor on that aspect of the new guidelines, and more specifically on Section 5.2.3 of Part B, which we have sent to NIST in response to a call for public comments.

The draft is right in recommending the use of presentation attack detection (PAD). We think it should go farther and make PAD a mandatory requirement right away, without waiting for a future edition as stated in a note.

But the draft only considers PAD performed at the sensor. Continue reading "Comments on the Recommended Use of Biometrics in the New Digital Identity Guidelines, NIST SP 800-63-3"

Using Near-Field Communication for Remote Identity Proofing

This is the last of a four-part series of posts presenting results of a project sponsored by an SBIR Phase I grant from the US Department of Homeland Security. These posts do not necessarily reflect the position or the policy of the US Government.

We have just published a paper presenting the last three of the five solutions that we have identified in the research project on remote identity proofing that we are now finalizing. Solutions 3--5 use Near-Field Communication (NFC) technology for remote identity proofing. Each of the solutions uses a preexisting NFC-enabled hardware token designed for some other purpose as a credential in remote identity proofing. A native app running on an NFC-enabled mobile device serves as a relay between the NFC token and the remote verifier.

In Solution 3 the token is a contactless EMV payment card. In Solution 4, the token is a medical identification smart card containing a private key and a certificate that binds the associated public key to attributes and a facial image. In Solution 5, the token is an e-Passport with an embedded RFID chip that contains signed data comprising biographic data and a facial image.

In solutions 4 and 5 a native app submits to the verifier an audio-visual stream of the subject reading prompted text. The verifier matches the face in the video to the facial image in the NFC token, uses speech recognition technology to verify that the subject is reading the text that was prompted, and verifies that the audio and video channels of the stream are in synchrony by matching distinguishable visemes in the video channel to phonemes in the audio channel.

See also:

The Remote Identity Proofing page, with links to other materials related to the project.

Remote Identity Proofing Discussed at the Internet Identity Workshop

This is Part 3 of a series of posts presenting results of a project sponsored by an SBIR Phase I grant from the US Department of Homeland Security. These posts do not necessarily reflect the position or the policy of the US Government.

To get community feedback on our remote identity proofing project we made a presentation two days ago at the 23rd Internet Identity Workshop in Mountain View. The slides can be found here. We were gratified that the feedback was positive and there were in-depth discussions with identity experts both during and after the presentation.

We started by explaining the goal of the project. Remote identity proofing has often relied on asking the subject multiple-choice “knowledge questions” (e.g. which of the following zip codes did you live in five years ago?). This method is terrible for privacy, since it relies on the identity proofing service gathering and using troves of personal information about people. Furthermore, due to the proliferation of personal data available online, it has now become ineffective. Continue reading "Remote Identity Proofing Discussed at the Internet Identity Workshop"

Implementing a PKI on a Blockchain

This is Part 2 of a series of posts presenting results of a project sponsored by an SBIR Phase I grant from the US Department of Homeland Security. These posts do not necessarily reflect the position or the policy of the US Government.

In the previous post I described the concept of a rich credential, and how a rich credential issued by an identity source can allow a subject to identify him/herself remotely to a verifier with a key pair, a password, and one or more biometric samples such as facial image, even if there is no prior relationship between the subject and the verifier. That was Solution 1, the first of five solutions that we have identified as possible alternatives to knowledge-based verification in the course of our research project on remote identity proofing.

We have now published a paper on Solution 2. In Solution 1 the identity source was a DMV. In Solution 2 the identity source is a bank.

Rich Credentials for Three-Factor Identity Verification without Prior Relationship

This is Part 1 of a series of posts presenting results of a project sponsored by an SBIR Phase I grant from the US Department of Homeland Security. These posts do not necessarily reflect the position or the policy of the US Government.

We have just published a paper on the first of five remote identity proofing solutions, which we have identified as possible alternatives to knowledge-based verification in the course of the research project mentioned in the previous post. The paper describes in detail a new type of credential, which we call a rich credential, that could be issued by an identity source such as a DMV and would enable multifactor identity verification by a remote verifier. In this post I will try to explain the motivations that led us to come up with the concept of a rich credential as the basis of Solution 1.

In-person identity proofing typically relies on the presentation of a picture ID, such as a driver's license or a passport, as the primary evidence of identity, supplemented by secondary evidence from different identity sources, such as proof of ownership of utility, financial or mobile accounts and address verification. Remote presentation of the secondary evidence is not much of a problem, so in the project we have focused on replacing the picture ID with other kinds of primary evidence that can be presented remotely.

Faster Modular Exponentiation in JavaScript

Modular exponentiation is the algorithm whose performance determines the performance and practicality of many public key cryptosystems, including RSA, DH and DSA. We have recently achieved a manyfold improvement in the performance of modular exponentiation in JavaScript over the implementation of modular exponentiation in the Stanford JavaScript Crypto Library (SJCL). JavaScript was originally intended for performing simple tasks in web pages, but it has grown into a sophisticated general purpose programming language used for both client and server computing, which is arguably the most important programming language today. Good performance of public key cryptography is difficult to achieve in JavaScript, because JavaScript is an interpreted language inherently slower than a compiled language such as C, and provides floating point arithmetic but no integer arithmetic. But fast JavaScript public key cryptography is worth the effort, because it may radically change the way cryptography is used in web applications. Continue reading "Faster Modular Exponentiation in JavaScript"

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"