A Mechanised Cryptographic Proof of the Wireguard Virtual Private Network Protocol

A Mechanised Cryptographic Proof of the WireGuard Virtual Private Network Protocol

Benjamin Lipp, Bruno Blanchet, Karthik Bhargavan (INRIA Paris, Prosecco) June 18, 2019

4th IEEE European Symposium on Security and Privacy • uses modern cryptography • no cryptographic agility (unlike e. g., TLS) • works directly over UDP • only a few thousand lines of code • ongoing integration into the Linux kernel • aims to replace OpenVPN and IPsec • VPN providers are starting to adopt it

Introduction Protocol Contributions Model Analysis Conclusion

The WireGuard Virtual Private Network (VPN)

Protocol and implementation in progress since 2015

1/17 • works directly over UDP • only a few thousand lines of code • ongoing integration into the Linux kernel • aims to replace OpenVPN and IPsec • VPN providers are starting to adopt it

Introduction Protocol Contributions Model Analysis Conclusion

The WireGuard Virtual Private Network (VPN)

Protocol and implementation in progress since 2015 • uses modern cryptography • no cryptographic agility (unlike e. g., TLS)

1/17 • ongoing integration into the Linux kernel • aims to replace OpenVPN and IPsec • VPN providers are starting to adopt it

Introduction Protocol Contributions Model Analysis Conclusion

The WireGuard Virtual Private Network (VPN)

Protocol and implementation in progress since 2015 • uses modern cryptography • no cryptographic agility (unlike e. g., TLS) • works directly over UDP • only a few thousand lines of code

1/17 Introduction Protocol Contributions Model Analysis Conclusion

The WireGuard Virtual Private Network (VPN)

Protocol and implementation in progress since 2015 • uses modern cryptography • no cryptographic agility (unlike e. g., TLS) • works directly over UDP • only a few thousand lines of code • ongoing integration into the Linux kernel • aims to replace OpenVPN and IPsec • VPN providers are starting to adopt it

1/17 ⇄ ← N2 , P2

→ N3 , P3

ts

empty

→ N1 , P1

pub, Si 

pub Er ,

← pub C1 hkdf1(C0 = constC, Ei ) ∥ ← priv pub C2 k1 hkdf2(C1, dh(Ei , Sr )) ← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei ) pub ← pub pub Si  aenc(k1, 0, Si , H2) Ei , ∥ ← priv pub C3 k2 hkdf2(C2, dh(Si , Sr ))

ts ← aenc(k2, 0, timestamp(), H3) ← pub C4 hkdf1(C3, Er ) ← priv pub C5 hkdf1(C4, dh(Er , Ei )) ← priv pub C6 hkdf1(C5, dh(Er , Si ))

C7∥π∥k3 ← hkdf3(C6, psk)

empty ← aenc(k3, 0, empty, H6) → ← T ∥T ← hkdf2(C7, empty) ← → → P1 aenc(T , N1 = 0, P1, empty)

Introduction Protocol Contributions Model Analysis Conclusion

WireGuard’s Main Protocol: Noise IKpsk2 (simpliﬁed)

pub knows Sr , psk knows psk Initiator i Responder r ⇄ ← N2 , P2

→ N3 , P3

ts

empty

→ N1 , P1

pub pub pub S ← aenc(k , 0, S , H ) , i  1 i 2 Si  ∥ ← priv pub C3 k2 hkdf2(C2, dh(S , Sr )) pub i Er , ts ← aenc(k2, 0, timestamp(), H3) ← pub C4 hkdf1(C3, Er ) ← priv pub C5 hkdf1(C4, dh(Er , Ei )) ← priv pub C6 hkdf1(C5, dh(Er , Si ))

C7∥π∥k3 ← hkdf3(C6, psk)

empty ← aenc(k3, 0, empty, H6) → ← T ∥T ← hkdf2(C7, empty) ← → → P1 aenc(T , N1 = 0, P1, empty)

Introduction Protocol Contributions Model Analysis Conclusion

WireGuard’s Main Protocol: Noise IKpsk2 (simpliﬁed)

pub C1 ← hkdf1(C0 = constC, E ) knows Spub, psk knows psk i r priv pub C2∥k1 ← hkdf2(C1, dh(E , S )) Initiator i Responder r i r ← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei )

pub Ei , ⇄ ← N2 , P2

→ N3 , P3

empty

→ N1 , P1

ts

pub Er , ts ← aenc(k2, 0, timestamp(), H3) ← pub C4 hkdf1(C3, Er ) ← priv pub C5 hkdf1(C4, dh(Er , Ei )) ← priv pub C6 hkdf1(C5, dh(Er , Si ))

C7∥π∥k3 ← hkdf3(C6, psk)

empty ← aenc(k3, 0, empty, H6) → ← T ∥T ← hkdf2(C7, empty) ← → → P1 aenc(T , N1 = 0, P1, empty)

Introduction Protocol Contributions Model Analysis Conclusion

WireGuard’s Main Protocol: Noise IKpsk2 (simpliﬁed)

→ N3 , P3

empty

→ N1 , P1

pub Er , ← pub C4 hkdf1(C3, Er ) ← priv pub C5 hkdf1(C4, dh(Er , Ei )) ← priv pub C6 hkdf1(C5, dh(Er , Si ))

C7∥π∥k3 ← hkdf3(C6, psk)

empty ← aenc(k3, 0, empty, H6) → ← T ∥T ← hkdf2(C7, empty) ← → → P1 aenc(T , N1 = 0, P1, empty)

Introduction Protocol Contributions Model Analysis Conclusion

WireGuard’s Main Protocol: Noise IKpsk2 (simpliﬁed)

ts ← aenc(k2, 0, timestamp(), H3) ⇄ ← N2 , P2

→ N3 , P3

empty

→ N1 , P1

empty ← aenc(k3, 0, empty, H6) → ← T ∥T ← hkdf2(C7, empty) ← → → P1 aenc(T , N1 = 0, P1, empty)

Introduction Protocol Contributions Model Analysis Conclusion

WireGuard’s Main Protocol: Noise IKpsk2 (simpliﬁed)

pub C1 ← hkdf1(C0 = constC, E ) knows Spub, psk knows psk i r priv pub C2∥k1 ← hkdf2(C1, dh(E , S )) Initiator i Responder r i r ← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei ) pub pub pub pub S ← aenc(k , 0, S , H ) , , i  1 i 2 Ei Si  ts ∥ ← priv pub C3 k2 hkdf2(C2, dh(S , Sr )) pub i Er , ts ← aenc(k2, 0, timestamp(), H3) ← pub C4 hkdf1(C3, Er ) ← priv pub C5 hkdf1(C4, dh(Er , Ei )) ← priv pub C6 hkdf1(C5, dh(Er , Si ))

C7∥π∥k3 ← hkdf3(C6, psk) ⇄ ← N2 , P2

→ N3 , P3

→ N1 , P1

→ ← T ∥T ← hkdf2(C7, empty) ← → → P1 aenc(T , N1 = 0, P1, empty)

Introduction Protocol Contributions Model Analysis Conclusion

WireGuard’s Main Protocol: Noise IKpsk2 (simpliﬁed)

pub C1 ← hkdf1(C0 = constC, E ) knows Spub, psk knows psk i r priv pub C2∥k1 ← hkdf2(C1, dh(E , S )) Initiator i Responder r i r ← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei ) pub pub pub pub S ← aenc(k , 0, S , H ) , , i  1 i 2 Ei Si  ts ∥ ← priv pub C3 k2 hkdf2(C2, dh(S , Sr )) pub i Er , empty ts ← aenc(k2, 0, timestamp(), H3) ← pub C4 hkdf1(C3, Er ) ← priv pub C5 hkdf1(C4, dh(Er , Ei )) ← priv pub C6 hkdf1(C5, dh(Er , Si ))

C7∥π∥k3 ← hkdf3(C6, psk)

empty ← aenc(k3, 0, empty, H6) ⇄ ← N2 , P2

→ N3 , P3

→ N1 , P1

← → → P1 aenc(T , N1 = 0, P1, empty)

Introduction Protocol Contributions Model Analysis Conclusion

WireGuard’s Main Protocol: Noise IKpsk2 (simpliﬁed)

pub C1 ← hkdf1(C0 = constC, E ) knows Spub, psk knows psk i r priv pub C2∥k1 ← hkdf2(C1, dh(E , S )) Initiator i Responder r i r ← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei ) pub pub pub pub S ← aenc(k , 0, S , H ) , , i  1 i 2 Ei Si  ts ∥ ← priv pub C3 k2 hkdf2(C2, dh(S , Sr )) pub i Er , empty ts ← aenc(k2, 0, timestamp(), H3) ← pub C4 hkdf1(C3, Er ) ← priv pub C5 hkdf1(C4, dh(Er , Ei )) ← priv pub C6 hkdf1(C5, dh(Er , Si ))

C7∥π∥k3 ← hkdf3(C6, psk)

empty ← aenc(k3, 0, empty, H6) → ← T ∥T ← hkdf2(C7, empty) ⇄ ← N2 , P2

→ N3 , P3

Introduction Protocol Contributions Model Analysis Conclusion

WireGuard’s Main Protocol: Noise IKpsk2 (simpliﬁed)

pub C1 ← hkdf1(C0 = constC, E ) knows Spub, psk knows psk i r priv pub C2∥k1 ← hkdf2(C1, dh(E , S )) Initiator i Responder r i r ← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei ) pub pub pub pub S ← aenc(k , 0, S , H ) , , i  1 i 2 Ei Si  ts ∥ ← priv pub C3 k2 hkdf2(C2, dh(S , Sr )) pub i Er , empty ts ← aenc(k2, 0, timestamp(), H3) → ← ( , pub) N1 , P1 C4 hkdf1 C3 Er ← priv pub C5 hkdf1(C4, dh(Er , Ei )) ← priv pub C6 hkdf1(C5, dh(Er , Si ))

C7∥π∥k3 ← hkdf3(C6, psk)

empty ← aenc(k3, 0, empty, H6) → ← T ∥T ← hkdf2(C7, empty) ← → → P1 aenc(T , N1 = 0, P1, empty) Introduction Protocol Contributions Model Analysis Conclusion

WireGuard’s Main Protocol: Noise IKpsk2 (simpliﬁed)

pub C1 ← hkdf1(C0 = constC, E ) knows Spub, psk knows psk i r priv pub C2∥k1 ← hkdf2(C1, dh(E , S )) Initiator i Responder r i r ← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei ) pub pub pub pub S ← aenc(k , 0, S , H ) , , i  1 i 2 Ei Si  ts ∥ ← priv pub C3 k2 hkdf2(C2, dh(S , Sr )) pub i Er , empty ts ← aenc(k2, 0, timestamp(), H3) → ← ( , pub) N1 , P1 C4 hkdf1 C3 Er ← priv pub ⇄ ← C5 hkdf1(C4, dh(Er , Ei )) N , P2 2 ← priv pub C6 hkdf1(C5, dh(Er , Si )) →, N3 P3 C7∥π∥k3 ← hkdf3(C6, psk)

empty ← aenc(k3, 0, empty, H6) → ← T ∥T ← hkdf2(C7, empty) ← → → P1 aenc(T , N1 = 0, P1, empty) 2) mac1 in all handshake messages ← ∥ pub mac1 mac |hash(label{zmac1 Sr }), MAC key

|msg{z α} msg bytes

3) Non-zero mac2 in response to cookie messages: mac ← mac τ, msg 2 | {z β} 16 ..., mac1, mac2 = 0 msg bytes incl. mac1

..., mac1, mac2

Introduction Protocol Contributions Model Analysis Conclusion

WireGuard’s DoS Protection During Handshake (simpliﬁed)

1) timestamp in the ﬁrst message

Initiator i Responder r

3/17 3) Non-zero mac2 in response to cookie messages: mac ← mac τ, msg 2 | {z β}

msg bytes incl. mac1

..., mac1, mac2

Introduction Protocol Contributions Model Analysis Conclusion

WireGuard’s DoS Protection During Handshake (simpliﬁed)

1) timestamp in the ﬁrst message

Initiator i Responder r 2) mac1 in all handshake messages ..., mac , mac = 016 ← ∥ pub 1 2 mac1 mac |hash(label{zmac1 Sr }), MAC key

|msg{z α} msg bytes

3/17 3) Non-zero mac2 in response to cookie messages: mac ← mac τ, msg 2 | {z β}

msg bytes incl. mac1

..., mac1, mac2

Introduction Protocol Contributions Model Analysis Conclusion

WireGuard’s DoS Protection During Handshake (simpliﬁed)

1) timestamp in the ﬁrst message

Initiator i Responder r 2) mac1 in all handshake messages ..., mac , mac = 016 ← ∥ pub 1 2 mac1 mac |hash(label{zmac1 Sr }), τ MAC key

|msg{z α} msg bytes

3/17 Introduction Protocol Contributions Model Analysis Conclusion

WireGuard’s DoS Protection During Handshake (simpliﬁed)

1) timestamp in the ﬁrst message

Initiator i Responder r 2) mac1 in all handshake messages ..., mac , mac = 016 ← ∥ pub 1 2 mac1 mac |hash(label{zmac1 Sr }), τ MAC key

|msg{z α} ..., mac1, mac2 msg bytes

3) Non-zero mac2 in response to cookie messages: mac ← mac τ, msg 2 | {z β}

msg bytes incl. mac1 3/17 Secrecy • Secrecy • Forward secrecy Agreement • Mutual authentication • Session uniqueness • Channel binding • Resistance against key compromise impersonation (KCI) • Resistance against identity mis-binding

Additional properties in WireGuard

• Resistance against denial of service • Identity hiding

Introduction Protocol Contributions Model Analysis Conclusion

Security Goals of WireGuard’s Secure Channel Protocol

Classic key exchange and secure channel properties

4/17 Agreement • Mutual authentication • Session uniqueness • Channel binding • Resistance against key compromise impersonation (KCI) • Resistance against identity mis-binding

Additional properties in WireGuard

• Resistance against denial of service • Identity hiding

Introduction Protocol Contributions Model Analysis Conclusion

Security Goals of WireGuard’s Secure Channel Protocol

Classic key exchange and secure channel properties

Secrecy • Secrecy • Forward secrecy

4/17 • Session uniqueness • Channel binding • Resistance against key compromise impersonation (KCI) • Resistance against identity mis-binding

Additional properties in WireGuard

• Resistance against denial of service • Identity hiding

Introduction Protocol Contributions Model Analysis Conclusion

Security Goals of WireGuard’s Secure Channel Protocol

Classic key exchange and secure channel properties

Secrecy • Secrecy • Forward secrecy Agreement • Mutual authentication

4/17 • Resistance against key compromise impersonation (KCI) • Resistance against identity mis-binding

Additional properties in WireGuard

• Resistance against denial of service • Identity hiding

Introduction Protocol Contributions Model Analysis Conclusion

Security Goals of WireGuard’s Secure Channel Protocol

Classic key exchange and secure channel properties

Secrecy • Secrecy • Forward secrecy Agreement • Mutual authentication • Session uniqueness • Channel binding

4/17 Additional properties in WireGuard

• Resistance against denial of service • Identity hiding

Introduction Protocol Contributions Model Analysis Conclusion

Security Goals of WireGuard’s Secure Channel Protocol

Classic key exchange and secure channel properties

Secrecy • Secrecy • Forward secrecy Agreement • Mutual authentication • Session uniqueness • Channel binding • Resistance against key compromise impersonation (KCI) • Resistance against identity mis-binding

4/17 Introduction Protocol Contributions Model Analysis Conclusion

Security Goals of WireGuard’s Secure Channel Protocol

Classic key exchange and secure channel properties

Additional properties in WireGuard

• Resistance against denial of service • Identity hiding

4/17 • Precise model of the Curve25519 elliptic curve for Diffie-Hellman • Indifferentiability lemmas for chains of random oracle calls (e. g., chains of HMAC or HKDF function calls)

• classic properties of key exchange and secure channels • identity hiding • resistance against denial of service Reusable contributions:

Related work: DowlingPaterson’18, DonenfeldMilner’18 on WireGuard KobeissiNicolasBhargavan’19, Suter-Dörig’18, Girol’19 on IKpsk2

Introduction Protocol Contributions Model Analysis Conclusion

Our Contributions

Mechanised cryptographic proof of WireGuard using CryptoVerif, analysing: • the entire protocol, including transport data messages

5/17 • Precise model of the Curve25519 elliptic curve for Diffie-Hellman • Indifferentiability lemmas for chains of random oracle calls (e. g., chains of HMAC or HKDF function calls)

• identity hiding • resistance against denial of service Reusable contributions:

Related work: DowlingPaterson’18, DonenfeldMilner’18 on WireGuard KobeissiNicolasBhargavan’19, Suter-Dörig’18, Girol’19 on IKpsk2

Introduction Protocol Contributions Model Analysis Conclusion

Our Contributions

Mechanised cryptographic proof of WireGuard using CryptoVerif, analysing: • the entire protocol, including transport data messages • classic properties of key exchange and secure channels

5/17 • Precise model of the Curve25519 elliptic curve for Diffie-Hellman • Indifferentiability lemmas for chains of random oracle calls (e. g., chains of HMAC or HKDF function calls)

Reusable contributions:

Related work: DowlingPaterson’18, DonenfeldMilner’18 on WireGuard KobeissiNicolasBhargavan’19, Suter-Dörig’18, Girol’19 on IKpsk2

Introduction Protocol Contributions Model Analysis Conclusion

Our Contributions

5/17 • Indifferentiability lemmas for chains of random oracle calls (e. g., chains of HMAC or HKDF function calls) Related work: DowlingPaterson’18, DonenfeldMilner’18 on WireGuard KobeissiNicolasBhargavan’19, Suter-Dörig’18, Girol’19 on IKpsk2

Introduction Protocol Contributions Model Analysis Conclusion

Our Contributions

5/17 Related work: DowlingPaterson’18, DonenfeldMilner’18 on WireGuard KobeissiNicolasBhargavan’19, Suter-Dörig’18, Girol’19 on IKpsk2

Introduction Protocol Contributions Model Analysis Conclusion

Our Contributions

5/17 Introduction Protocol Contributions Model Analysis Conclusion

Our Contributions

Mechanised cryptographic proof of WireGuard using CryptoVerif, analysing: • the entire protocol, including transport data messages • classic properties of key exchange and secure channels • identity hiding • resistance against denial of service Reusable contributions: • Precise model of the Curve25519 elliptic curve for Diffie-Hellman • Indifferentiability lemmas for chains of random oracle calls (e. g., chains of HMAC or HKDF function calls) Related work: DowlingPaterson’18, DonenfeldMilner’18 on WireGuard KobeissiNicolasBhargavan’19, Suter-Dörig’18, Girol’19 on IKpsk2 5/17 initial game |→ ·{z · · →} intermediate games →| ·{z · · →} ﬁnal game transformations transformations

security properties easily provable here

• security games in a probabilistic process calculus • generates next game from previous game, given transformation • built-in proof strategy • supports secrecy and correspondence properties • successful termination ⇒ asymptotic security • exact security given by probability bound

Introduction Protocol Contributions Model Analysis Conclusion

The CryptoVerif Automatic Protocol Prover

Proof assistant for game-based cryptographic proofs

6/17 |→ ·{z · · →} intermediate games →| ·{z · · →} ﬁnal game transformations transformations

security properties easily provable here

Introduction Protocol Contributions Model Analysis Conclusion

The CryptoVerif Automatic Protocol Prover

Proof assistant for game-based cryptographic proofs

initial game

6/17 →| ·{z · · →} ﬁnal game transformations

security properties easily provable here

Introduction Protocol Contributions Model Analysis Conclusion

The CryptoVerif Automatic Protocol Prover

Proof assistant for game-based cryptographic proofs

initial game |→ ·{z · · →} intermediate games transformations

6/17 security properties easily provable here

Introduction Protocol Contributions Model Analysis Conclusion

The CryptoVerif Automatic Protocol Prover

Proof assistant for game-based cryptographic proofs

initial game |→ ·{z · · →} intermediate games →| ·{z · · →} ﬁnal game transformations transformations

6/17 • security games in a probabilistic process calculus • generates next game from previous game, given transformation • built-in proof strategy • supports secrecy and correspondence properties • successful termination ⇒ asymptotic security • exact security given by probability bound

Introduction Protocol Contributions Model Analysis Conclusion

The CryptoVerif Automatic Protocol Prover

Proof assistant for game-based cryptographic proofs

initial game |→ ·{z · · →} intermediate games →| ·{z · · →} ﬁnal game transformations transformations

security properties easily provable here

6/17 • built-in proof strategy • supports secrecy and correspondence properties • successful termination ⇒ asymptotic security • exact security given by probability bound

Introduction Protocol Contributions Model Analysis Conclusion

The CryptoVerif Automatic Protocol Prover

Proof assistant for game-based cryptographic proofs

initial game |→ ·{z · · →} intermediate games →| ·{z · · →} ﬁnal game transformations transformations

security properties easily provable here

• security games in a probabilistic process calculus • generates next game from previous game, given transformation

6/17 • successful termination ⇒ asymptotic security • exact security given by probability bound

Introduction Protocol Contributions Model Analysis Conclusion

The CryptoVerif Automatic Protocol Prover

Proof assistant for game-based cryptographic proofs

initial game |→ ·{z · · →} intermediate games →| ·{z · · →} ﬁnal game transformations transformations

security properties easily provable here

• security games in a probabilistic process calculus • generates next game from previous game, given transformation • built-in proof strategy • supports secrecy and correspondence properties

6/17 Introduction Protocol Contributions Model Analysis Conclusion

The CryptoVerif Automatic Protocol Prover

Proof assistant for game-based cryptographic proofs

initial game |→ ·{z · · →} intermediate games →| ·{z · · →} ﬁnal game transformations transformations

security properties easily provable here

6/17 • IND-CPA- and INT-CTXT-secure • for identity hiding: preserves secrecy of associated data

• Gap Diffie-Hellman in the appropriate subgroup

• random oracle • the ChaCha20Poly1305 AEAD

• Curve25519 Diffie-Hellman

Introduction Protocol Contributions Model Analysis Conclusion

Cryptographic Assumptions

• the BLAKE2s hash function (in hash, hkdf, mac)

7/17 • IND-CPA- and INT-CTXT-secure • for identity hiding: preserves secrecy of associated data

• Gap Diffie-Hellman in the appropriate subgroup

• the ChaCha20Poly1305 AEAD

• Curve25519 Diffie-Hellman

Introduction Protocol Contributions Model Analysis Conclusion

Cryptographic Assumptions

• the BLAKE2s hash function (in hash, hkdf, mac) • random oracle

7/17 • Gap Diffie-Hellman in the appropriate subgroup

• IND-CPA- and INT-CTXT-secure • for identity hiding: preserves secrecy of associated data • Curve25519 Diffie-Hellman

Introduction Protocol Contributions Model Analysis Conclusion

Cryptographic Assumptions

• the BLAKE2s hash function (in hash, hkdf, mac) • random oracle • the ChaCha20Poly1305 AEAD

7/17 • Gap Diffie-Hellman in the appropriate subgroup

• for identity hiding: preserves secrecy of associated data • Curve25519 Diffie-Hellman

Introduction Protocol Contributions Model Analysis Conclusion

Cryptographic Assumptions

• the BLAKE2s hash function (in hash, hkdf, mac) • random oracle • the ChaCha20Poly1305 AEAD • IND-CPA- and INT-CTXT-secure

7/17 • Gap Diffie-Hellman in the appropriate subgroup

• Curve25519 Diffie-Hellman

Introduction Protocol Contributions Model Analysis Conclusion

Cryptographic Assumptions

• the BLAKE2s hash function (in hash, hkdf, mac) • random oracle • the ChaCha20Poly1305 AEAD • IND-CPA- and INT-CTXT-secure • for identity hiding: preserves secrecy of associated data

7/17 • Gap Diffie-Hellman in the appropriate subgroup

Introduction Protocol Contributions Model Analysis Conclusion

Cryptographic Assumptions

• the BLAKE2s hash function (in hash, hkdf, mac) • random oracle • the ChaCha20Poly1305 AEAD • IND-CPA- and INT-CTXT-secure • for identity hiding: preserves secrecy of associated data • Curve25519 Diffie-Hellman

7/17 Introduction Protocol Contributions Model Analysis Conclusion

Cryptographic Assumptions

7/17 • a session is clean if it’s not trivially broken i. e. if not all secrets of one party are compromised

• two explicit honest parties i and r • adversary plays all other honest and dishonest parties • polynomial number of sessions • polynomial number of transport data messages in a session • prove security properties for clean sessions between i and r

Introduction Protocol Contributions Model Analysis Conclusion

Model of Environment and Corruption

• any number of available parties (i. e., static key pairs)

8/17 • a session is clean if it’s not trivially broken i. e. if not all secrets of one party are compromised

• adversary plays all other honest and dishonest parties • polynomial number of sessions • polynomial number of transport data messages in a session • prove security properties for clean sessions between i and r

Introduction Protocol Contributions Model Analysis Conclusion

Model of Environment and Corruption

• any number of available parties (i. e., static key pairs) • two explicit honest parties i and r

8/17 • a session is clean if it’s not trivially broken i. e. if not all secrets of one party are compromised

• polynomial number of sessions • polynomial number of transport data messages in a session • prove security properties for clean sessions between i and r

Introduction Protocol Contributions Model Analysis Conclusion

Model of Environment and Corruption

• any number of available parties (i. e., static key pairs) • two explicit honest parties i and r • adversary plays all other honest and dishonest parties

8/17 • a session is clean if it’s not trivially broken i. e. if not all secrets of one party are compromised

• prove security properties for clean sessions between i and r

Introduction Protocol Contributions Model Analysis Conclusion

Model of Environment and Corruption

8/17 • a session is clean if it’s not trivially broken i. e. if not all secrets of one party are compromised

Introduction Protocol Contributions Model Analysis Conclusion

Model of Environment and Corruption

• any number of available parties (i. e., static key pairs) • two explicit honest parties i and r • adversary plays all other honest and dishonest parties • polynomial number of sessions • polynomial number of transport data messages in a session • prove security properties for clean sessions between i and r

8/17 Introduction Protocol Contributions Model Analysis Conclusion

Model of Environment and Corruption

8/17 Reminder: a random oracle returns • a fresh random value on new input • the same value than before on previously seen input Mechanised analysis has to treat all cases of collision ⇒ CryptoVerif creates nested branches for hkdf inputs

(remember: 8 dependent random oracle calls with inputs v0,..., v7)

== v0[i] == v0[j] == v0[k] == v1[i] == v1[j] == v1[k] == v2[i] == v2[j] == v2[k] == v3[i] == v3[j] == v3[k] v0 == v4[i] v1 == v4[j] v2 == v4[k] ··· == v5[i] == v5[j] == v5[k] == v6[i] == v6[j] == v6[k] == v7[i] == v7[j] == v7[k] else else else

Introduction Protocol Contributions Model Analysis Conclusion

The Random Oracle in the Key Derivation

9/17 • a fresh random value on new input • the same value than before on previously seen input Mechanised analysis has to treat all cases of collision ⇒ CryptoVerif creates nested branches for hkdf inputs

(remember: 8 dependent random oracle calls with inputs v0,..., v7)

Introduction Protocol Contributions Model Analysis Conclusion

The Random Oracle in the Key Derivation

Reminder: a random oracle returns

9/17 • the same value than before on previously seen input Mechanised analysis has to treat all cases of collision ⇒ CryptoVerif creates nested branches for hkdf inputs

(remember: 8 dependent random oracle calls with inputs v0,..., v7)

Introduction Protocol Contributions Model Analysis Conclusion

The Random Oracle in the Key Derivation

Reminder: a random oracle returns • a fresh random value on new input

9/17 Mechanised analysis has to treat all cases of collision ⇒ CryptoVerif creates nested branches for hkdf inputs

(remember: 8 dependent random oracle calls with inputs v0,..., v7)

Introduction Protocol Contributions Model Analysis Conclusion

The Random Oracle in the Key Derivation

Reminder: a random oracle returns • a fresh random value on new input • the same value than before on previously seen input

9/17 ⇒ CryptoVerif creates nested branches for hkdf inputs

(remember: 8 dependent random oracle calls with inputs v0,..., v7)

Introduction Protocol Contributions Model Analysis Conclusion

The Random Oracle in the Key Derivation

Reminder: a random oracle returns • a fresh random value on new input • the same value than before on previously seen input Mechanised analysis has to treat all cases of collision

9/17 (remember: 8 dependent random oracle calls with inputs v0,..., v7)

Introduction Protocol Contributions Model Analysis Conclusion

The Random Oracle in the Key Derivation

Reminder: a random oracle returns • a fresh random value on new input • the same value than before on previously seen input Mechanised analysis has to treat all cases of collision ⇒ CryptoVerif creates nested branches for hkdf inputs

9/17 == v0[i] == v0[j] == v0[k] == v1[i] == v1[j] == v1[k] == v2[i] == v2[j] == v2[k] == v3[i] == v3[j] == v3[k] v0 == v4[i] v1 == v4[j] v2 == v4[k] ··· == v5[i] == v5[j] == v5[k] == v6[i] == v6[j] == v6[k] == v7[i] == v7[j] == v7[k] else else else

Introduction Protocol Contributions Model Analysis Conclusion

The Random Oracle in the Key Derivation

(remember: 8 dependent random oracle calls with inputs v0,..., v7)

9/17 == v0[j] == v0[k] == v1[j] == v1[k] == v2[j] == v2[k] == v3[j] == v3[k] v1 == v4[j] v2 == v4[k] ··· == v5[j] == v5[k] == v6[j] == v6[k] == v7[j] == v7[k] else else

Introduction Protocol Contributions Model Analysis Conclusion

The Random Oracle in the Key Derivation

(remember: 8 dependent random oracle calls with inputs v0,..., v7)

== v0[i] == v1[i] == v2[i] == v3[i] v0 == v4[i] == v5[i] == v6[i] == v7[i] else 9/17 == v0[k] == v1[k] == v2[k] == v3[k] v2 == v4[k] ··· == v5[k] == v6[k] == v7[k] else

Introduction Protocol Contributions Model Analysis Conclusion

The Random Oracle in the Key Derivation

(remember: 8 dependent random oracle calls with inputs v0,..., v7)

== v0[i] == v0[j] == v1[i] == v1[j] == v2[i] == v2[j] == v3[i] == v3[j] v0 == v4[i] v1 == v4[j] == v5[i] == v5[j] == v6[i] == v6[j] == v7[i] == v7[j] else else 9/17 Introduction Protocol Contributions Model Analysis Conclusion

The Random Oracle in the Key Derivation

(remember: 8 dependent random oracle calls with inputs v0,..., v7)

Indifferentiable in any context: (manually proved, some lemmas with CryptoVerif)

3 independent calls to 3 independent random oracles.

k1 ← chain1(v0, v1)

k2 ← chain2(v0, v1, v2) → ← π∥k3∥T ∥T ← chain6(v0, v1, v2, v3, v4, v5, v6)

Introduction Protocol Contributions Model Analysis Conclusion

Simpliﬁcation of the Key Derivation’s HKDF Chain

8 chained calls to one random oracle.

C ← const

C ← hkdf(C, v0)

C∥k1 ← hkdf(C, v1)

C∥k2 ← hkdf(C, v2)

C ← hkdf(C, v3)

C ← hkdf(C, v4)

C ← hkdf(C, v5)

C∥π∥k3 ← hkdf(C, v6) → ← T ∥T ← hkdf(C, ϵ) 10/17 Indifferentiable in any context: (manually proved, some lemmas with CryptoVerif)

Idea: extract only whenever the protocol needs a key

Introduction Protocol Contributions Model Analysis Conclusion

Simpliﬁcation of the Key Derivation’s HKDF Chain

8 chained calls to 3 independent calls to one random oracle. 3 independent random oracles.

C ← const k1 ← chain1(v0, v1)

C ← hkdf(C, v0) k2 ← chain2(v0, v1, v2) → ← C∥k1 ← hkdf(C, v1) π∥k3∥T ∥T ← chain6(v0, v1, v2, v3, v4, v5, v6)

C∥k2 ← hkdf(C, v2)

C ← hkdf(C, v3)

C ← hkdf(C, v4)

C ← hkdf(C, v5)

C∥π∥k3 ← hkdf(C, v6) → ← T ∥T ← hkdf(C, ϵ) 10/17 Indifferentiable in any context: (manually proved, some lemmas with CryptoVerif)

Introduction Protocol Contributions Model Analysis Conclusion

Simpliﬁcation of the Key Derivation’s HKDF Chain

8 chained calls to 3 independent calls to one random oracle. 3 independent random oracles.

C ← const k1 ← chain1(v0, v1)

C ← hkdf(C, v0) k2 ← chain2(v0, v1, v2) → ← C∥k1 ← hkdf(C, v1) π∥k3∥T ∥T ← chain6(v0, v1, v2, v3, v4, v5, v6)

C∥k2 ← hkdf(C, v2)

C ← hkdf(C, v3) Idea: extract only whenever the C ← hkdf(C, v4) protocol needs a key C ← hkdf(C, v5)

C∥π∥k3 ← hkdf(C, v6) → ← T ∥T ← hkdf(C, ϵ) 10/17 Introduction Protocol Contributions Model Analysis Conclusion

Simpliﬁcation of the Key Derivation’s HKDF Chain

Indifferentiable in any context: (manually proved, some lemmas with CryptoVerif)

8 chained calls to 3 independent calls to one random oracle. 3 independent random oracles.

C ← const k1 ← chain1(v0, v1)

C ← hkdf(C, v0) k2 ← chain2(v0, v1, v2) → ← C∥k1 ← hkdf(C, v1) π∥k3∥T ∥T ← chain6(v0, v1, v2, v3, v4, v5, v6)

C∥k2 ← hkdf(C, v2)

C ← hkdf(C, v3) Idea: extract only whenever the C ← hkdf(C, v4) protocol needs a key C ← hkdf(C, v5)

C∥π∥k3 ← hkdf(C, v6) → ← T ∥T ← hkdf(C, ϵ) 10/17 • group of order kq where k = 8 and q large prime,

base point g0 of order q used for honest key generation ′ ′ ′ ′ • twist of curve: group of order k q where k = 4 and q large prime

• could be on curve or twist, and in subgroup generated by g0 or not

• produced by adding a low-order point to a public key • they lead to the same shared secret

• Curve25519 is not a prime order group

• curve points are represented by only the x coordinate • incoming public keys are not veriﬁed

• for each public key in the subgroup, there is a small number of equivalent public keys outside the subgroup

Updated model in the paper’s long version: https://cryptoverif.inria.fr/WireGuard

Introduction Protocol Contributions Model Analysis Conclusion

A Precise Model of Curve25519

11/17 • could be on curve or twist, and in subgroup generated by g0 or not

• produced by adding a low-order point to a public key • they lead to the same shared secret

• group of order kq where k = 8 and q large prime,

base point g0 of order q used for honest key generation ′ ′ ′ ′ • twist of curve: group of order k q where k = 4 and q large prime • curve points are represented by only the x coordinate • incoming public keys are not veriﬁed

• for each public key in the subgroup, there is a small number of equivalent public keys outside the subgroup

Updated model in the paper’s long version: https://cryptoverif.inria.fr/WireGuard

Introduction Protocol Contributions Model Analysis Conclusion

A Precise Model of Curve25519

• Curve25519 is not a prime order group

11/17 • could be on curve or twist, and in subgroup generated by g0 or not

• produced by adding a low-order point to a public key • they lead to the same shared secret

′ ′ ′ ′ • twist of curve: group of order k q where k = 4 and q large prime • curve points are represented by only the x coordinate • incoming public keys are not veriﬁed

• for each public key in the subgroup, there is a small number of equivalent public keys outside the subgroup

Updated model in the paper’s long version: https://cryptoverif.inria.fr/WireGuard

Introduction Protocol Contributions Model Analysis Conclusion

A Precise Model of Curve25519

• Curve25519 is not a prime order group • group of order kq where k = 8 and q large prime,

base point g0 of order q used for honest key generation

11/17 • could be on curve or twist, and in subgroup generated by g0 or not

• produced by adding a low-order point to a public key • they lead to the same shared secret

• curve points are represented by only the x coordinate • incoming public keys are not veriﬁed

• for each public key in the subgroup, there is a small number of equivalent public keys outside the subgroup

Updated model in the paper’s long version: https://cryptoverif.inria.fr/WireGuard

Introduction Protocol Contributions Model Analysis Conclusion

A Precise Model of Curve25519

• Curve25519 is not a prime order group • group of order kq where k = 8 and q large prime,

base point g0 of order q used for honest key generation ′ ′ ′ ′ • twist of curve: group of order k q where k = 4 and q large prime

11/17 • could be on curve or twist, and in subgroup generated by g0 or not

• produced by adding a low-order point to a public key • they lead to the same shared secret

• incoming public keys are not veriﬁed

• for each public key in the subgroup, there is a small number of equivalent public keys outside the subgroup

Updated model in the paper’s long version: https://cryptoverif.inria.fr/WireGuard

Introduction Protocol Contributions Model Analysis Conclusion

A Precise Model of Curve25519

• Curve25519 is not a prime order group • group of order kq where k = 8 and q large prime,

base point g0 of order q used for honest key generation ′ ′ ′ ′ • twist of curve: group of order k q where k = 4 and q large prime • curve points are represented by only the x coordinate

11/17 • could be on curve or twist, and in subgroup generated by g0 or not

• produced by adding a low-order point to a public key • they lead to the same shared secret

• incoming public keys are not veriﬁed

• for each public key in the subgroup, there is a small number of equivalent public keys outside the subgroup

Introduction Protocol Contributions Model Analysis Conclusion

A Precise Model of Curve25519

• Curve25519 is not a prime order group • group of order kq where k = 8 and q large prime,

base point g0 of order q used for honest key generation ′ ′ ′ ′ • twist of curve: group of order k q where k = 4 and q large prime • curve points are represented by only the x coordinate

Updated model in the paper’s long version: https://cryptoverif.inria.fr/WireGuard

11/17 • produced by adding a low-order point to a public key • they lead to the same shared secret

• could be on curve or twist, and in subgroup generated by g0 or not • for each public key in the subgroup, there is a small number of equivalent public keys outside the subgroup

Introduction Protocol Contributions Model Analysis Conclusion

A Precise Model of Curve25519

• Curve25519 is not a prime order group • group of order kq where k = 8 and q large prime,

Updated model in the paper’s long version: https://cryptoverif.inria.fr/WireGuard

11/17 • produced by adding a low-order point to a public key • they lead to the same shared secret

• for each public key in the subgroup, there is a small number of equivalent public keys outside the subgroup

Introduction Protocol Contributions Model Analysis Conclusion

A Precise Model of Curve25519

• Curve25519 is not a prime order group • group of order kq where k = 8 and q large prime,

• could be on curve or twist, and in subgroup generated by g0 or not

Updated model in the paper’s long version: https://cryptoverif.inria.fr/WireGuard

11/17 • produced by adding a low-order point to a public key • they lead to the same shared secret

Introduction Protocol Contributions Model Analysis Conclusion

A Precise Model of Curve25519

• Curve25519 is not a prime order group • group of order kq where k = 8 and q large prime,

• could be on curve or twist, and in subgroup generated by g0 or not • for each public key in the subgroup, there is a small number of equivalent public keys outside the subgroup

Updated model in the paper’s long version: https://cryptoverif.inria.fr/WireGuard

11/17 • they lead to the same shared secret

Introduction Protocol Contributions Model Analysis Conclusion

A Precise Model of Curve25519

• Curve25519 is not a prime order group • group of order kq where k = 8 and q large prime,

• could be on curve or twist, and in subgroup generated by g0 or not • for each public key in the subgroup, there is a small number of equivalent public keys outside the subgroup • produced by adding a low-order point to a public key

Updated model in the paper’s long version: https://cryptoverif.inria.fr/WireGuard

11/17 Introduction Protocol Contributions Model Analysis Conclusion

A Precise Model of Curve25519

• Curve25519 is not a prime order group • group of order kq where k = 8 and q large prime,

Updated model in the paper’s long version: https://cryptoverif.inria.fr/WireGuard

11/17 ′ ′ Sr Si • Let Si, Sr, Ei, Er, and psk be compromised. Adv ′ ̸ ′ ̸ • Adversary constructs Si = Si, Sr = Sr as different but equivalent static keys ⇒ The two sessions derive the same traffic keys but Si Sr are between different parties.

Deﬁnition: Resistance against Identity Mis-Binding Two honest parties deriving the same traffic keys in some sessions • agree on each other’s identities • even if one or both of them have been interacting with a dishonest party or a honest party with compromised keys

Theoretical Attack:

pub pub Mitigation: include static public keys Si and Sr into key derivation

Introduction Protocol Contributions Model Analysis Conclusion

A Theoretical Attack leading to Identity Mis-Binding

12/17 ′ ′ Sr Si • Let Si, Sr, Ei, Er, and psk be compromised. Adv ′ ̸ ′ ̸ • Adversary constructs Si = Si, Sr = Sr as different but equivalent static keys ⇒ The two sessions derive the same traffic keys but Si Sr are between different parties.

Two honest parties deriving the same traffic keys in some sessions • agree on each other’s identities • even if one or both of them have been interacting with a dishonest party or a honest party with compromised keys

Theoretical Attack:

pub pub Mitigation: include static public keys Si and Sr into key derivation

Introduction Protocol Contributions Model Analysis Conclusion

A Theoretical Attack leading to Identity Mis-Binding

Deﬁnition: Resistance against Identity Mis-Binding

• agree on each other’s identities • even if one or both of them have been interacting with a dishonest party or a honest party with compromised keys

Theoretical Attack:

pub pub Mitigation: include static public keys Si and Sr into key derivation

Introduction Protocol Contributions Model Analysis Conclusion

A Theoretical Attack leading to Identity Mis-Binding

Deﬁnition: Resistance against Identity Mis-Binding Two honest parties deriving the same traffic keys in some sessions

• even if one or both of them have been interacting with a dishonest party or a honest party with compromised keys

Theoretical Attack:

pub pub Mitigation: include static public keys Si and Sr into key derivation

Introduction Protocol Contributions Model Analysis Conclusion

A Theoretical Attack leading to Identity Mis-Binding

Deﬁnition: Resistance against Identity Mis-Binding Two honest parties deriving the same traffic keys in some sessions • agree on each other’s identities

Theoretical Attack:

pub pub Mitigation: include static public keys Si and Sr into key derivation

Introduction Protocol Contributions Model Analysis Conclusion

A Theoretical Attack leading to Identity Mis-Binding

pub pub Mitigation: include static public keys Si and Sr into key derivation

Introduction Protocol Contributions Model Analysis Conclusion

A Theoretical Attack leading to Identity Mis-Binding

Theoretical Attack:

12/17 ′ ′ Sr Si Adv ′ ̸ ′ ̸ • Adversary constructs Si = Si, Sr = Sr as different but equivalent static keys ⇒ The two sessions derive the same traffic keys but Si Sr are between different parties.

pub pub Mitigation: include static public keys Si and Sr into key derivation

Introduction Protocol Contributions Model Analysis Conclusion

A Theoretical Attack leading to Identity Mis-Binding

Theoretical Attack:

• Let Si, Sr, Ei, Er, and psk be compromised.

12/17 ′ ′ Sr Si Adv

⇒ The two sessions derive the same traffic keys but Si Sr are between different parties.

pub pub Mitigation: include static public keys Si and Sr into key derivation

Introduction Protocol Contributions Model Analysis Conclusion

A Theoretical Attack leading to Identity Mis-Binding

Theoretical Attack:

• Let Si, Sr, Ei, Er, and psk be compromised. ′ ̸ ′ ̸ • Adversary constructs Si = Si, Sr = Sr as different but equivalent static keys

12/17 ⇒ The two sessions derive the same traffic keys but are between different parties.

pub pub Mitigation: include static public keys Si and Sr into key derivation

Introduction Protocol Contributions Model Analysis Conclusion

A Theoretical Attack leading to Identity Mis-Binding

Theoretical Attack:

′ ′ Sr Si • Let Si, Sr, Ei, Er, and psk be compromised. Adv ′ ̸ ′ ̸ • Adversary constructs Si = Si, Sr = Sr as different but equivalent static keys

Si Sr

12/17 pub pub Mitigation: include static public keys Si and Sr into key derivation

Introduction Protocol Contributions Model Analysis Conclusion

A Theoretical Attack leading to Identity Mis-Binding

Theoretical Attack:

′ ′ Sr Si • Let Si, Sr, Ei, Er, and psk be compromised. Adv ′ ̸ ′ ̸ • Adversary constructs Si = Si, Sr = Sr as different but equivalent static keys ⇒ The two sessions derive the same traffic keys but Si Sr are between different parties.

12/17 Introduction Protocol Contributions Model Analysis Conclusion

A Theoretical Attack leading to Identity Mis-Binding

Theoretical Attack:

pub pub 12/17 Mitigation: include static public keys Si and Sr into key derivation WireGuard values DoS resistance over privacy

pub • knowing a candidate public key SY , adversary can compare ∥ pub mac1 = mac(hash(labelmac1 SY ), msgα) • similar test possible on the encrypted cookie • at least VPN provider’s keys usually public ⇒ the MACs weaken identity hiding properties pub • Si  not forward secret, would require a round-trip more

Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Known Weaknesses

13/17 pub • knowing a candidate public key SY , adversary can compare ∥ pub mac1 = mac(hash(labelmac1 SY ), msgα) • similar test possible on the encrypted cookie • at least VPN provider’s keys usually public ⇒ the MACs weaken identity hiding properties pub • Si  not forward secret, would require a round-trip more

Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Known Weaknesses

WireGuard values DoS resistance over privacy

13/17 • similar test possible on the encrypted cookie • at least VPN provider’s keys usually public ⇒ the MACs weaken identity hiding properties pub • Si  not forward secret, would require a round-trip more

Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Known Weaknesses

WireGuard values DoS resistance over privacy

pub • knowing a candidate public key SY , adversary can compare ∥ pub mac1 = mac(hash(labelmac1 SY ), msgα)

13/17 • at least VPN provider’s keys usually public ⇒ the MACs weaken identity hiding properties pub • Si  not forward secret, would require a round-trip more

Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Known Weaknesses

WireGuard values DoS resistance over privacy

pub • knowing a candidate public key SY , adversary can compare ∥ pub mac1 = mac(hash(labelmac1 SY ), msgα) • similar test possible on the encrypted cookie

13/17 ⇒ the MACs weaken identity hiding properties pub • Si  not forward secret, would require a round-trip more

Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Known Weaknesses

WireGuard values DoS resistance over privacy

13/17 pub • Si  not forward secret, would require a round-trip more

Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Known Weaknesses

WireGuard values DoS resistance over privacy

13/17 Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Known Weaknesses

WireGuard values DoS resistance over privacy

13/17 pub pub • public key SA1 initiating sessions with SB1 pub pub • public key SA2 initiating sessions with SB2

← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei ) pub ← ( , , pub, ) Si  aenc k1 0 Si H2

Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Our Contribution on Noise IKpsk2

14/17 pub pub • public key SA1 initiating sessions with SB1 pub pub • public key SA2 initiating sessions with SB2

← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei )

Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Our Contribution on Noise IKpsk2

pub ← ( , , pub, ) Si  aenc k1 0 Si H2

14/17 pub pub • public key SA1 initiating sessions with SB1 pub pub • public key SA2 initiating sessions with SB2

Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Our Contribution on Noise IKpsk2

← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei ) pub ← ( , , pub, ) Si  aenc k1 0 Si H2

14/17 pub pub • public key SA1 initiating sessions with SB1 pub pub • public key SA2 initiating sessions with SB2

⇒ AEAD needs to preserve AD secrecy • We prove: pub pub pub pub knowing SA1 , SA2 , SB1 , SB2 , adversary cannot distinguish

Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Our Contribution on Noise IKpsk2

← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei ) pub ← ( , , pub, ) Si  aenc k1 0 Si H2

pub • Adversary could compare additional data of Si  with ∥ pub ∥ pub hash(hash(constH SY ) Ei )

14/17 pub pub • public key SA1 initiating sessions with SB1 pub pub • public key SA2 initiating sessions with SB2

• We prove: pub pub pub pub knowing SA1 , SA2 , SB1 , SB2 , adversary cannot distinguish

Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Our Contribution on Noise IKpsk2

← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei ) pub ← ( , , pub, ) Si  aenc k1 0 Si H2

pub • Adversary could compare additional data of Si  with ∥ pub ∥ pub hash(hash(constH SY ) Ei ) ⇒ AEAD needs to preserve AD secrecy

14/17 pub pub • public key SA1 initiating sessions with SB1 pub pub • public key SA2 initiating sessions with SB2

Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Our Contribution on Noise IKpsk2

← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei ) pub ← ( , , pub, ) Si  aenc k1 0 Si H2

14/17 Introduction Protocol Contributions Model Analysis Conclusion

Identity Hiding: Our Contribution on Noise IKpsk2

← ∥ pub ∥ pub H2 hash(hash(constH Sr ) Ei ) pub ← ( , , pub, ) Si  aenc k1 0 Si H2

pub • Adversary could compare additional data of Si  with ∥ pub ∥ pub hash(hash(constH SY ) Ei ) ⇒ AEAD needs to preserve AD secrecy • We prove: pub pub pub pub knowing SA1 , SA2 , SB1 , SB2 , adversary cannot distinguish pub pub • public key SA1 initiating sessions with SB1 pub pub • public key SA2 initiating sessions with SB2

14/17 • uses a different Diffie-Hellman assumption (PRF-ODH) • CryptoVerif formally encodes many small steps, separately

Compared to manual proof from DowlingPaterson’18: 11 games

Introduction Protocol Contributions Model Analysis Conclusion

Metrics

Numbers based on the largest variant of our model:

• approx. 1300 lines of model code • 36 proof instructions • 168 games produced by CryptoVerif • 16 minutes runtime on Intel Xeon 3.6 GHz

15/17 • uses a different Diffie-Hellman assumption (PRF-ODH) • CryptoVerif formally encodes many small steps, separately

Introduction Protocol Contributions Model Analysis Conclusion

Metrics

Numbers based on the largest variant of our model:

• approx. 1300 lines of model code • 36 proof instructions • 168 games produced by CryptoVerif • 16 minutes runtime on Intel Xeon 3.6 GHz

Compared to manual proof from DowlingPaterson’18: 11 games

15/17 • CryptoVerif formally encodes many small steps, separately

Introduction Protocol Contributions Model Analysis Conclusion

Metrics

Numbers based on the largest variant of our model:

• approx. 1300 lines of model code • 36 proof instructions • 168 games produced by CryptoVerif • 16 minutes runtime on Intel Xeon 3.6 GHz

Compared to manual proof from DowlingPaterson’18: 11 games

• uses a different Diffie-Hellman assumption (PRF-ODH)

15/17 Introduction Protocol Contributions Model Analysis Conclusion

Metrics

Numbers based on the largest variant of our model:

• approx. 1300 lines of model code • 36 proof instructions • 168 games produced by CryptoVerif • 16 minutes runtime on Intel Xeon 3.6 GHz

Compared to manual proof from DowlingPaterson’18: 11 games

• uses a different Diffie-Hellman assumption (PRF-ODH) • CryptoVerif formally encodes many small steps, separately

15/17 Introduction Protocol Contributions Model Analysis Conclusion

Results Compared to Goals

Classic key exchange and secure channel properties:

Secrecy • Secrecy (by proving message indistinguishability) • Forward secrecy Agreement • Mutual authentication (as of 2nd message) • Session uniqueness • Channel binding • Resistance against key compromise impersonation (KCI) • Resistance against identity mis-binding (except theoretical attack)

Additional properties in WireGuard: • Resistance against denial of service (no replay of 1st msg, cookie enforces round-trip) • Identity hiding (weak) 16/17 Introduction Protocol Contributions Model Analysis Conclusion

Conclusion and Main Take-Aways

• WireGuard protocol is cryptographically safe • weak identity hiding • more context in key derivation prevents theoretical attack • (teaser: and makes proofs easier) • chains of random oracle calls can be reduced to fewer calls • precise model for Curve25519 and Curve448

• detailed comparison to other analyses of WireGuard in our paper’s related work section • the long version and our models with an updated version of Curve25519 are available at: https://cryptoverif.inria.fr/WireGuard

17/17