More Efficient Post-quantum KEMTLS with Pre-distributed Public Keys

Abstract

While server-only authentication with certificates is the most widely used mode of operation for the Transport Layer Security (TLS) protocol on the world wide web, there are many applications where TLS is used in a different way or with different constraints. For example, embedded Internet-of-Things clients may have a server certificate pre-programmed and be highly constrained in terms of communication bandwidth or computation power. As post-quantum algorithms have a wider range of performance trade-offs, designs other than traditional “signed-key-exchange” may be worthwhile. The KEMTLS protocol, presented at ACM CCS 2020, uses key encapsulation mechanisms (KEMs) rather than signatures for authentication in the TLS 1.3 handshake, a benefit since most post-quantum KEMs are more efficient than PQ signatures. However, KEMTLS has some drawbacks, especially in the client authentication scenario which requires a full additional roundtrip.

We explore how the situation changes with pre-distributed public keys, which may be viable in many scenarios, for example pre-installed public keys in apps, on embedded devices, cached public keys, or keys distributed out of band. Our variant of KEMTLS with pre-distributed keys, called $\mathsf{KEMTLS\text {-}PDK}$, is more efficient in terms of both bandwidth and computation compared to post-quantum signed-KEM TLS (even cached public keys), and has a smaller trusted code base. When client authentication is used, $\mathsf{KEMTLS\text {-}PDK}$ is more bandwidth efficient than KEMTLS yet can complete client authentication in one fewer round trips, and has stronger authentication properties. Interestingly, using pre-distributed keys in $\mathsf{KEMTLS\text {-}PDK}$ changes the landscape on suitability of PQ algorithms: schemes where public keys are larger than ciphertexts/signatures (such as Classic McEliece and Rainbow) can be viable, and the differences between some lattice-based schemes is reduced. We also discuss how using pre-distributed public keys provides privacy benefits compared to pre-shared symmetric keys in TLS.

A KEMTLS

Figure 4 presents KEMTLS  [43] side-by-side with TLS 1.3. Establishing an ephemeral shared secret happens in a similar way in TLS 1.3 and KEMTLS. The client submits a public key $g^x$ (TLS 1.3) or $\mathsf {pk}_e$ (KEMTLS) to the server in the $\mathtt{ClientHello}$ message. The server then replies with its key share $g^y$ (TLS 1.3) or ciphertext $\mathsf {ct}_e$ (KEMTLS). At this point, the server has the information to derive the handshake shared secret. This shared secret $\mathsf {ss}_e$ is used to encrypt the server’s certificate before transmitting it to the client.

In TLS 1.3, this certificate contains a long-term public key for a digital signature algorithm $\mathsf {pk}_S$. The server signs the transcript of all the transmitted messages so far and submits this signature in the $\mathtt{ServerCertificateVerify}$ message. This allows the client to immediately verify the server’s identity: the signature proves the server posesses the private key corresponding to the certificate. The server then finishes the handshake by sending the key confirmation message. The client replies with its own key confirmation message.

When using long-term public keys for KEMs in certificates, signing the transcript is not possible. So, in KEMTLS, the client encapsulates a new shared secret $\mathsf {ss}_S$ to the server’s long-term public key $\mathsf {pk}_S$. It then sends over the corresponding ciphertext $\mathsf {ct}_S$ to the server. Only if the server can decapsulate the shared secret from the ciphertext, can it prove posession of the private key corresponding to the certificate. The server mixes in the new shared secret with the ephemeral secret key and derives new handshake keys. The server’s key confirmation message then proves possesion of the long-term key.

Fig. 4.

Overview of TLS 1.3 and KEMTLS

If the client were to wait for the server to prove that it has decapsulated the ciphertext, KEMTLS would need a full extra round-trip over TLS 1.3. However, before the confirmation message, the client already knows that only the intended server would be able to read any data that is encrypted with keys derived from $\mathsf {ss}_S$. KEMTLS uses this to allow the client to send data to the implicitly authenticated server before it has received the server’s key confirmation message. Once the key confirmation is received, the server is explicitly authenticated and the client then knows the server is present.