Blog – Page 3

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.

Request for Comments: A Possible-Worlds Semantics for Kolmogorov’s Axiomatization of Probability Theory

Probability theory is being very successfully used in a growing number of fields of science and engineering. It is essential to several areas of computer science that I am interested in, including areas critical to cybersecurity and privacy such as cryptogaphy, biometrics, artificial intelligence and human-computer interaction.

The success of probability theory has been made possible by the elegant formalization that was provided by Kolmogorov in his 1933 treatise, which is universally accepted by practitioners as the foundation of modern probability theory.

Curiously, however, in spite of the practical success of probability theory and the universal acceptance of Kolmogorov’s formalization as its foundation, the meaning of the concept of probability has been an open question in philosophy for three centuries, and still is today, as can be seen in this entry of the Stanford Encyclopedia of Philosophy. To try to understand why this is so, I’ve looked at the interpretation of his own formalization that Kolmogorov provides in his treatise.

It turns out that Kolmogorov’s interpretation is inconsistent with his formalization. Later authors, while keeping the formalization, have moved away from the interpretation, but without providing a satisfactory alternative. In this paper I propose an interpretation where the elements of the set that Kolmogorov called E and is now called Ω are possible worlds, in the simplest sense of the term, without complications such as Kripke’s frames necessitated by modal logic. I also propose an intensional definition of the notion of event as a condition on the values of one or more random variables, the less intuitive traditional definition as a subset of Ω being then more easily understood as the extensional counterpart of the intensional definition.

Comments on the paper would be very welcome.

Airport Security in the Age of COVID-19

As the travel restrictions imposed to control the coronavirus pandemic are beginning to be relaxed in some parts of the world, it is time to start rethinking airport security in the age of COVID-19. Even if an effective vaccine is found for COVID-19, it will be out of the question to go back to long lines at security checkpoints and boarding gates, and the manual checking of identity documents and boarding passes.

In a provisional patent application that I coauthored with Karen Lewison before the pandemic and have now published, we proposed an automated method of verifying the identity of travelers that could be used in the post-pandemic world to speed up the security check and the boarding process, and to eliminate the face-to-face interaction with a security officer at the checkpoint and a flight attendant at the boarding gate. The method takes advantage of the high accuracy achieved by today’s deep neural networks for face recognition, while overcoming the privacy concerns raised by the collection and storage of facial images.

Here is a summary of the method.

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.

Identity Verification: A Coronavirus Challenge to the Financial World

Updated April 1st, 2020

This blog post has been coauthored with Karen Lewison

The coronavirus pandemic is causing unprecedented disruption throughout the business world. Businesses that are not able to cope with public health orders and new customer behaviors are going out of business, while businesses that are able to adapt are thriving and expanding their market share. Disruption will be temporary in sectors of the economy where face-to-face interaction adds value to the business-to-customer relationship and a physical presence on the street is an essential requirement of the business model; gyms, bars and conference centers will no doubt reopen once the pandemic has been controlled. But changes brought by the pandemic will be permanent in sectors of the economy where face-to-face interaction adds no value and a physical presence is a legacy of a traditional business model. One of those sectors is the financial world.

A challenge to financial institutions

Financial institutions have been less impacted than other businesses by the pandemic. In the US, the entire financial sector has been declared critical infrastructure by DHS and is thus protected against closure orders by states or counties. And most financial transactions are now conducted online using web browsers or mobile apps, without face-to-face interactions that would put employees and customers at risk of contagion. Nevertheless, coronavirus poses a challenge to financial institutions: how to verify the identity of new customers.

Pomcor Granted Patent on Rich Credentials

Pomcor has been granted US Patent 10,567,377, Multifactor Privacy-Enhanced Remote Identification Using a Rich Credential. Karen Lewison is the lead inventor and I am a coinventor. Pomcor has so far been granted a total of eight patents, two of which we have sold. The remaining six patents that we own are listed in the Patents page of this web site.

This latest patent is special because it provides a solution to a major societal problem: how to identify people over the Internet with strong security. Techniques are available for authenticating repeat visitors to a web site or current users of a web application. But authentication techniques are only applicable once a relationship has been established. They are not applicable when somebody wants to establish a new relationship, e.g. by becoming a new customer of a bank, or signing up with a robo advisor, or applying for a mortgage, or renting an apartment, or switching to a different car insurance.

A New Tool Against the Surge of Application Fraud

This blog post has been coauthored with Karen Lewison

In recent posts we have been concerned with online credit card fraud and how to fight it using cardholder authentication. In this post we are concerned with another kind of financial fraud, known as application fraud or new account fraud. Both kinds of fraud have been rising after the introduction of chip cards, for reasons mentioned by Elizabeth Lasher in her article The Surge of Application Fraud:

“Due to the high volume of data breaches, Social Security numbers, mailing addresses, passwords, health history, even the name of our first pet is all for sale on the Dark Web. When you combine this phenomenon with the economic pressure applied on fraudsters to find a new cash cow after chip and signature plugged a gap in card-present fraud in the US, there is a perfect storm.”

The term “application fraud” refers to the creation of a financial account, such as a bank account or a mortgage account, with the intention to commit fraud. Application fraud can be first-party fraud, where the account is opened under the fraudster’s own identity, or third-party fraud, where the fraudster uses a stolen identity. Here we are primarily concerned with the latter.

PSD2 Is In Trouble: Will It Survive?

This blog post has been coauthored with Karen Lewison

The 2nd Payment Services Directive (PSD2) of the European Union went into effect on September 14, but one of its most prominent provisions, the Strong Customer Authentication (SCA) requirement, was postponed until December 31, 2020 by an opinion dated 16 October 2019 of the European Banking Authority (EBA). The EBA cited pushback from the National Competent Authorities (NCAs) of the EU member countries as the reason for the postponement, and the fact that version 2 of the 3-D Secure protocol (3-D Secure 2) is not ready as a reason for the pushback.

PSD2 is supposed to be technology neutral, but the EBA has unequivocally endorsed 3-D Secure as the way to implement the SCA requirement for online credit card transactions, as stated in another opinion, dated 21 June 2019:

Will Cardholder Authentication Ever Come to the US?

This blog post has been coauthored with Karen Lewison

You may have heard that the EU is struggling to implement the Strong Customer Authentication (SCA) requirements of Payment Services Directive 2 (PSD2). The directive was issued four years ago, Regulatory Technical Standards (RTS) followed two years later, and the SCA requirements went into effect on September 14. But on October 16 the European Banking Authority (EBA) had to postpone enforcement until December 31, 2020, due to pushback from the National Competent Authorities (NCAs) of the EU member countries. In an opinion announcing the postponement, the EBA cited as a reason for the pushback the fact that 3-D Secure 2 (3DS2) is not ready.

The problems that the EBA is having with the SCA requirements have more to do with the bureaucratic formulation of the requirements in PSD2, than with the technical difficulty of providing strong security. We will discuss this in another post, but first we want to ask here whether cardholder authentication will ever come to the US.