Analyzing and Fixing the QACCE Security of QUIC

  • Hideki Sakurada
  • Kazuki Yoneyama
  • Yoshikazu Hanatani
  • Maki Yoshida
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 10074)

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.

Keywords

QUIC QACCE model Automated verification ProVerif 

1 Introduction

1.1 Backgrounds

As mobile Internet devices (smartphones, tablet computers, wearable computers, etc.) are growing explosively, various web applications are used in our daily life. Devices and servers of applications frequently execute transport protocols to communicate via the Internet. Hence, to reduce latency of transport protocols is an important issue.

TLS (Transport Layer Security) [1] is the most widely used secure transport protocol. However, latency of TLS on establishing a connection between a device and a server is not low, and it may be a bottleneck of web applications in restricted bandwidth networks. Thus, several transport protocols [2, 3, 4, 5] have been studied to achieve both low latency and sufficient security. QUIC (Quick UDP Internet Connection) [5] is one of the most promising candidates of such protocols.

QUIC was developed by Google and implemented as a secure transport protocol of Google Chrome in 2013. TLS is the protocol on TCP (Transmission Control Protocol), and relies on the packet retransmission mechanism of TCP. On the other hand, QUIC is the protocol on UDP (User Datagram Protocol), and has a specific packet retransmission mechanism to reduce latency. Also, the number of rounds for key exchange is smaller than that of TLS. QUIC is widely implemented in Google’s servers, and Google Chrome is now the most popular browser (it takes 60.5 % of worldwide desktop browser usage in April 16, 2016) [6]. Therefore, to clarify the security of QUIC is very important in practice. However, no formal security discussion is given in Google’s documents.

There are some previous studies to formally define the security requirements for QUIC and to prove the security under appropriate assumptions of building blocks. Fischlin and Günther [7] proposed a security model for multi-stage key exchange protocols based on the Bellare-Rogaway model [8], and prove the key exchange part of QUIC satisfies their security definition. Their work is only for the key exchange part, and it still not clear if the entire protocol of QUIC is secure. Lychev et al. [9] proposed a new security model for Quick Connections (QC) protocols, called Quick Authenticated and Confidential Channel Establishment (QACCE) model. QC protocols represent an abstraction of transport protocols including QUIC and TLS1.3 [10]. The QACCE model captures the security of the entire transport protocol as well as the key exchange part. In the QACCE model, three security requirements are formulated: the server impersonation resistance, the channel corruption resistance, and the IP spoofing resistance. The server impersonation resistance guarantees that any adversary cannot impersonates an honest server. The channel corruption resistance guarantees that any adversary cannot reveal information about groups of messages exchanged between a client and a server without corrupting the server before or during the session. The IP spoofing resistance guarantees that any adversary cannot make the server accept a connection request on behalf of a client who did not request the connection to the server. These security requirements seem reasonable for QC protocols. They further proved the security of QUIC in the QACCE model. However, actually, the QACCE model is very complicated; and thus, it is hard to understand if the model captures requirements just enough.

1.2 Our Contribution

We show the first automated security verification of QUIC based on the QACCE model. We use verification tool ProVerif [11, 12, 13, 14] because ProVerif can generically deal with subtle security definitions like the QACCE model.

First, we formalize a symbolic model for QUIC and the QACCE model. Though the specification of QUIC contains updates of state and time synchronizations, ProVerif cannot directly support state and time. Hence, we reformulate the protocol of QUIC to avoid the direct management of state and time. Three security requirements of the QACCE model are exactly formalized as verification queries of ProVerif.

Next, we verify QUIC based on our symbolic formalization. If Lychev et al.’s security proofs were correct, ProVerif would be also expected to decide “secure”. However, ProVerif finds concrete attacks against all three security requirements. These attacks break the matching between a client and a server by modifying protocol flows. It causes that the client and the server believe distinct sessions as the matching session. Therefore, Lychev et al.’s security proofs are actually not correct.

Finally, we discuss the reasons why attacks occur. We conclude that there is no practical impact to the security of QUIC. The reason of attacks is that the QACCE model contains unnecessary strong definitions against desirable security requirements. Actually, by appropriately weakening the model, these attacks are easily prevented. We show how to weaken the QACCE model to capture the security of QUIC just enough.

2 Definition of QC Protocol

In this section we quote the definition of a Quick Connections (QC) protocol in [9], which is a communication protocol between a client and a server (the latter holds a public key and the corresponding secret key). The parties first agree on an initial session key, which can be used to exchange data until the final key is set. After the final key is set, it is used for further data exchange.

The protocol is associated with the security parameter \(\lambda \), a server key generation protocol \(\mathsf {Kg}\) that on input \(\lambda \) returns public and secret keys, an authenticated encryption with associated data scheme AEAD \(= (\mathcal {E},\mathcal {D})\) with key space \(\{0, 1\}^{\lambda }\), header space \(\{0, 1\}^*\), message space \(\{0, 1\}^*\), an IV-extraction function get\(\_\)iv that takes a key and a header and outputs an IV \(\in \{0, 1\}^n\) for each message to be encrypted or decrypted via the associated AEAD, and a scfg\(\_\)gen function that the server can use to update part of its global state \(\mathsf {scfg}\). The server can maintain global state other than its \(\mathsf {scfg}\). All global state is initially set to \(\varepsilon \). A protocol’s execution is associated with the universal notion of time, which is divided into discrete periods \(\tau _1, \tau _2,\ldots \). The keys are generated via \((pk, sk) \leftarrow _{R} \mathsf {Kg}(\lambda )\). The input of each party (representing what parties know at the beginning) consists of the public key of the server pk and the list of messages \(M^{send} = M_1, \ldots , M_m\) for some \(m \in \mathbb {N}\) and where each \(M_i \in \{0, 1\}^*\), that a party needs to send securely (\(M^{send}\) can also be \(\varepsilon \)). The server has an additional input: the secret key. All parties can keep global state. We suppose that the client and server are given vectors of messages as input.

A QC protocol consists of four phases. Each message exchanged by the parties must belong to some unique stage, but the second and third stages may overlap:

Stage 1: Initial Key Agreement.

At the end of this stage, each party sets the initial key variable \(ik = (ik_{c}, ik_{s}, iaux)\), where \(iaux \in \{0, 1\}^*\) (initially set to \(\varepsilon \)) is any additional information used for encryption and decryption.

Stage 2: Initial Data Exchange.

In this stage, messages from the input data list can be transmitted using the associated AEAD scheme and the key ik. The server uses \(ik_{c}\) to encrypt and \(ik_{s}\) to decrypt, whereas the client uses \(ik_{s}\) to encrypt and \(ik_{c}\) to decrypt. At the end of this stage, each party outputs the list of messages \(M^{iget} = M_1,\ldots , M_{m'}\) for some \(m'\in \mathbb {N}\) and where each \(M_i \in \{0, 1\}^*\), (\(M^{iget}\) can also be \(\varepsilon \)), representing the messages the party received in the initial data exchange phase.

Stage 3: Key Agreement.

At the end of this stage, each party sets the session key variable \(k = (k_{c}, k_{s}, aux)\), where \(aux \in \{0, 1\}^*\) (initially set to \(\varepsilon \)) is any additional information used for encryption and decryption.

Stage 4: Data Exchange.

In this stage, messages from the input data list can be sent using the associated AEAD scheme and the key k. The server uses \(k_{c}\) to encrypt and \(k_{s}\) to decrypt, whereas the client uses \(k_{s}\) to encrypt and \(k_{c}\) to decrypt. At the end of this stage, each party outputs the list of messages \(M^{get} = M_1,\ldots , M_{m''}\) for some \(m''\in \mathbb {N}\) and where each \(M_i \in \{0, 1\}^*\), (\(M^{get}\) can also be \(\varepsilon \)), representing the messages the party received in the final stage.

We say that a party rejects a packet if it outputs \(\bot \), and accepts it otherwise.

When a client (or server) party sets ik in Stage 1 corresponding to a particular QC protocol execution instance, we say that client (or server) party sets that ik with a particular server (or client) party if every sent and received packet by that client (or server) party in Stage 1 of that QC protocol execution instance belongs to that client (or server) party’s connection with that server (or client) party. We can define an analogous notion for setting k with respect to Stage 3. We will refer to parties that set ik’s in Stage 1 with each other as each other’s peers. The correctness of the protocol requires that the input data of one party’s \(M^{send}\) be equal to outputs of the other party’s \(M^{iget}, M^{get}\). In other words, the protocol is correct if it allows the parties to exchange the data that they intended to exchange with their corresponding communication partners in the protocol, while preserving the order of the messages.

3 QACCE Model, Revisited

In this section, we quote the QACCE model. However, the QACCE model in [9] has several errors regardless of our verification result. We show a corrected version of the QACCE model.

Security Experiment. Fix the security parameter \(\lambda \) and a QC protocol \(\varPi \) with associated server key generation protocol \(\mathsf {Kg}\), scfg\(\_\)gen, an authenticated encryption with associated data scheme AEAD \(= (\mathcal {E}, \mathcal {D})\) with key space \(\{ 0, 1 \}^{\lambda }\) and additional authenticated data (which we will denote by H) space \(\{ 0, 1 \}^*\).

The experiment \({\text {Exp}}^\mathsf {QACCE}_{\varPi } (A)\) associated with the adversary A is defined as follows: We consider two sets of parties, clients and servers, \(C = \{ C_1, \dots , C_{\ell } \}\) and \(S = \{ S_1, \dots , S_{\ell } \}\), for parameter \(\ell \in \mathbb {N}\) denoting the maximum possible number of servers or clients. The experiment first generates server key pairs \((pk_i, sk_i) \leftarrow _{R} \mathsf {Kg}(\lambda )\), \(k_{stk} \leftarrow _{R} \{ 0, 1 \}^{128}\), and \(\mathsf {scfg}^t_i \leftarrow _R \text {scfg}\_\text {gen} (sk_i, \tau _t, \lambda )\), for all time periods, for all \(i \in [\ell ]\).

To capture several sequential and parallel executions of the protocol we follow the standard approach and associate each party \(P_i \in C \cup S \) with a set of stateful oracles \(\pi ^{1}_{p,i}, \dots , \pi ^{d}_{p,i}\), for parameter \(d \in \mathbb {N}\) and \(p \in \{ c, s \}\), where each oracle \(\pi ^{r \in [d]}_{p,i}\) represents a process that executes one single instance of the protocol at party \(P_i\) and p indicates whether the party in question is a client or server. Intuitively, each oracle \(\pi ^{q}_{p,i}\) of some party \(P_i \in C \cup S \) models that party’s IP address and a unique port number. The experiment flips a bit \(b^{q}_{p,i} \leftarrow _R \{ 0, 1 \}\) for each oracle \(\pi ^{q}_{p,i}\).

Each server oracle gets the corresponding \(\mathsf {scfg}^t_i\) at the beginning of each time period. We assume that at each point of the protocol’s execution each party (adversary included) can tell what time period it is. We also assume that every server oracle is aware what protocol stage it is in for every client oracle that it is and/or has been exchanging messages with. With this assumption we are not required to keep track of the stages in the simulations. Even though the server keeps local state and knows which stage it is in, it may have inaccurate view of the stage of the protocol because it is not guaranteed to know the correct identity of the party it is talking with. We refer to oracles that set ik with each other as peers.

The adversary A is given the public keys of all servers \(pk_1, \dots , pk_{\ell }\) and can interact with all oracles of all parties by issuing queries. The values in parentheses are supplied by A. If the parameter in parentheses is an oracle, e.g. \(\pi ^q_{p,i}\), this means that A needs to supply the indices piq specifying the oracle.

  • \(\mathsf {connect}(\pi ^{q}_{c, i}, \pi ^{r}_{s, j})\), for \(i, j \in [\ell ]\), \(q, r \in [d]\).

    As a result, \(\pi ^{q}_{c,i}\) outputs the initial connection request packet (first connection for that client party for that particular time period) that it would send specifically to oracle \(\pi ^{r}_{s,j}\) according to the protocol. The output of this query is not delivered to the recipient oracle, but is just given to A. This query allows the adversary to ask a client oracle to start communicating with a particular server party for the first time between those parties for a particular time period.

  • \(\mathsf {resume}(\pi ^{q}_{c, i}, \pi ^{r}_{s,j})\), for \(i, j \in [\ell ]\), \(q, r \in [d]\).

    This query returns \(\bot \) if ik corresponding to oracle \(\pi ^{q}_{c,i}\) is not set. Otherwise, \(\pi ^{q}_{c,i}\) outputs the 0-RTT connection request packet that it would send to an oracle \(\pi ^{r}_{s,j}\) according to the protocol. The output is given to A, who can deliver it to the destination oracle, modify it, or drop it. This query allows the adversary to ask a particular client oracle to request a 0-RTT connection with a particular server party, if the client party corresponding to that oracle has communicated before with that server in a particular time period. Recall that every server party is aware of its communication status with respect to every client oracle that may contact it.

  • \(\mathsf {send}(\pi ^{r}_{p,j}, m)\), for \(p \in \{ c, s \}\), \(j \in [\ell ]\), \(r \in [d]\) and \(m \in \{ 0, 1 \}^*\).

    As a result, m is sent to \(\pi ^{r}_{p,j}\), which will respond with \(\bot \) if the oracle is in data exchange phase. Otherwise, A gets the response, which is defined according to the protocol. This query allows the adversary to send a specified packet m to a specified destination oracle. Note that the attacker must provide a header for the packet that specifies the source and destination IP addresses and port numbers as well as packet sequence numbers of its choice. The destination oracle can check this information. The adversary gets control of the resulting packet and can choose to modify, drop, or deliver it to an oracle.

  • \(\mathsf {revealik} ( \pi ^{q}_{p,i})\), for \(p \in \{ c, s \}\), \(i \in [\ell ]\), \(q \in [d]\).

    As a result, A receives the contents of variable ik for oracle \(\pi ^{q}_{p,i}\). This query allows the adversary to learn the initial key set by the oracle of its choice.

  • \(\mathsf {revealk}(\pi ^{q}_{p,i})\), for \(p \in \{ c, s \}\), \(i \in [\ell ]\), \(q \in [d]\).

    As a result, A receives the contents of variable k for oracle \(\pi ^{q}_{p,i}\). This query allows the adversary to learn the final key set by the oracle of its choice.

  • \(\mathsf {corrupt}(S_i)\), for \(i \in [\ell ]\).

    A gets back \(sk_i\) and the current \(\mathsf {scfg}^t_i\) and any other state of \(S_i\). This query allows the adversary to corrupt the server of its choice and learn its long-term secrets including \(\mathsf {scfg}^t_i\) for the current time period.

  • \(\mathsf {encrypt}(\pi ^{r}_{p,j}, m_0, m_1, H, \mathsf {init})\), for \(p \in \{ c, s \}\), \(j \in [\ell ]\), \(r \in [d]\), \(m_0, m_1, H \in \{ 0, 1 \}^*\), and \(\mathsf {init} \in \{ 0, 1 \}\):

    It returns \(\bot \) if \(|m_0| \ne |m_1|\). When \(\mathsf {init} = 1\), it returns \(\bot \) if \(\pi ^{r}_{p,j}\) is not in the initial data exchange stage, or \({\text {IV}} \leftarrow get\_iv(ik, H)\) was used; otherwise, it returns \((H, \mathcal {E}( ik_{p'}, {\text {IV}}, H, m_{b^{r}_{p,j}}))\). When \(\mathsf {init} = 0\), it returns \(\bot \) if \(\pi ^{r}_{p,j}\) is not in the data exchange stage, or \(\text {IV} \leftarrow get\_iv(k, H)\) was used; otherwise, it returns \((H, \mathcal {E}( k_{p'}, \text {IV}, H, m_{b^{r}_{p,j}}))\). This query, unlike the previous ones, deals with the initial and final data exchange phases1 (flag \(\mathsf {init}\) specifies which), while the previous ones concerned the initial and final key exchange phases. It is designed to follow the standard approach of capturing message privacy under chosen message attack. It allows the adversary to obtain a randomly chosen ciphertext out of the two messages provided by the adversary. Just like in the security definition for AEAD, the attacker can select the header H. For QUIC it means that the adversary can specify the source and destination IP addresses and port numbers as well as packet sequence numbers of its choice. Unlike the AEAD security model, however, we do not let the adversary select the IV because in QUIC the IV depends on the secrets of a party and is not under the attacker’s control. get\(\_\)iv is the function that we require to produce initialization vectors used for encryption and appropriate headers. The initialization vector is not given to the adversary. The adversary is restricted to providing H whose destination IP address and port number correspond to \(\pi ^{r}_{p,j}\) and whose source IP address and port number correspond to an oracle \(\pi ^{q}_{p',i}\) in the experiment, for \(p' \in \{ c, s \} \backslash \{ p \}\).

  • \(\mathsf {decrypt}(\pi ^{r}_{p,j}, \mathcal {C}, H, \mathsf {init})\), for \(p \in \{ c, s \}\), \(j \in [\ell ]\), \(r \in [d]\), \(\mathcal {C} , H \in \{ 0, 1 \}^{*}\), and \(\mathsf {init} \in \{ 0, 1 \}\):

    It returns \(\bot \) if \((H, \mathcal {C})\) was output before by \(\mathsf {encrypt}( \pi ^{q}_{p',i}, *,\) \( *, *, \mathsf {init})\).2

    When \(\mathsf {init} = 1\), it returns \(\bot \) if \(\pi ^{r}_{p,i}\) is not in the initial data exchange phase, or \(\mathcal {D}(ik_p, \text {IV}, H, \mathcal {C}) = \bot \), where \(\text {IV} \leftarrow get\_iv(ik,H)\); otherwise it returns \(b^{r}_{p,j}\). When \(\mathsf {init} = 0\), it returns \(\bot \) if \(\pi ^{r}_{p,i}\) is not in the data exchange phase, or \(\mathcal {D}(k_p, \text {IV}, H, \mathcal {C}) = \bot \), where \(\text {IV} \leftarrow get\_iv(k,H)\); otherwise it returns \(b^{r}_{p,j}\). This query also concerns the initial and final data exchange phases. It follows the standard approach to capture authenticity for AEAD schemes. The adversary’s goal is to create a “new” valid ciphertext. If it succeeds, it is given the challenge bit and thus can win.

  • \(\mathsf {connprivate}( \pi ^{q}_{c,i}, \pi ^{r}_{s,j})\), for \(i, j \in [\ell ]\), \(q, r \in [d]\).

    As a result, the initial connection request is sent to \(\pi ^{r}_{s,j}\). The response, which is defined according to the protocol, is sent to \(\pi ^{q}_{c,i}\) and not shown to A. Any following response of \(\pi ^{q}_{c,i}\) is not shown to A. It models IP spoofing attacks.

After the adversary is done with queries it may output a tuple (piqb), for \(p \in \{ c, s \}\).

Matching Conversation. For \(p \in \{ c, s \}\), \(p' \in \{ c, s \} \backslash \{ p \}\), \(i, j \in [\ell ]\), \(q, r \in [d]\), we denote with \(R^{q}_{p,i}\) the sequence of all messages used for establishing keys (during stages 1 and 3) sent and received by \(\pi ^{q}_{p,i}\) in chronological order, and we call \(R^{q}_{p,i}\) the message record at \(\pi ^{q}_{p,i}\). With respect to two message records \(R^{q}_{p,i}\) and \(R^{r}_{p',j}\), we say that \(R^{q}_{p,i}\) is a prefix of \(R^{r}_{p',j}\), if \(R^{q}_{p,i}\) contains at least one message, and the messages in \(R^{q}_{p,i}\) are identical to and in the same order as the first \(| R^{q}_{p,i} |\) messages of \(R^{r}_{p',j}\). We say that \(\pi ^{q}_{p,i}\) has a matching conversation with \(\pi ^{r}_{p',j}\), if either \(R^{r}_{p',j}\) is a prefix of \(R^{q}_{p,i}\) and \(\pi ^{q}_{p,i}\) has sent the last message(s), or \(R^{q}_{p,i}\) is a prefix of \(R^{r}_{p',j}\) and \(\pi ^{r}_{p',j}\) has sent the last message(s).

Note that the notion of a matching conversation is not sufficient to define peers because, unlike in TLS, communicating parties in QUIC may set initial keys without having a matching conversation. This is why throughout our analysis the notion of peers is instead equivalent to the notion of one party setting a key with another party.

Security Requirements.
  • The server impersonation advantage of A \(\mathbf{Adv}^{\mathsf {s-imp}}_{\varPi } (A)\) is the probability that there exists an oracle \(\pi ^{q}_{c,i}\) such that k of this oracle is set and there is no oracle \(\pi ^{r}_{s,j}\) corresponding to a server party \(S_j\) such that \(\pi ^{q}_{c,i}\) has a matching conversation to \(\pi ^{r}_{s,j}\), no \(\mathsf {revealik}\) contained ik possibly set in the optional initial key agreement stage between \(\pi ^{q}_{c,i}\) and \(\pi ^{r}_{s,j}\), and \(S_j\) was not corrupted.

The above captures the attack when the adversary impersonates an honest server and makes a client think it sets a key shared with the server, but the adversary may have the shared key instead.

  • The channel-corruption advantage of A \(\mathbf{Adv}^{\mathsf {ch-corr}}_{\varPi } (A)\) is \(2 \Pr [ b = b^{q}_{p,i} ] - 1\), where if \(p = s\), then it must be the case that \(\pi ^{q}_{s,i}\) has a matching conversation with some client oracle \(\pi ^{r}_{p',j}=\pi ^{r}_{c,j}\) satisfying the conditions below, and if \(p = c\), then the peer server oracle \(\pi ^{r}_{p',j}\) of \(\pi ^{q}_{c,i}\) must satisfy the same conditions. Let S be the server in this session.

    1. 1.

      no \(\mathsf {encrypt}(\pi ^{q}_{p,i}, *, *, *, 1)\) and \(\mathsf {encrypt}( \pi ^{r}_{p',j}, *, *, *, 1)\) queries were made for any \(*\) after or during the same time period \(\tau _t\) that S was corrupted,

       
    2. 2.

      no \(\mathsf {encrypt}(\pi ^{q}_{p,i}, *, *, *, *)\) and \(\mathsf {encrypt}(\pi ^{r}_{p',j} , *, *, *, *)\) queries were made for any \(*\) after S was corrupted, and

       
    3. 3.

      no \(\mathsf {revealik}(\pi ^{q}_{p,i})\) and \(\mathsf {revealik}(\pi ^{r}_{p',j})\) or \(\mathsf {revealk}(\pi ^{q}_{p,i})\) and \(\mathsf {revealk}(\pi ^{r}_{p',j})\) queries returned the key used to answer any \(\mathsf {encrypt}(\pi ^{q}_{p,i}, *, *, *, *)\) and \(\mathsf {encrypt}(\pi ^{r}_{p',j}\),\(*\), \(*\), \(*\), \(*)\) queries for any \(*\) respectively.

       

The above captures the attacks in which information about groups of messages exchanged between the client and the server is leaked without the adversary corrupting the server party (1) before or (2) during the same time period as attempting the breach as well as without (3) revealing the initial and session keys ik and k. Thus, we capture a slightly weaker notion of forward secrecy by restricting the adversary to corrupt the appropriate server only after the time period when the adversary attempts the breach.

  • The IP spoofing of A \(\mathbf{Adv}^{\mathsf {ips}}_{\varPi } (A)\) is the probability that there exist oracles \(\pi ^{q}_{c,i}\) and \(\pi ^{r}_{s,j}\) such that at some time period \(\tau _t\) A makes a \(\mathsf {send}(\pi ^{r}_{s,j} , m')\) query, \(\pi ^{r}_{s,j}\) does not reject this query, \(S_j\) was not corrupted, \(m'\) is not an output resulting from any previous connection request query (done via \(\mathsf {connect}\) or \(\mathsf {resume}\) queries), and the only other query A is allowed to make concerning \(\pi ^{q}_{c,i}\) during \(\tau _t\) is the \(\mathsf {connprivate}(\pi ^{q}_{c,i}, \pi ^{r}_{s,j} )\) query.

This goal captures attacks in which the adversary wins if it succeeds in having the server accept a connection request on behalf of a client who either did not request connection to that server or previously requested only an initial connection but did not request any further connections in the same time period. The adversary issues a connection query hoping it gets accepted by the server, possibly preceded by the only other allowed query in that time period: connection request (\(\mathsf {connprivate}\)) whose output it cannot see.

Security Definition. We say that a QC protocol \(\varPi \) is QACCE-secure if its advantage \(\mathbf{Adv}^{\mathsf {QACCE}}_{\varPi } (A)\), defined as \(\mathbf{Adv}^{\mathsf {s-imp}}_{\varPi } (A) + \mathbf{Adv}^{\mathsf {ips}}_{\varPi }(A) + \mathbf{Adv}^{\mathsf {ch-corr}}_{\varPi } (A)\), is negligible (in \(\lambda \)) for any polynomial-time adversary A.

4 Specifications of QUIC

We recall the specification of QUIC. Due to the page limitation, we cannot give the entire specification here. Please see [9] for the details. QUIC has the 1-RTT and 0-RTT protocols. Let \(\mathcal {SS} = (\mathsf {Kg}_s, \mathsf {Sign}, \mathsf {Ver})\) be a digital signature scheme. We assume that each server has generated a key pair \((pk_S, sk_S) \leftarrow _R \mathsf {Kg}_s(\lambda )\) and distributed the verification key \(pk_S\) using PKI. The 1-RTT protocol proceeds as follows (more detailed protocol flow is shown in Table 1 in Appendix A).

Stage 1: Initial Key Agreement.

The client and the server run Diffie-Hellman (DH) key exchange as follows. The client sends a message \(m_1\), which we call the initial connection request message of this session, containing a randomly generated connection id \(\mathtt {cid}\). The server responds with a message \(m_2\) containing a part \(\mathtt {scfg}^t_{\mathtt {pub}}\) of the server’s global state \(\mathtt {scfg}^t\) and the source-address token \(\mathtt {stk}\) of the client. The part \(\mathtt {scfg}^t_{\mathtt {pub}}\) contains the server’s static DH public value signed with \(sk_S\). The token \(\mathtt {stk}\) contains the client’s IP address encrypted using AEAD with the key \(k_{\mathtt {stk}}\) generated by the server. Then, the client sends a message \(m_3\) containing the \(\mathtt {stk}\) and the client’s DH public value. The server rejects this if \(\mathtt {stk}\) is expired or does not contain the client’s IP address. Finally, they compute the key ik by DH and a key derivation function xtrct_xpnd.

Stage 2: Initial Data Exchange.

The client and the server sends messages \(m_4\) and \(m_5\) (and more, if any) encrypted by AEAD with the key and nonces extracted from ik.

Stage 3: Key Agreement.

The server sends a message \(m_6\) containing an ephemeral DH public value encrypted by AEAD with the key and nonces extracted from ik. The client and the server computes the key k using the server’s new public value.

Stage 4: Data Exchange.

The client and the server sends messages \(m_7\) and \(m_8\) (and more, if any) encrypted by AEAD with the key and nonces extracted from k.

The 0-RTT protocol omits the messages \(m_1\) and \(m_2\) above, assuming that the client have received \(\mathtt {scfg}^t_{\mathtt {pub}}\) and \(\mathtt {stk}\) in a 1-RTT session. In a 0-RTT session, the message \(m_3\) is called the 0-RTT connection request message of this session. The server’s global state \(\mathtt {scfg}^t\) and the token \(\mathtt {stk}\) are eventually expired, in which case the 1-RTT protocol is used.

5 Protocol Languages and Informal Semantics

We use the ProVerif tool [11, 12, 13, 14] for our analysis. ProVerif is a tool for automatically analyze various security properties of security protocols. ProVerif adopts a dialect of the applied pi calculus as a protocol language, which we can extend with functions symbols and equational rules. ProVerif can efficiently analyze protocols for an unbounded number of sessions by using abstraction based of Horn clauses.

We introduce ProVerif’s languages for specifying protocols and security properties. Due to space limitation, we present only fragments of the languages and their informal semantics that are used in our analysis. We further omit types of terms in the presentations below for brevity. Please refer to [11] for more complete explanation and details.

Variables, Terms, and Equations. We assume that there is an infinite number of variables \(x, y, z, n, \ldots \). A term is constructed from variables by applying a number of function symbols, which are declared by users. Function symbols that take no argument are called constants. Along with function symbols, equations involving them are also defined. Terms are rewritten by using the equations as axioms. Some function symbols are declared as destructors. When a destructor is used in a protocol execution, it must be immediately rewritten by an equation; otherwise the execution halts. Function symbols and the equations for cryptographic primitives in QUIC are shown in Appendix B.

Processes. A protocol is described as a process, which typically consists of some subprocesses. The syntax for processes are given as follows.The process Open image in new window is an inactive process and is usually omitted when it is a subprocess of other process. \(\texttt {!} P\) is an unbounded number of copies of a process P running in parallel. \(P\texttt {||} Q\) is a parallel execution of processes P and Q. Processes running in parallel may communicate each other over channels using commands Open image in new window and Open image in new window , which stores the received term in a variable x and sends a term t through the channel c, respectively. A fresh random data such as keys and nonces are generated and stored on a variable x by \({\texttt {new}\, x}\). A condition cond is checked by \(\texttt {if}\,cond\,\texttt {then}\), where cond is an equation Open image in new window or an inequation Open image in new window ; if cond is not true, the process halts. A term t is assigned on a variable x by \(\texttt {let}\,x{\texttt {=}}t\,{\texttt {in}}\). An event is issued by Open image in new window , where ev is a function symbol for events. Events do not affect the protocol execution but are referred to in the security definitions. A table tab is extended with an entry t by Open image in new window , and the existence of an entry t is checked by Open image in new window ; if t is not on tab, the process halts.

We actually use a little larger fragment of this language that has pattern-matching. For example, a process Open image in new window deconstructs t as a pair \((t_{1}, t_{2})=t\), assigns \(t_1\) on the variable x, and checks if \(s=t_2\) as in \(\texttt {if}\, s\texttt {=}t_2\, \texttt {then}\, P\).

Security Properties. Among various security properties that ProVerif can analyze, we use correspondence assertions and observational equivalence. A correspondence assertion is described as follows:where \({\tilde{x}^{(j)} \subseteq \{x_{1},\ldots , x_{n} \} }\), i.e., \({\tilde{x}^{(j)} = x_{i^{(j)}_{1}},\ldots x_{i^{(j)}_{l}}}\) for some indices \({i^{(j)}_{1},\ldots ,i^{(j)}_{l}}\). This assertion means that, for all values of variables \(x_{1},\ldots ,x_{n}\), if the event Open image in new window occurs in an execution of a process, then at least one of the events Open image in new window must occur in this execution.
An observational equivalence property is specified by using a special function symbol choice in the protocol. Intuitively, if a term Open image in new window is used in a process, either Open image in new window or msg1 is chosen as the value of the term, and ProVerif checks if the adversary may know which one is chosen.
Fig. 1.

Descripton of the server process

Fig. 2.

Descripton of the client process

6 Formalization of the QUIC Protocol

While a protocol is modeled as a collection of stateful oracles in the QACCE model, ProVerif has a limited support for dealing with state and time. We therefore reformulate QUIC without using explicit updates of local states (variables) and assume that server configurations and source-address tokens are never expired. The latter allows us to capture more attacks than [9], which assumes no two server configurations of a server are valid at the same time period. On the other hand, this also may allow false attacks that are impossible in reality.

We model QUIC as processes for servers and clients defined in Figs. 1 and 2, respectively. The whole ProVerif script for our analysis is given in Appendix D. They are invoked unbounded number of times from the main process (shown in Appendix C) and are given some parameters such as IP addresses and keys for digital signatures. They receive messages from the public channel and send the responses to the channel following the protocol definition. The adversary may also send messages to the processes and receive the responses. This models \(\mathsf {send}\) queries in the QUIC protocol model.

A client process starts with arguments such as IP addresses and port numbers of the client and the peer server, which are received from the adversary in the main process. After receiving \(m_2\), it executes the subsequent part of the protocol unbounded number of times, which is indicated by “!.” The first and the other executions correspond to a 1-RTT session and 0-RTT sessions, respectively. In this way the adversary controls timings and parameters of client processes as it does with \(\mathsf {connect}\) and \(\mathsf {resume}\) queries in the QUIC protocol model. Similarly, server processes also repeat the execution after sending \(m_2\) unbounded number of times.

After the initial and final key agreement phase, each process invokes two subprocesses Oenc and Odec, which models \(\mathsf {encrypt}\) and \(\mathsf {decrypt}\) queries, that encrypts and decrypts messages received from the adversary. Oenc is defined to receive a plaintext from the adversary. We later consider a variation of Oenc, which receives two plaintexts. Each server and client process also invokes other subprocesses Ocorrupt and Oreveal, which models \(\mathsf {corrupt}\) and \(\mathsf {reveal}\) queries, that leaks the server’s long-term secrets and the session keys, respectively, when queried by the adversary. Queries to these subprocesses are recorded as events, which is referred to in the security definitions. The definitions of these subprocesses are shown in Appendix C.

For modeling matching conversations, messages that have sent and received at each step of the initial and final key agreement phases are recorded on a table called conversations. A conversation that should be matched is given as arguments when subprocesses Oenc and Odec are invoked, and these subprocesses check if the conversation is on the table, i.e., there is a peer that has the conversation.

7 Formalization of the QACCE Security

The QACCE security is formalized as follows, as security properties against the server impersonation, channel corruption, and IP spoofing attacks.

Server Impersonation. The security against the server-impersonation attack is formalized by the following query:
Intuitively, this query means that if a client sets a key during a conversation conv with a session identified by cid with a server S, one of the following cases must be true:
  • There is a server that sets a key during this (matching) conversation in this session, indicated by the server_k_set event.

  • The key (\(ik_c\)) for encrypting messages to the client in the initial data exchange and the key agreement phases of this session is revealed, indicated by the revealed event.

  • The server is corrupted, indicated by the corrupted event.

Channel Corruption. The channel-corruption attack succeeds if a \(\mathsf {decrypt}\) query succeeds, returning the secret bit \(b_{p,j}^r\), or the adversary successfully guesses the bit. We separately formalize these two cases as a correspondence assertion and as observational equivalence. We call the security properties for these cases as authenticity and secrecy.
Similarly to the case of server-impersonation, authenticity is formalized as follows:
This means that if a decryption query with a ciphertext C with a header H succeeds, the ciphertext must have been made an encryption query within this session, unless the server is corrupted or the session secret has been revealed. While the original security definition allows corruption of the server S of this session as long as \(\mathsf {encrypt}\) query is not issued after that, our formalization does not allow to corrupt the server because ProVerif does not precisely model time as in “after that.”

Secrecy is formalized as observational equivalence between two variations of the protocol. In these variations, Oenc is modified to receive a pair of plaintexts Open image in new window and msg1 and encrypt Open image in new window , which is Open image in new window and msg1 in the first and the second variations, respectively. This is defined as Oenc2 in Appendix C. Since ProVerif does not allow us to use events and observational equivalence at the same time, we disable Ocorrupt and Oreveal in the analysis of secrecy.

IP Spoofing. We assume that initial connection requests (\(m_1\)) to servers are sent only by \(\mathsf {connprivate}\) queries because otherwise the IP spoofing attack trivially succeeds. Equivalently, instead of prohibiting initial connection requests and implementing \(\mathsf {connprivate}\) queries, we define the success condition of the IP spoofing attack so that the attack succeeds only if the response to the initial connection request is not received. We also let the IP spoofing attack succeed only if \(m_3\) is accepted by a server. The security against the IP spoofing attack is formalized by the following query:
Intuitively, this query means that if a server S who has sent m2 accepts m3, a client has sent m3, unless m2 is has been captured or the server S has been corrupted.

8 Results of the Analysis

ProVerif reports attacks shown below, on all the properties formalized in previous section. These attacks exploit the following facts:
  1. (I)

    Server accepts a valid source-address token (\(\mathtt {stk}\)) even though it is distinct from the one generated in the current session.

     
  2. (II)

    The same keys are used in the initial data exchange and the final key agreement phases of a session, and in the QACCE model headers, which contain sequence numbers, in \(\mathsf {encrypt}\) and \(\mathsf {decrypt}\) queries are arbitrarily chosen by the adversary and are not checked by the oracles.

     
Server Impersonation. The first attack exploits the above fact I. A man-in-the-middle-adversary has a source-address token \(\mathtt {stk}'\) that is issued in the previous session and is not yet expired. It replaces the new source-address token \(\mathtt {stk}\) sent from the server with \(\mathtt {stk}'\). Since this causes parties to have distinct conversations, in which the tokens are distinct, although the same key is set, this attack meets the definition of the (successful) server impersonation attack.

This attack is excluded from the server impersonation attacks if we modify the definition of matching conversations so that it remarks only \(m_3\) and \(m_6\). i.e., the argument conv of the events client_k_set and server_k_set may contain those messages. However, another attack that exploits the fact II is reported in this case: in the key agreement phase of a session, a man-in-the-middle adversary forges \(m_6\) using an \(\mathsf {encrypt}\) query in which the plaintext is \((\mathtt {scfg}_\mathtt {pub}^t, \tilde{\mathtt {pub}'}_s, \mathtt {stk})\) with an arbitrary \(\tilde{\mathtt {pub}'}_s\), and the sequence number in the header is the one for \(m_6\). It then replaces the \(m_6\) from the server with the forged version. This causes the parties to fail to have matching conversations.

Channel Corruption. Attacks similar to the above second attack are reported for authenticity and secrecy.

In the attack on authenticity, a man-in-the-middle adversary captures \(m_6\) sent from the server and sends it as a message in the initial data exchange phase, i.e., issues a query \(\mathsf {decrypt}(\pi _{c,j}^r, m_6, H, \mathsf {init})\) to the client \(\pi _{c,j}^r\) where \(H=(\mathtt {cid}, \mathtt {sqn})\) is a pair of the connection id and the sequence number. Since the client is still in the initial data exchange phase and has a matching conversation of the server, and the messages is not output of an encryption query, this attack meets the definition of the channel-corruption attack.

In the attack on secrecy, a man-in-the-middle attacker issues a query \(\mathsf {encrypt}(\pi _{s,j}^r, m\), \(m'\), H, \(\mathsf {init})\) in the data exchange phase so that it succeeds to obtain the ciphertext \(e'\) of \(m_6\) with probability 1 / 2; m is a random plaintext and \(m'\) is the triplet \((\mathtt {scfg}_\mathtt {pub}^t, \tilde{\mathtt {pub}'}_s, \mathtt {stk})\) with an arbitrary \(\tilde{\mathtt {pub}'}_s\), and the sequence number in H is the one for \(m_6\). The adversary then sends the \((\mathtt {IP}_s, \mathtt {IP}_c, \mathtt {port}_s, \mathtt {port}_c, H, e')\) to the client in the key agreement phase. If \(b_{s,j}^r=1\), the client proceeds to the data exchange phase; otherwise, the client halts because the message is not a valid \(m_6\).

IP Spoofing. This attack exploits the fact I. A man-in-the-middle attacker captures a valid source-address token sent in the previous session. In the current session started using a \(\mathsf {connprivate}\) query, it makes a c_hello message using the token and sends it by a \(\mathsf {send}\) query to the server. This message is accepted by the server, and thus this IP spoofing attack succeeds.

9 Fixing the QACCE Security

In this section, we suggest some fixes for the security definitions. ProVerif reports that QUIC is secure for the fixed definitions suggested below.

In our first server-impersonation attack, the source-address tokens are not agreed by the server and the client, although the tokens have the same IP address. This is not harmful if we assume that tokens are only for avoiding IP-spoofing attacks. It is therefore reasonable to exclude this attack from the definition of the server-impersonation attacks, modifying the definition of matching conversations so that it takes care of only \(m_3\) and \(m_6\) messages.

Our second server-impersonation attack and channel-corruption attacks relies on the fact that in the QACCE model the headers in \(\mathsf {encrypt}\) and \(\mathsf {decrypt}\) queries are arbitraryly chosen by the adversary and are not checked by the oracles. However, in reality, headers are not arbitrary: at least sequence numbers contained in the headers must be incremented in each encryption and checked by the recipient. We therefore suggest to fix the QACCE model so that headers in \(\mathsf {encrypt}\) and \(\mathsf {decrypt}\) queries are defined and checked according to the (QUIC) protocol, respectively.

In the IP-spoofing security, the adversary cannot see messages containing the source-address token (\(\mathtt {stk}\)) issued in the current sessions. However, our attacks use a \(\mathtt {stk}\) in the previous session that is still valid. We therefore suggest to fix the definition of the IP-spoofing security to assume that the adversary does not see any valid \(\mathtt {stk}\) that can be used in the current session.

10 Conclusion

In this paper, we have automatically analyzed the QUIC protocol based on the QACCE model, using the ProVerif protocol analyzer. The main technical contribution is that we have given symbolic formalization of QUIC and the QACCE security for automatic analysis. Since the QACCE model is a general model for QC protocols, our formalization can be used for analyzing other QC protocols such as TLS. Our analysis have found some attacks, which show that the definition of QACCE security is unnecessarily strong and that analysis in [9] is not correct, alghouth these attacks have no practical impact on QUIC. We have further suggested fixes for the QACCE security and analyzed QUIC with the fixed security definitions.

Our results can be seen as a case study on how formal automatic analysis complements cryptoraphic analysis by hands of experts on cryptorgaphy. Since security analysis plays an important role in recent development of security protocols, believing an incorrect analysis result may lead the development to a wrong direction. It is therefore important to refine existing analysis results by automatic analysis.

Footnotes

  1. 1.

    In the original model, this query returns the encryption of \(m_{b^{q}_{p,j}}\). However, since p in \(m_{b^{q}_{p,j}}\) is equal to p in \(\pi ^{r}_{p,j}\), \(m_{b^{q}_{p,j}}\) must be changed to \(m_{b^{r}_{p,j}}\).

  2. 2.

    In the original model, \(\mathsf {encrypt}\) query for \(\pi ^{r}_{p,j}\) is prohibited. However, \(\mathsf {encrypt}( \pi ^{r}_{p,j}, *, *, *, \mathsf {init})\) returns the ciphertext generated by p, and it is not reasonable. In this definition, the ciphertext of generated by \(p'\) should be prohibited. Thus, \(\pi ^{r}_{p,j}\) must be changed to \(\pi ^{q}_{p',i}\).

References

  1. 1.
    Dierks, T., Allen, C.: The TLS protocol version 1.0. In: RFC 2246 (Proposed Standard), Internet Engineering Task Force (1999)Google Scholar
  2. 2.
    Ford, B.: Structured streams: a new transport abstraction. In: SIGCOMM 2007, pp. 361–372 (2007)Google Scholar
  3. 3.
    Stewart, R.: Stream control transmission protocol. In: RFC 4960 (Proposed Standard), Internet Engineering Task Force (2007)Google Scholar
  4. 4.
    Erman, J., Gopalakrishnan, V., Jana, R., Ramakrishnan, K.K.: Towards a SPDY’ier mobile web? In: CoNEXT 2013, pp. 303–314 (2013)Google Scholar
  5. 5.
    Roskind, J.: QUIC (Quick UDP Internet Connections): Multiplexed Stream Transport Over UDP (2013). https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/
  6. 6.
    StatCounter: StatConter Global Stats: Top. 5 Desktop Browsers from to Apr 2016 (2016). http://gs.statcounter.com/#desktop-browser-ww-monthly-201504-201604
  7. 7.
    Fischlin, M., Günther, F.: Multi-stage key exchange and the case of Google’s QUIC protocol. In: ACM Conference on Computer and Communications Security 2014, pp. 1193–1204 (2014)Google Scholar
  8. 8.
    Bellare, M., Rogaway, P.: Entity authentication and key distribution. In: Stinson, D.R. (ed.) CRYPTO 1993. LNCS, vol. 773, pp. 232–249. Springer, Heidelberg (1994). doi: 10.1007/3-540-48329-2_21 CrossRefGoogle Scholar
  9. 9.
    Lychev, R., Jero, S., Boldyreva, A., Nita-Rotaru, C.: How secure and quick is QUIC? Provable security and performance analyses. In: 2015 IEEE Symposium on Security and Privacy, pp. 214–231 (2015)Google Scholar
  10. 10.
    Rescorla, E.: The Transport Layer Security (TLS) Protocol Version 1.3. Internet-Draft draft-ietf-tls-tls13-13 (2016)Google Scholar
  11. 11.
    ProVerif: Cryptographic protocol verifier in the formal model. http://prosecco.gforge.inria.fr/personal/bblanche/proverif/
  12. 12.
    Blanchet, B.: Automatic verification of correspondences for security protocols. J. Comput. Secur. 17(4), 363–434 (2009)CrossRefGoogle Scholar
  13. 13.
    Blanchet, B., Abadi, M., Fournet, C.: Automated verification of selected equivalences for security protocols. J. Logic Algebraic Program. 75(1), 3–51 (2008). Algebraic Process Calculi. The First Twenty Five Years and Beyond. IIIMathSciNetCrossRefMATHGoogle Scholar
  14. 14.
    Cheval, V., Blanchet, B.: Proving more observational equivalences with ProVerif. In: Basin, D., Mitchell, J.C. (eds.) POST 2013. LNCS, vol. 7796, pp. 226–246. Springer, Heidelberg (2013). doi: 10.1007/978-3-642-36830-1_12 CrossRefGoogle Scholar

Copyright information

© Springer International Publishing AG 2016

Authors and Affiliations

  • Hideki Sakurada
    • 1
  • Kazuki Yoneyama
    • 2
  • Yoshikazu Hanatani
    • 3
  • Maki Yoshida
    • 4
  1. 1.NTT Communication Science LaboratoriesNTT CorporationKanagawaJapan
  2. 2.Ibaraki UniversityIbarakiJapan
  3. 3.Corporate Research & Development CenterToshiba CorporationKanagawaJapan
  4. 4.Network Security Research InstituteNational Institute of Information and Communications Technology (NICT)TokyoJapan

Personalised recommendations