Storing Cryptographic Keys in Persistent Browser Storage

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”

NSA’s FAQs Demystify the Demise of Suite B, but Fail to Explain One Important Detail

Last July, the National Security Agency (NSA) issued CNSS Advisory Memorandum 02-15, available at the Advisory Memoranda page, updating the list of cryptographic algorithms that can be used in National Security Systems (NSS). A subsequent document referred to the new algorithms as the Commercial National Security Algorithm Suite (CNSA Suite), which replaces Suite B. The transition to the CNSA Suite took place two months before a Suite B deadline to discontinue the use of RSA, DH and DSA and rely exclusively on ECC algorithms for public key cryptosystems. The subsequent document explained the motivation for the transition by saying that “the growth of elliptic curve use has bumped up against the fact of continued progress in the research on quantum computing, which has made it clear that elliptic curve cryptography is not the long term solution many once hoped it would be,” and announced “preliminary plans” for a future transition to quantum-resistant algorithms.

This abrupt change of course, following many years of promoting ECC, took the cryptographic community by surprise. Continue reading “NSA’s FAQs Demystify the Demise of Suite B, but Fail to Explain One Important Detail”

It’s Time to Redesign Transport Layer Security

One difficulty faced by privacy-enhancing credentials (such as U-Prove tokens, Idemix anonymous credentials, or credentials based on group signatures), is the fact that they are not supported by TLS. We noticed this when we looked at privacy-enhancing credentials in the context of NSTIC, and we proposed an architecture for the NSTIC ecosystem that included an extension of TLS to accommodate them.

Several other things are wrong with TLS. Performance is poor over satellite links due to the additional roundtrips and the transmission of certificate chains during the handshake. Client and attribute certificates, when used, are sent in the clear. And there has been a long list of TLS vulnerabilities, some of which have not been addressed, while others are addressed in TLS versions and extensions that are not broadly deployed.

The November SSL Pulse reported that only 18.2% of surveyed web sites supported TLS 1.1, which dates back to April 2006, only 20.7% supported TLS 1.2, which dates back to August 2008, and only 30.6% had server-side protection against the BEAST attack, which requires either TLS 1.1 or TLS 1.2. This indicates upgrade fatigue, which may be due to the age of the protocol and the large number of versions and extensions that it has accumulated during its long life. Changing the configuration of a TLS implementation to protect against vulnerabilities without shutting out a large portion of the user base is a complex task that IT personnel is no doubt loath to tackle.

So perhaps it is time to restart from scratch, designing a new transport layer security protocol — actually, two of them, one for connections and the other for datagrams — that will incorporate the lessons learned from TLS — and DTLS — while discarding the heavy baggage of old code and backward compatibility requirements.

We have written a new white paper that recapitulates the drawbacks of TLS and discusses ingredients for a possible replacement.

The paper emphasizes the benefits of redesigning transport layer security for the military, because the military in particular should be very much interested in better transport layer security protocols. The military should be interested in better performance over satellite and radio links, for obvious reasons. It should be interested in increased security, because so much is at stake in the security of military networks. And I would argue that it should also be interested in increased privacy, because what is viewed as privacy on the Internet may be viewed as resistance to traffic analysis in military networks.

Pomcor’s Comments on the Cybersecurity Green Paper

We have written a response to the Call for Comments on the report entitled Cybersecurity, Innovations and the Internet Economy, written by the Internet Policy Task Force of the US Department of Commerce.

In the response we call for research and development efforts aimed at improving and broadening the scope of the TLS protocol (formerly known as SSL). This would benefit NSTIC and the many IETF protocols that rely on TLS for their security.

If you have any comments on our response, please leave then below.