Blog – Page 2

Passwordless Authentication for the Consumer Space

This is part 1 of a series on cryptographic authentication. Part 2 and Part 3 are now available.

FIDO adoption lags in spite of general availability

In a white paper issued in March 2022 the FIDO Alliance candidly announced that FIDO-based authentication based on the FIDO2 standards, which include the Client-To-Authenticator Protocol of the FIDO Alliance and the companion Web Authentication API (WebAuthn) of the W3C “has not attained large-scale adoption in the consumer space”.

FIDO2 is a cryptographic authentication solution for the web, which uses a key pair managed by an authenticator and is advertised by the FIDO Alliance as being “passwordless”. The key pair may be stored in the authenticator, or, equivalently from a security viewpoint, it may be encrypted under a symmetric key stored in the authenticator, and exported to play the role of a “credential ID”. The authenticator may be a “roaming authenticator” carried in a “security key”, or a “platform authenticator” provided by the OS of the user’s smartphone or laptop.

Early authenticators were security keys, which few web users had. Today most smartphones and laptops have platform authenticators, and that makes FIDO2 a generally available web technology. But the announcement by the FIDO Alliance shows that general availability has not translated into general adoption.

The white paper attributes this to challenges that consumers face with platform authenticators: “having to re-enroll each new device”, and having “no easy ways to recover from a lost or stolen device” as the credentials managed by the platform authenticator of the device are lost. To address the loss-of-credential problem, Apple, Google and Microsoft have announced a joint effort to devise solutions that are expected to become available “in the course of the coming year” and that, according to the white paper, will involve “multi-device credentials”.

Another contributing factor to the lack of adoption, however, is no doubt the complexity and cost of the FIDO2 authentication solution. Implementing the solution in a web app requires FIDO Server software provided by a company certified to provide such software by the FIDO Alliance. A team from the certified company must work with a team from the company that is developing the app to integrate the solution into the app. By contrast, an ordinary 2FA solution is implemented by the app developers themselves, possibly by a single developer, without any integration effort.

Thus FIDO faces two obstacles to widespread adoption: usability and cost.

Two working demonstrations of cryptographic authentication on GitHub

But cryptographic authentication need not be complicated, costly or challenging to the consumer. It can be implemented simply by storing a key pair in persistent browser storage (localStorage or IndexDB), registering the public key, and authenticating by proof of possession of the private key. I will refer to this as the browser storage solution to cryptographic authentication while referring to the use of a FIDO authenticator as the FIDO solution, or the authenticator storage solution, glossing over the fact that the private key may be exported under encryption rather than physically kept in the authenticator.

The browser storage solution can easily overcome the two obstacles that FIDO faces in the consumer space. To demonstrate this I have published on GitHub two demo web apps that implement passwordless, phishing-resistant cryptographic authentication with a key pair credential, without relying on an authenticator. In both of them the key pair is generated in the browser by the JavaScript frontend of the app, and kept in the localStorage facility provided by the Web Storage API. One of them uses a “nosql” (MongoDB) backend database to register the public key and store the user data, while the other uses an “sql” database for that purpose.

Pomcor Releases PJCL 1.0.0 on GitHub and npm and Deprecates the Beta Versions of the Pomcor JavaScript Cryptographic Library

In 2018 we published a series of beta versions of the Pomcor JavaScript Cryptographic Library (PJCL), which we called 0.9.0, 0.9.0r1, 0.9.1, 0.9.1r1 and 0.9.1r2. (We shall use semantic versioning to name future versions.) We then had to put the PJCL work on hold, but have now been able to resume development. We have refactored the library as an ES6 module and released version 1.0.0 on GitHub at https://github.com/fcorella/pjcl.git, and on npm.

While testing the refactored version 1.0.0 we found two bugs that we tracked back to version 0.9.1r2. Specifically, we found a bug in function pjclPBKDF2_SHA256 and a bug in function pjclFFCValidateG_256, which caused the JavaScript interpreter to throw exceptions. We fixed the bugs in a maintenance release 0.9.1r3, but we have now archived and deprecated the beta versions and will no longer be maintaining them.

If you want to stay informed about PJCL in the future, please subscribe to GitHub notifications about the pjcl repository.

Identity in a Zero Trust Architecture

In the previous post I said I was happy that the new CFO of Pomcor, Ken Cone, has experience with government contracting, as his experience may help us apply for and manage government funding for our reasearch on identity and authentication protocols. Identity is an essential element of cybersecurity, and Executive Order 14028 has recognized that cybersecurity is an essential element of national and economic security.

Here I want to add that identity is essential, more specifically, in modern “zero trust” cybersecurity architectures whose importance is recognized by the Federal Government. The White House has stated in the OMB memorandum M-22-09 that a zero trust approach to security is needed today to provide a “defensible architecture” in the current threat environment. The Department of Defense (DoD) has published a Zero Trust Reference Architecture, and M-22-09 directs Federal Agencies to move towards zero trust cybersecurity principles.

This has implications for identity. As stated in the Reference Architecture and cited in M-22-09, “The foundational tenet of the Zero Trust Model is that no actor, system, network, or service operating outside or within the security perimeter is trusted. Instead, we must verify anything and everything attempting to establish access.” This means that secure identification is an essential requirement of zero trust architecture.

To meet this requirement, M-22-09 calls for multi-factor authentication (MFA); not the usual MFA, however, but rather what the memorandum calls “phishing-resistant MFA”, where phishing resistance is achieved by using a secret that is not shared with the relying party. That means a private key.

Thus the memorandum is calling for cryptographic authentication, which is what Pomcor has been working on for years, and is working on right now. I look forward to Pomcor contributing to the transition towards zero trust in the Federal Government and to the adoption by the Government and the Private Sector of cryptographic authentication methods that provide strong security.

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.

Pomcor Granted Patent on Frictionless Cardholder Authentication

This post has been updated to include the patent number.

Pomcor has been granted US patent 10,825,025 on the method of cardholder authentication that I have discussed before on this blog. The Cardholder Authentication page has links to earlier materials. Actually, the patent was granted on November 3, 2020, but I was busy working on TLS traffic visibility at the time.

3-D Secure 2 purports to reduce the friction created by 3-D Secure 1 as it redirects the cardholder browser to the card issuer’s site for authentication. But it does so by omitting cardholder authentication altogether for transactions deemed low risk, and may increase friction for other transactions.

Eliminating friction with a Service Worker

We eliminate friction instead, for all transactions, by using a Service Worker registered with the browser by the issuer to intercept the redirected request and authenticate the user by proof of possession of a private key, which is used to sign a description of the transaction and thus provide a defense against transaction repudiation to the merchant.

The private key is associated with a credit card certificate that contains the corresponding public key and a cryptographic hash of the data printed on the credit card. The card data is not included in the certificate to avoid exposing it to an attacker who uses malware or physical capture of the cardholder’s device to obtain the certificate. When the merchant’s site or native app receives the certificate along with signature, it verifies the hash against the printed card data entered by the cardholder.

We originally used the idea of intercepting an authentication request with a Service Worker in connection with Rich Credentials, then presented it in general terms at ICMC 2017.

Are Service Workers still usable?

People have been telling us recently that Service Workers can no longer be used because WebKit deletes Service Worker registrations, along with first-party data stored in the browser, after seven days of non-use. This is an unfortunate complication, but it does not mean that Service Workers and first-party data can no longer be used. It just means that the web app that registers the Service Worker, in this case the issuer’s web app, must be added to the home screen, as explained in this WebKit blog post.

The 0-RTT Feature of TLS 1.3 Can Be Used As an Encrypted Steganographic Channel to Operate a Backdoor into an Enterprise Network

The TLS 1.3 specification in RFC 8446 allows the client to send application data to the server immediately after the ClientHello message, with zero round-trip time, and refers to that data as 0-RTT data or early data.

A server that receives early data may accept it or reject it. Rejected data is ignored by the server but seen by all routers, switches, firewalls and other network appliances in the network path from the client to the server. Therefore an attacker-controlled client can use rejected early data as a steganographic channel to communicate with any compromised network appliance situated in the network path. Furthermore neither the server, nor any of the TLS visibility solutions that are currently in the market among those that I surveyed in an earlier post, attempt to decrypt rejected early data. Hence the attacker-controlled client can encrypt the channel using a key unknown to the server but shared with the compromised appliance without risking detection.

An attacker who has implanted persistent malware on an enterprise network appliance can therefore use rejected early data as an encrypted steganographic channel to send command-and-control (C2) instructions from an external client to the implant in the compromised appliance and thus operate a backdoor into the enterprise network.

In this post I go over some of the details of the 0-RTT feature of TLS 1.3, describe several methods that an attacker-controlled client can use to cause rejection of early data by the server, sketch out an attack scenario and propose mitigations.

Nubeva Explains How It handles TLS 1.3 Key Updates in Response to Pomcor Blog Post

In the last post of the TLS traffic visibility series, before a survey of solutions, I drew attention to how in TLS 1.3 different kinds of traffic are protected under different keys and sometimes with different ciphers, and how client and server can update their application traffic keys at any time. I referred to this as the multiple protection state problem of TLS 1.3.

This problem means that PFS visibility solutions where a single symmetric session key per direction of traffic is sent to a passive visibility middlebox will not work for TLS 1.3 even if they work for TLS 1.2. I mentioned two such solutions in the previous post, one of them being Nubeva’s Symmetric Key Intercept (SKI), described in a presentation at a NIST workshop.

In response to the blog post, Nubeva has sent me a detailed explanation of how their SKI solution handles the multiplicity of symmetric keys in TLS 1.3. It turns out that, although the solution is called Symmetric Key Intercept and the workshop presentation referred to the extraction of symmetric keys from system memory, it is not the symmetric keys that are extracted and sent to a decryptor, but rather the TLS 1.3 traffic secrets, from which the symmetric keys are derived by the decryptor as described in Nubeva’s response.

A Survey of Existing and Proposed TLS Visibility Solutions

This is the fifth and last post of a series on providing visibility of TLS 1.3 traffic in the intranet. An index to the series and related materials can be found in the TLS Traffic Visibility page.

Update. This post has been updated in response to a clarification received from Nubeva. See the section on SKI below and the next blog post.

It is well known that TLS 1.3 has created a visibility problem for encrypted intranet traffic by removing the static RSA key exchange method. Except in PSK-only mode, TLS 1.3 traffic has forward secrecy protection and cannot be decrypted by a passive middlebox provisioned with a static private key. This is known as the PFS visibility problem, where PFS stands for “perfect” forward secrecy.

But there is no awareness yet of a second problem created by TLS 1.3 that makes it harder to solve the PFS visibility problem than is generally understood. I call it the multiple protection state problem.

TLS 1.2 has PFS cipher suites, and therefore it has its own PFS visibility problem. If a client insists on using a PFS cipher suite, a passive middlebox provisioned with a static private key won’t be able to decrypt the traffic. Some existing TLS visibility solutions provide the middlebox with the symmetric keys used to protect the traffic, rather than with the private key used to perform the key exchange. Such solutions are being successfully deployed for decrypting TLS 1.2 traffic. But the multiple protection state problem means that those solutions are not applicable to TLS 1.3.

I realized this as I was working on a survey of TLS visibility solutions. The problem is described in the next section and the survey can be found in the following section.

A Two-Version Visibility Solution for TLS 1.2 and TLS 1.3 based on a Handshake-Agnostic Middlebox

This is the fourth post of a series on providing visibility of TLS 1.3 traffic in the intranet. An index to the series and related materials can be found in the TLS Traffic Visibility page.

In earlier posts I have proposed a solution for the intranet visibility problem of TLS 1.3 based on the establishment of a visibility shared secret (VSS) between the TLS server and a visibility middlebox, using a long term TCP connection on the same or a different wire than the TLS connection. The visibility middlebox does not relay the TLS traffic: it uses port mirroring to observe the traffic, decrypts it (or, using TLS 1.3 terminology, deprotects it), and forwards the plaintext to a monitoring facility. The solution has a secret derivation (SD) variant where the middlebox derives the TLS 1.3 traffic secrets on its own, and a secret transmission (ST) variant where the server sends the traffic secrets to the middlebox encrypted under keys derived from VSS.

But a server that upgrades to TLS 1.3 must continue to support clients that use earlier versions of TLS. TLS 1.0 and TLS 1.1 have been deprecated, but TLS 1.2 may remain in use for many years. In this post I introduce a third variant that provides visibility for TLS 1.2 in addition to TLS 1.3. This two-version (2V) variant uses a handshake-agnostic visibility middlebox to handle all the key exchange modes of both versions of TLS, and preserves forward secrecy for those modes that provide it. At the end of this post I also describe a VSS precomputation feature, usable in all three variants, that I have mentioned in earlier posts but not discussed in detail yet.

Extending the TLS 1.3 Visibility Solution to Include PSK and 0-RTT

This is the third post of a series on providing visibility of TLS 1.3 traffic in the intranet. An index to the series and related materials can be found in the TLS Traffic Visibility page.

Update. This post has been updated to say that, in the ST variant, the messages that convey the traffic secrets also convey the two-byte designation of the cipher suite that specifies the AEAD algorithm to be used with the keys derived from the secrets, and that the messages include the connection ID of the client-server connection as the AEAD associated data. The middlebox needs to be told what algorithm to use to decrypt early data if the early data is rejected by the server.

TLS 1.3 has created a problem for enterprises by discontinuing all key exchange methods that use static key pairs. In the first post of this series I described a solution to this problem that preserves forward secrecy, based on the establishment of an ephemeral shared secret between the TLS server and a visibility middlebox. In the second post I provided full details of the solution for the (EC)DHE-only key exchange mode of TLS 1.3. In this post I show how the solution can be extended to handle the PSK-only and PSK + (EC)DHE key exchange modes and the 0-RTT feature of TLS 1.3 by providing the PSK to the middlebox. In this post I also introduce a variant of the solution that handles the PSK modes without the middlebox having to know the PSK and provides different benefits. Both variants can be used in all three key exchange modes of TLS 1.3.