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”
Last July, the
National Security Agency (NSA)
issued CNSS Advisory Memorandum 02-15, available at the
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
National Security Algorithm Suite (CNSA Suite), which replaces
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
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”
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.
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
We have written a
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
We have written a response to the
Comments on the report
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.