Analyzing and Fixing the QACCE Security of QUIC

Abstract

QUIC is a secure transport protocol developed by Google. Lychev et al. proposed a security model (QACCE model) to capture the security of QUIC. However, the QACCE model is very complicated, and it is not clear if security requirements for QUIC are appropriately defined. In this paper, we show the first formal analysis result of QUIC using automated security verification tool ProVerif. Our symbolic model formalizes the QACCE model and the specification of QUIC. As the result of the verification, we find three attacks against QUIC in the QACCE model. It means that the Lychev et al.’s security proofs are not correct. We discuss why such attacks occur, and clarify there are unnecessarily strong points in the QACCE model. Finally, we give a way to improve the QACCE model to exactly address the appropriate security requirements.

Appendices

A Protocol Flow of QUIC

The 1-RTT protocol of QUIC is shown in Table 1. The 0-RTT protocol simply omits $m_1$ and $m_2$ from the 1-RTT protocol and renumber the sequence number, which starts from 1.

Table 1. The 1-RTT connection establishment

The client has following information.

• $pk_S$: a verification key of a server which is obtained from PKI

• $\tau _t$: current time period

The server has following information.

• $pk_S$: a verification key

• $sk_S$: a signing key corresponding with $pk_S$

• $k_{\mathtt {stk}}$: a server secret key where $k_{\mathtt {stk}} \leftarrow _R \{ 0,1 \}^{128}$

• $Y' = g^{y'}$ where $y' \leftarrow _R \# \langle g\rangle$ (ServerConfiguration for 0-RTT)

• $\tau _t$: current time period

• $\mathtt {scfg}^t$: a part of global state of server in the time period $\tau _t$

• $\mathtt {stk}$: source-address token $\mathtt {stk}$

• xtrct_xpnd: key derivation function for QUIC

• $\mathtt {strike}$: set of used nonce

• $\mathtt {strike}_{rng}$: arrowed time period

• pak: packet generate function for QUIC

• process_packets: packet process function for QUIC

We assume that the server’s $\mathtt {scfg}$ is refreshed every time period $\tau _t$ using the scfg$\_$gen function as follows.

$\underline{scfg\_gen(sk, \tau _t, \lambda )}$:

$q \leftarrow _R \{\text {primes~of~size } \lambda \},$ $g \leftarrow _R \{\text {generators~of } \mathbb {Z}_q \},$ $x_s \leftarrow _R \mathbb {Z}_{q-1},$ $y_s \leftarrow g^{x_s},$ $\mathtt {pub}_s \leftarrow (g, q, y_s),$ $\mathtt {sec}_s \leftarrow x_s,$ $\mathtt {expy}\leftarrow \tau _{t+1},$ $\mathtt {scid}\leftarrow \mathcal {H} (\mathtt {pub}_s, \mathtt {expy}),$ $\mathtt {str}\leftarrow$ “QUIC server config signature”, $\mathtt {scfg}^t_{\mathtt {pub}} \leftarrow (\mathtt {scid}, \mathtt {pub}_s,$ $\mathtt {expy}, \mathtt {prof}),$ $\mathtt {scfg}\leftarrow (\mathtt {scfg}^t_{\mathtt {pub}}, \mathtt {sec}_s).$

B Formalization of Cryptographic Primitives

The cryptographic primitives used in QUIC are authenticated encryption with associated data (AEAD), Diffie-Hellman key agreement, digital signatures, the hash function ($\mathcal {H}$), and the key derivation function ($\mathrm {xtrct\_xpnd}$). Diffie-Hellman key agreement and digital signatures are formalized in the same way as in [11]. The hash function and the key derivation function are formalized merely as function symbols Hash and xtrct_xpnd that have no equation, respectively. Additionally, we use some function symbols for representing extraction of keys such as $k_s$ and $k_c$ from k output by the key derivation function.

AEAD is formalized by first introducing a function symbol E for encryption. A term ${\texttt {E(k, iv, m, h)}}$ represents encryption of the plaintext m with additional authenticated data h encrypted with key k and nonce iv. We also introduce destructor function symbol D, extract_nonce, extract_AD and equations

$$\begin{aligned} {\texttt {D(k, iv, h, E(k, iv, m, h))}}= & {} {\texttt {m}} \\ {\texttt {extract\_nonce(E(k, iv, m, h))}}= & {} {\texttt {nonce}} \\ {\texttt {extrac\_AD(E(k, iv, m, h))}}= & {} {\texttt {h}}. \end{aligned}$$

The first equation means that a ciphertexts is decrypted and verified by using the valid key and the nonce. Note that since D is a destructor, if decryption fails in a process, e.g., due to incorrect nonce or key, the process halts. The other equations enables the adversary to obtain the nonce and the associated data from a ciphertext.

Fig. 3.

Descripton of the main process

Fig. 4.

Descripton of other processes that reply to queries from the adversary

C Definitions of Some Processes

The “main” processes that invokes clients and servers is shown in Fig. 3. It receives some parameters from the adversary through the public channel c. Figure 4 shows the processes that replies to $\mathsf {encrypt}$, $\mathsf {decrypt}$, $\mathsf {reveal}$, and $\mathsf {corrupt}$ queries and the process tap_m2 that serves as a secret channel that securely transmits $m_2$ from the server to the client when a $\mathsf {connprivate}$ query is issued.

In the formalization of secrecy, Oenc2 instead of Oenc is used. We must prohibit the adversary to send a plaintext twice in the $\mathsf {encrypt}$ query, e.g., and , because otherwise the adversary trivially knows the secret bit by comparing the two ciphertexts. However, this restriction cannot be directly modeled in ProVerif. We therefore use another function symbol Ef instead of E in Oenc2 for producing distinct ciphertext on each query, even if the adversary sends a plaintext more than once. This makes it useless to compare ciphertexts received by Oenc2.

D ProVerif Script