0% found this document useful (0 votes)
32 views53 pages

PQWire Guard

Uploaded by

sgnwis
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
32 views53 pages

PQWire Guard

Uploaded by

sgnwis
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 53

Post-quantum WireGuard

Andreas Hülsing, Kai-Chun Ning, Peter Schwabe, Florian Weber, Philip


R. Zimmermanna

October 25, 2021

a authors in alphabetic order


WireGuard

• Modern Virtual Private Network (VPN) protocol


• Presented by Donenfeld at NDSS 2017
• Merged into Linux kernel in 2020
• Only ≈4000 lines of code
• Runs over UDP

”Compared to horrors that are OpenVPN and IPSec, WireGuard is a work


of art”
—Linus Torvalds

1
“Cryptographically opinionated”

• No “crypto agility”
• Fixed suite of cryptographic primitives:
• X25519 as Diffie-Hellman routine
• ChaCha20-Poly1305 as AEAD
• Blake2s for hashing and keyed hashing
• HKDF for key derivation

2
“Cryptographically opinionated”

• No “crypto agility”
• Fixed suite of cryptographic primitives:
• X25519 as Diffie-Hellman routine
• ChaCha20-Poly1305 as AEAD
• Blake2s for hashing and keyed hashing
• HKDF for key derivation
• Focus today: the WireGuard handshake
• Authenticate parties to each other
• Establish a session key to encrypt payload data

2
“Cryptographically opinionated”

• No “crypto agility”
• Fixed suite of cryptographic primitives:
• X25519 as Diffie-Hellman routine
• ChaCha20-Poly1305 as AEAD
• Blake2s for hashing and keyed hashing
• HKDF for key derivation
• Focus today: the WireGuard handshake
• Authenticate parties to each other
• Establish a session key to encrypt payload data

2
Diffie-Hellman reminder

Alice Bob

A ← ga B ← gb

K ← Ba = (gb )a = gab K ← Ab = (ga )b = gab

3
Diffie-Hellman reminder

Attacker who can compute x given gx breaks Diffie-Hellman

This is known as Discrete-Logarithm Problem

3
4
“In the past, people have said, maybe it’s 50 years away, it’s a dream,
maybe it’ll happen sometime. I used to think it was 50. Now I’m thinking
like it’s 15 or a little more. It’s within reach. It’s within our lifetime. It’s
going to happen.”
—Mark Ketchen (IBM), Feb. 2012, about quantum computers

5
Post-quantum crypto

Definition
Post-quantum crypto is (asymmetric) crypto that resists attacks using
classical and quantum computers.

6
Post-quantum crypto

Definition
Post-quantum crypto is (asymmetric) crypto that resists attacks using
classical and quantum computers.

5 main directions
• Lattice-based crypto (PKE and Sigs)
• Code-based crypto (mainly PKE)
• Multivariate-based crypto (mainly Sigs)
• Hash-based signatures (only Sigs)
• Isogeny-based crypto (so far, mainly PKE)

6
NISTPQC

Overview tweeted by Jacob Alperin-Sheriff on Dec 4, 2017.

7
State of NIST PQC

• Nov 2017: 69 “complete and proper” submissions

8
State of NIST PQC

• Nov 2017: 69 “complete and proper” submissions


• Jan. 2019: Round-2 announcement planned at RWC

8
State of NIST PQC

• Nov 2017: 69 “complete and proper” submissions


• Jan. 2019: Round-2 announcement planned at RWC
• Feb. 2019: 26 round-2 candidates

8
State of NIST PQC

• Nov 2017: 69 “complete and proper” submissions


• Jan. 2019: Round-2 announcement planned at RWC
• Feb. 2019: 26 round-2 candidates
• Jun. 2020: Round-3 announcement planned

8
State of NIST PQC

• Nov 2017: 69 “complete and proper” submissions


• Jan. 2019: Round-2 announcement planned at RWC
• Feb. 2019: 26 round-2 candidates
• Jun. 2020: Round-3 announcement planned
• Jul. 2020: Round-3 announcement:
• 7 finalists
• 8 alternate schemes

8
What now?

• NIST is expected to announce winners in late 2021


• ≈ one year later get standards

9
What now?

• NIST is expected to announce winners in late 2021


• ≈ one year later get standards
• Replace existing crypto with new crypto

9
What now?

• NIST is expected to announce winners in late 2021


• ≈ one year later get standards
• Replace existing crypto with new crypto

Mission accomplished – The world is safe again!

9
What now?

• NIST is expected to announce winners in late 2021


• ≈ one year later get standards
• Replace existing crypto with new crypto

Mission accomplished – The world is safe again!

. . . or is it?

9
The WireGuard handshake (basic idea: “4DH”)

Initiator has long-term DH key-pair (sski , spki )


Responder has long-term DH key-pair (sskr , spkr )
Initiator Responder

(eski , epki ) ← DH.Gen()


epk
−−−−−−−−−−−−−−−−−−−−−−−−−−i−−−−−−−−−−−−−−−−−−−−−−→

(eskr , epkr ) ← DH.Gen()


epk
←−−−−−−−−−−−−−−−−−−−−−−−−−r−−−−−−−−−−−−−−−−−−−−−−−

k1 ← DH.Shared(eski , spkr ) k2 ← DH.Shared(sskr , epki )


k2 ← DH.Shared(sski , epkr ) k3 ← DH.Shared(eskr , spki )
k3 ← DH.Shared(eski , epkr ) k4 ← DH.Shared(eskr , epki )
k4 ← DH.Shared(sski , spkr ) k1 ← DH.Shared(sskr , spki )

Derive session key from k1 , k2 , k3 , and k4

10
The WireGuard handshake (high-level)
Initiator Responder
1: (eski , epki ) ← DH.Gen()
2:
$
sidi ← {0, 1}32
3: ltk ← AEAD.Enc(κ3 , 0, spki , H3 )
4: now ← Timestamp()
5: time ← AEAD.Enc(κ4 , 0, H4 , now)
6: m1 ← MAC(H(lbl3 ∥ spkr ), type ∥ 03 ∥ sidi ∥ epki ∥ ltk ∥ time)
7: m2 ← MAC(cookie, type ∥ 03 ∥ sidi ∥ epki ∥ ltk ∥ time ∥ m1)
8: InitHello ← type ∥ 03 ∥ sidi ∥ epki ∥ ltk ∥ time ∥ m1 ∥ m2

InitHello
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→

9: (eskr , epkr ) ← DH.Gen()


10:
$
sidr ← {0, 1}32
11: zero ← AEAD.Enc(κ9 , 0, H9 , ∅)
12: m1 ← MAC(H(lbl3 ∥ spki ), type ∥ 03 ∥ sidr ∥ sidi ∥ epkr ∥ zero)
13: m2 ← MAC(cookie, type ∥ 03 ∥ sidr ∥ sidi ∥ epkr ∥ zero ∥ m1)
14: RespHello ← type ∥ 03 ∥ sidr ∥ sidi ∥ epkr ∥ zero ∥ m1 ∥ m2

RespHello
←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

15: tki ← KDF1 (C9 , ∅)


16: tkr ← KDF2 (C9 , ∅)

AEAD.Enc(tki , ·, ∅, application data)


−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ 11
Handshake security

• Key confidentiality
• Entity authentication

12
Handshake security

• Key confidentiality
• Entity authentication
• Key uniqueness
• Identity hiding
• Replay attack resistance
• Unknown key-share (UKS) attack resistance
• DoS attack resistance (early reject)

12
WireGuard security proofs

• Computational: Dowling and Paterson, 2018


• eCK-PFS-PSK
• Assumes additional key-confirmation message
• Missing: key uniqueness, identity hiding, DoS mitigation
• Symbolic: partially by Donenfeld and Milner, 2017
• Missing: perfect forward secrecy, replay attack resistance, DoS
mitigation

13
Post-quantum security of WireGuard

• The optional PSK provides confidentiality against quantum


attacks.
• Assumption: PSK cannot be recovered by quantum attackers
• Post-quantum cryptography: Donenfeld claimed ’not practical for
use here’
• Applebaum, Martindale, Wu, 2019:
• Tweak to WireGuard protocol
• Send H(pk) instead of pk
• Quantum attacker does not easily get pk
• Resistance against mass-surveillance attackers

14
PQ-WireGuard – our goals

• Post-quantum confidentiality and authentication


• NIST security level 3 (≈AES-192)
• Retain all security properties of WireGuard
• Efficient 1-round-trip handshake

15
PQ-WireGuard – our goals

• Post-quantum confidentiality and authentication


• NIST security level 3 (≈AES-192)
• Retain all security properties of WireGuard
• Efficient 1-round-trip handshake
• No fragmentation
• Remember: WireGuard uses UDP
• Lost packets, filtering ⇒ more complex state machine
• Packet-size constraint:
• IPv6 guarantee: no fragmentation of packets ≤ 1280 bytes
• Fit WireGuard messages into 1232 bytes

15
PQ-WireGuard – the idea

1. Replace DH with key-encapsulation mechanisms (KEMs)


2. Instantiate with PQ KEMs achieving desired security

16
Diffie-Hellman

Alice Bob

A ← ga B ← gb

K ← Ba = (gb )a = gab K ← Ab = (ga )b = gab

17
Diffie-Hellman

Alice Bob

A ← ga B ← gb

K ← Ba = (gb )a = gab K ← Ab = (ga )b = gab

17
KEMs: as close as you’ll get to DH

Initiator Responder

(pk, sk) ← KEM.Gen

pk

(ct, K) ← KEM.Enc(pk)

ct

K ← KEM.Dec(ct, sk)

18
KEMs: as close as you’ll get to DH∗

Initiator Responder

(pk, sk) ← KEM.Gen

pk

(ct, K) ← KEM.Enc(pk)

ct

K ← KEM.Dec(ct, sk)

∗ Except with CSIDH (Castryck, Lange, Martindale, Renes, Panny, 2018)

18
What can KEMs (not) do?

Initiator Responder

(eski , epki ) ← DH.Gen()


epk
−−−−−−−−−−−−−−−−−−−−−−−−−−i−−−−−−−−−−−−−−−−−−−−−−→

(eskr , epkr ) ← DH.Gen()


epk
←−−−−−−−−−−−−−−−−−−−−−−−−−r−−−−−−−−−−−−−−−−−−−−−−−

k1 ← DH.Shared(eski , spkr ) k1 ← DH.Shared(sskr , epki )


k2 ← DH.Shared(sski , epkr ) k2 ← DH.Shared(eskr , spki )
k3 ← DH.Shared(eski , epkr ) k3 ← DH.Shared(eskr , epki )
k4 ← DH.Shared(sski , spkr ) k4 ← DH.Shared(sskr , spki )

19
A first approach with KEMs

Initiator Responder

(eski , epki ) ← CPAKEM.Gen()


r1 ← {0, 1}λ , (c1 , k1 ) ← CCAKEM.Enc(spkr , r1 )
$

epk , c1
−−−−−−−−−−−−−−−−−−−−−−−−−i −−−−−−−−−−−−−−−−−−−−−−−→

r2 ← {0, 1}λ , (c2 , k2 ) ← CCAKEM.Enc(spki , r2 )


$

r3 ← {0, 1}λ , (c3 , k3 ) ← CPAKEM.Enc(epki , r3 )


$

c2 , c3
←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

k1 ← CCAKEM.Dec(sskr , c1 )
k2 ← CCAKEM.Dec(sski , c2 )
k3 ← CPAKEM.Dec(eski , c3 )

20
What are we lacking?

DoS resistance
• First initiator message is unauthenticated
• Solution: Use (optional) pre-shared key for early rejects

21
What are we lacking?

DoS resistance
• First initiator message is unauthenticated
• Solution: Use (optional) pre-shared key for early rejects

“MEX” resistance
• Some security also if all RNGs are insecure
• Static-static DH for confidentiality from long-term keys
• Solution: Use “NAXOS trick”

21
What are we lacking?

DoS resistance
• First initiator message is unauthenticated
• Solution: Use (optional) pre-shared key for early rejects

“MEX” resistance
• Some security also if all RNGs are insecure
• Static-static DH for confidentiality from long-term keys
• Solution: Use “NAXOS trick”

UKS-attack resistance
• WireGuard does not hash public keys into session key
• UKS resistance derived from static-static DH
• Solution: Use default PSK as H(spki ⊕ spkr )

21
(Most of) the PQ-WireGuard handshake
Initiator Responder
1: (eski , epki ) ← CPAKEM.Gen()
2: sidi ← {0, 1}32
$

3: ri ← {0, 1}λ
4: (ct1, shk1) ← CCAKEM.Enc(spkr , KDF1 (σi , ri ))
5: ltk ← AEAD.Enc(κ3 , 0, H(spki ), H3 )
6: now ← Timestamp()
7: time ← AEAD.Enc(κ4 , 0, H4 , now)
8: m1 ← MAC(H(lbl3 ∥ spkr ), type ∥ 03 ∥ sidi ∥ epki ∥ ct1 ∥ ltk ∥ time)
9: m2 ← MAC(cookie, type ∥ 03 ∥ sidi ∥ epki ∥ ct1 ∥ ltk ∥ time ∥ m1)
10: InitHello ← type ∥ 03 ∥ sidi ∥ epki ∥ ct1 ∥ ltk ∥ time ∥ m1 ∥ m2
InitHello
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→

11: e, rr ← {0, 1}λ × {0, 1}λ


12: (ct2, shk2) ← CPAKEM.Enc(epki , e)
13: (ct3, shk3) ← CCAKEM.Enc(spki , KDF1 (σr , rr ))
14:
$
sidr ← {0, 1}32
15: zero ← AEAD.Enc(κ9 , 0, H9 , ∅)
16: m1 ← MAC(H(lbl3 ∥ spki ), type ∥ 03 ∥ sidr ∥ sidi ∥ ct2 ∥ ct3 ∥ zero)
17: m2 ← MAC(cookie, type ∥ 03 ∥ sidr ∥ sidi ∥ ct2 ∥ ct3 ∥ zero ∥ m1)
18: RespHello ← type ∥ 03 ∥ sidr ∥ sidi ∥ ct2 ∥ ct3 ∥ zero ∥ m1 ∥ m2
RespHello
←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
22
Adding explicit key confirmation

Initiator Responder
19: conf ← AEAD.Enc(κ10 , 0, H10 , ∅)
20: m1 ← MAC(H(lbl3 ∥ spkr ), type ∥ 03 ∥ sidi ∥ sidr ∥ conf)
21: m2 ← MAC(cookie, type ∥ 03 ∥ sidi ∥ sidr ∥ conf ∥ m1)
22: InitConf ← type ∥ 03 ∥ sidi ∥ sidr ∥ conf ∥ m1 ∥ m2
InitConf
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→

23: tki ← KDF1 (C10 , ∅)


24: tkr ← KDF2 (C10 , ∅)

• Allows proofs to separate handshake from data transmission


• eCK-PFS-PSK proof applies to actual protocol

23
PQ-WireGuard security proofs

• Computational:
• Based on Dowling and Paterson (2018)
• Proof in the eCK-PFS-PSK model
• Standard model proof
• Symbolic:
• Based on Donenfeld and Milner (2017)
• Uses the Tamarin prover
• Cover all desired security properties

24
Instantiation

• Long-term IND-CCA-secure KEM: Classic McEliece


• Smallest ciphertext of all NIST PQC candidates
• Public-key size does not matter
• Key-generation time does not matter

25
Instantiation

• Long-term IND-CCA-secure KEM: Classic McEliece


• Smallest ciphertext of all NIST PQC candidates
• Public-key size does not matter
• Key-generation time does not matter
• Ephemeral IND-CPA-secure KEM requirements:
• NIST PQC round-2 candidate at level 3
• High-speed constant-time implementation
• Pick “conservative” primitives
• No patent claims by submitters
• No tweaks that lower security

25
Instantiation

• Long-term IND-CCA-secure KEM: Classic McEliece


• Smallest ciphertext of all NIST PQC candidates
• Public-key size does not matter
• Key-generation time does not matter
• Ephemeral IND-CPA-secure KEM requirements:
• NIST PQC round-2 candidate at level 3
• High-speed constant-time implementation
• Pick “conservative” primitives
• No patent claims by submitters
• No tweaks that lower security
• Fit into unfragmented IPv6 packet:
• public key of ≤928 bytes
• ciphertext of ≤984 bytes

25
Dagger

• Only three NIST round-2 candidates within size constraints:


• SIKE – not high-speed
• ROLLO – not conservative
• Round5 – patent encumbered

26
Dagger

• Only three NIST round-2 candidates within size constraints:


• SIKE – not high-speed
• ROLLO – not conservative
• Round5 – patent encumbered
• Idea: Tweak lattice-based KEM:
• More public-key and ciphertext compression
• Increase hardness of lattice problems
• Increase failure probability (no issue for CPA sec.)

26
Dagger

• Only three NIST round-2 candidates within size constraints:


• SIKE – not high-speed
• ROLLO – not conservative
• Round5 – patent encumbered
• Idea: Tweak lattice-based KEM:
• More public-key and ciphertext compression
• Increase hardness of lattice problems
• Increase failure probability (no issue for CPA sec.)
• Tweaked (smaller, more lightweight) Saber: Dagger

26
Implementation and Evaluation

• Implement as Linux kernel module


• Use existing high-speed constant-time software for McEliece and
Dagger (Saber)

27
Implementation and Evaluation

• Implement as Linux kernel module


• Use existing high-speed constant-time software for McEliece and
Dagger (Saber)
• Metrics for comparison:
• Amount of traffic
• Number of packets
• Handshake latency

27
Implementation and Evaluation

• Implement as Linux kernel module


• Use existing high-speed constant-time software for McEliece and
Dagger (Saber)
• Metrics for comparison:
• Amount of traffic
• Number of packets
• Handshake latency
• Use virtual 10Gbps Ethernet link between two VMs
• Both IPv4 and IPv6: similar results
• Compare with WireGuard, OpenVPN, IPsec, PQCrypto-VPN

27
Results

Packet Traffic Client Time Server Time


VPN Software
Number (bytes) (milliseconds) (milliseconds)
WireGuard 3 458 0.592 0.480
(0) (0) (0.399) (0.389)
PQ-WireGuard 3 2654 1.015 0.786
(0) (0) (0.618) (0.621)
IPsec 6 4299 17.188 11.912
(RSA-2048) (0) (0) (0.712) (0.535)
IPsec 4 2281 5.226 2.822
(Curve25519) (0) (0) (0.575) (0.436)
OpenVPN 21.003 7955.409 1148.733 1142.650
(RSA-2048) (0.055) (7.319) (250.513) (243.184)
OpenVPN 19.005 5788.610 1139.140 1133.944
(NIST P-256) (0.007) (9.423) (247.659) (240.691)
OpenVPN-NL 19.005 6065.700 1162.649 1151.790
(RSA-2048) (0.072) (9.665) (261.078) (246.363)
OpenVPN-NL 19.001 6061.138 1159.627 1153.949
(NIST P-256) (0.003) (4.304) (252.989) (247.470)
PQ-OpenVPN 63.006 35608.817 1160.922 1155.713
(Frodo-752 [BCD+16]) (0.078) (10.324) (259.246) (245.614)
PQ-OpenVPN 23.005 8996.684 1277.172 1269.074
(SIDHp503 ) (0.072) (9.449) (251.461) (257.427)

28
More online

Paper:
https://cryptojedi.org/papers/#pqwireguard

Code:
https://cryptojedi.org/crypto/#pqwireguard

29

You might also like