Cryptography – Page 2

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.

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.

Protocol-Level Details of the TLS 1.3 Visibility Solution

This is the second 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.

TLS 1.3 has created a major problem for enterprise data centers. The new version of the protocol has discontinued the RSA ciphersuites, as well as the static Diffie Hellman (DH) and Elliptic Curve Diffie Hellman (ECDH) ciphersuites, leaving Ephemeral DH (DHE) and Ephemeral ECDH (ECDHE) as the only key exchange primitives based on asymmetric cryptography. These primitives provide forward secrecy, but make it impossible to inspect TLS traffic in the intranet by provisioning a middlebox with a static RSA key, as is done for earlier versions of TLS. Since traffic inspection is necessary for essential tasks such as troubleshooting, attack detection and compliance audits, enterprises cannot migrate to TLS 1.3 without a solution to this problem.

On September 25 NIST held a workshop to discuss the problem. Before the workshop I posted a quick write up on this blog proposing a solution that provides plaintext visibility of the TLS traffic while preserving the forward secrecy provided by TLS 1.3. This post explains the solution in more detail with reference to the specification of TLS 1.3 in RFC 8446, and includes security considerations and performance considerations.

Reconciling Forward Secrecy with Network Traffic Visibility in Enterprise Deployments of TLS 1.3

This is the first 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. I have corrected the post to say that the middlebox and the server must both use an ephemeral key pair for their key exchange.

Update. I said that the TLS server uses a key derivation function to derive a key pair from the secret that it shares with the middlebox. I should have said, more precisely, that it uses the secret to derive bits that are then used to generate a key pair. I’ve corrected this below, and I will write another post to provide more details.

TLS 1.3 has removed the static RSA and static Diffie-Hellman cipher suites, so that all key exchange mechanisms based on public-key cryptography now provide forward secrecy. This is great for security, but creates a problem for enterprise deployments of the TLS protocol.

As explained in the Enterprise Transport Security specification of the European Telecommunications Standards Institute (ETSI), enterprises need to inspect the network traffic inside their data centers for reasons including application health monitoring, troubleshooting, intrusion detection, detection of malware activity, detection of denial-of-service attacks, and compliance audits.

Visibility of plaintext network traffic is usually achieved by means of passive middleboxes that observe the encrypted network traffic and are able to decrypt it. When a middlebox observes a TLS 1.2 key exchange, if the server uses a static RSA or static Diffie-Hellman key pair and the middlebox is provided with a copy of the private key component of the static key pair, the middlebox can compute the session keys in the same manner as the server, and use the session keys to decrypt the subsequent traffic.

The problem is that this method cannot be used with TLS 1.3, and enterprise data centers cannot refuse to upgrade and get stuck at TLS 1.2 forever.

The above mentioned ETSI specification proposes a clever solution. The TLS client and server follow the TLS 1.3 specification, but the server cheats by using a static Diffie-Hellman key pair while pretending to use an ephemeral one, and shares the static private key with the middlebox. This solution works, but fails to achieve the security benefit of forward secrecy.

I would like to propose instead a solution, illustrated in Figure 1, that requires no cheating and achieves both forward secrecy and visibility of the traffic plaintext to the middlebox.

The TLS client and the TLS server fully implement TLS 1.3. When the server and the middlebox see the ClientHello message, they perform a Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) key exchange where each side (server and middlebox) uses an ephemeral key pair whose public key component is signed by the private key component of a long-term signature key pair. The result of this (EC)DH key exchange is an ephemeral secret shared between the TLS server and the middlebox. The TLS server uses that shared secret to derive bits, by means of a key derivation algorithm such as HKDF, that it in turn uses to generate an (EC)DH key pair that it uses in the TLS key exchange. This (EC)DH key pair is ephemeral and provides forward secrecy, because it is derived from the ephemeral shared secret. The middlebox uses the shared secret to derive the same ephemeral (EC)DH key pair in the same manner as the TLS server. Then it uses that shared ephemeral key pair to compute the session keys, and uses the session keys to decrypt the subsequent traffic.

Next post in this series: Protocol-Level Details of the TLS 1.3 Visibility Solution.

Pomcor Granted Patent on How to Implement a PKI on a Blockchain

Pomcor has just been granted US Patent 10,764,067, “Operation of a Certificate Authority on a Distributed Ledger”. A distributed ledger is a database replicated across of set of nodes and populated by transactions issued by the nodes. A distributed consensus algorithm is used to achieve consensus among the nodes on the order of the ledger transactions. A blockchain is a distributed ledger in which ledger transactions are grouped into blocks, and consensus on the ordering of the ledger transactions is based on consensus on the validity and ordering of the blocks.

Some distributed ledgers, e.g. the Ethereum blockchain, provide on-ledger storage by allowing a ledger transaction to contain an instruction to store data in an abstract ledger store identified by a ledger address. As ledger transactions including such instructions are propagated to the nodes of the ledger through the peer-to-peer protocol each node executes the instruction locally, on a local replica of the abstract ledger store that is part of the node’s local replica of the ledger state.

A public key infrastructure is a system for issuing, revoking and validating public key certificates, implemented by a hierarchy of certificate authorities (CAs). The storage replication functionality provided by a distributed ledger with on-ledger storage can greatly simplify the implementation of a PKI.

I do not advocate setting up a blockchain or other distributed ledger just for the purpose of implementing a PKI. But if a distributed ledger has already been set up or is being set up for some other purpose, it can be opportunistically used to implement a PKI, or to simplify the operation of an existing PKI.

I also do not advocate storing or transmitting certificates on the blockchain. That would be a bad idea for privacy reasons, and there is no need to do so. A CA operating on a distributed ledger can issue any kind of certificates, including certificates whose subject is a machine, such as a web server or an IoT device, and certificates whose subject is a person. Each kind of certificate can be stored together with the corresponding private key in any kind of secure storage customarily used for that kind of certificate. In a presentation at ICMC 2017 I explained how JavaScript Web APIs can be used to store personal cryptographic credentials in the browser.

Here is a summary of how a PKI can be implemented on a distributed ledger; details can be found in the patent. A subject requests a certificate as usual by submitting a certificate signing request (CSR). The CA creates a certificate and transmits it to the subject, without ledger involvement in the transmission; there is no need for the subject to have access to the ledger. But the CA also issues an issuance transaction on the ledger with an instruction to store a cryptographic hash of the certificate in a certificate issuance store controlled by the CA; and when the certificate needs to be revoked, it issues a revocation transaction on the ledger with an instruction to store the serial number of the certificate in a certificate revocation store also controlled by the CA. As those transactions propagate throughout the ledger, the instructions are executed by all the nodes in their local replicas of the stores.

This greatly simplifies the process of verifying that a certificate is valid.

Instead of verifying the signature on the certificate, the verifier can just check that the hash of the certificate is present in the certificate issuance store controlled by the CA that has issued the certificate. In fact, the signature can be omitted from the certificate if all verifiers have access to the ledger, substantially reducing the size of the certificate and thus the bandwidth and latency cost of presenting the certificate.

And the verifier can check that the certificate has not been revoked simply by checking that its serial number is not present in the certificate revocation store controlled the CA. This obviates the need for the CA to provide a highly available Online Certificate Status Protocol (OCSP) server and/or a regularly updated Certificate Revocation List (CRL); and for the verifier to query the OCSP server or maintain a local copy of the CRL by periodically retrieving signed updates.