Uncategorized – Pomcor

A Definition of Special Soundness Better Suited for Anonymous Credentials

December 1, 2024: updated to make corrections as shown. The proposed alternative definition of special soundness has not been changed, but its wording has been clarified.

I am co-authoring a book on the Foundations of Cryptographic Authentication with Sukhi Chuhan and Veronica Wojnas, where Chapter 3 is concerned with traditional credentials (as opposed to verifiable credentials or the mDL). Section 3.5 has an extensive treatment of zero knowledge, and in section 3.5.6 we use BBS signatures as an example of anonymous credentials. The chapter is still work in progress: the definition of special soundness proposed here is discussed in Section 3.5.6 but has not been retrofitted yet into sections 3.5.1-5.

As we were studying in detail the BBS paper we saw that the Sigma protocol defined in the paper for proving knowledge of a BBS signature is not special sound, contrary to what the paper claims. Then we thought of a modification to the definition of special soundness, proposed here, that would make it special sound. The proposed definition is more widely applicable than the current one, while still implying proof of knowledge.

A Streamlined Process for Licensing a Cryptographic Authentication Patent

THE STREAMLINED PROCESS IS NO LONGER AVAILABLE. PLEASE WRITE TO US THROUGH THE CONTACT PAGE IF YOU WOULD LIKE TO LICENSE THE PATENT

Two-factor authentication with a fusion credential, demonstrated in this GitHub repository, overcomes the UX obstacles that are impeding large scale adoption of cryptographic authentication, by making it possible to add protection against man-in-the-middle phishing attacks, password reuse and backend breaches to a site where users authenticate with email and password, while keeping the same user experience, including the ability to log in on any browser, in any device.

But two-factor credential fusion makes use of an invention protected by a patent, and cryptography-related patents have historically delayed adoption of new technologies. To overcome this additional obstacle to the adoption of cryptographic authentication, I have now introduced a streamlined process for licensing the patent, which may be of independent interest.

The process uses a "DocuSign envelope", which is a type of workflow document that DocuSign routes by email to participants in a business process. The document is first routed to the patent holder, who applies a "DocuSign eSignature" to a license offer. It is then routed to the client, who adds a "DocuSign eSignature" accepting the offer and pays the license fee. It is finally routed back to the patent holder, who adds a "DocuSign eSignature" granting the license, after receiving the license fee. The completed document with all three eSignatures is sent by email to the parties, and kept by DocuSign in its own storage where it is available as evidence that the license has been granted.

Details of the process and examples of completed documents are available here.

Ken Cone joins Pomcor as CFO

I'm happy to announce that Ken Cone has agreed to join Pomcor as CFO.

Ken is a highly experienced CPA and financial adviser who has provided business and tax advice in a variety of industries. He knows Pomcor well, having provided us with accounting expertise and tax preparation services for several years. I view his joining Pomcor as an executive as a vote of confidence in the future of the company, which I appreciate.

Experience with government contracting in the defense industry

It also makes me happy that Ken is familiar with government contracting, and more specifically, government contracting in the defense industry. Most of our research over the last decade, and research that we are conducting right now, is concerned with identity and authentication protocols. Identity is an essential element of cybersecurity, which in the current threat environment cybersecurity is an essential element of national and economic security, as recognized in the President's Executive Order 14028. We have received government funding for our research in the past, and we may apply for funding in the future to continue our research on identity. Ken's expertise and experience with government contracting will help us apply for and manage such funding.

IN LOVING MEMORY OF KAREN LEWISON

Photo of Karen Lewison Karen Lewison, CEO of Pomcor, has passed away after fighting cancer for almost two years. Karen and I used different names, but we were married and I loved her deeply.

Karen was a physician, but after co-founding Pomcor, and later taking over as CEO, she pivoted into hi tech. She managed government grants, conducted research, wrote code, and was a coinventor of several US patents granted to Pomcor. In particular, she was the lead inventor of the recently granted US patent 10,576,377, which introduces the concept of rich credentials. She was also the lead inventor of a patent application that discloses a method of operating a certificate authority on a blockchain or distributed ledger. The very same day that she passed away a USPTO examiner called and “allowed” that application, which means that a patent will be granted on the application in due course. I was able to communicate the news to Karen.

Karen's cancer was diagnosed at a very late stage of the disease, where patients are expected to give up. Instead she chose to fight, and won several battles against complications of the disease, achieving spectacular recoveries after being on the brink of death. Throughout her fierce war against cancer she remained engaged in our research. We filed joint patent applications on several new inventions and coauthored a paper and several blog posts.

I plan to continue on my own the work that Karen and I were doing together, in honor of her memory and inspired by her courage. Pomcor will go on.

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"

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.

Category: Uncategorized