Multi-Stage Key Exchange
and the Case of Google’s QUIC Protocol
Marc Fischlin and Felix Günther
Technische Universität Darmstadt, Germany
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 1
Key Exchange
so far. . .
corruption
key reveal
eavesdroppig
active attacks
pkB , skA
pkA , skB
KE
BR ’93
$
???
test
K
BFWW @CCS’11
K
secure composition
Channel
Thanks to Giorgia Azzurra Marson for the drawings.
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 2
But what if. . . ?
pkB , skA
pkA , skB
KE
K1
K1
Channel(K1 )
“multi-stage KE”
K2
K2
Channel(K2 )
...
I
I
I
key exchange establishes more than one key?
. . . even uses the intermediary keys within the key exchange or channel?
not covered by KE models so far
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 3
Should we care?
I
QUIC (“Quick UDP Internet Connections”, Google 2013)
I
I
I
I
I
“low-latency transport protocol with security equivalent to TLS”
Diffie–Hellman-based key agreement
aims at 0-RTT, i.e., immediately encrypts under intermediate key K1
later rekeys to forward-secure K2
intermediate key K1 used to establish K2 (i.e., in KE part)
Client C
knows server’s pkS
ephemeral eskC , epkC
K1 = DH(eskC , pkS )
K2 = DH(eskC , epkS )
Server S
skS
epkC
{data}K1
{epkS }K1
{data}K2
Stage 1
K1 = DH(epkC , skS )
ephemeral eskS , epkS
K2 = DH(epkC , eskS )
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 4
Stage 2
Should we care?
I
QUIC (“Quick UDP Internet Connections”, Google 2013)
I
I
I
I
I
I
“low-latency transport protocol with security equivalent to TLS”
Diffie–Hellman-based key agreement
aims at 0-RTT, i.e., immediately encrypts under intermediate key K1
later rekeys to forward-secure K2
intermediate key K1 used to establish K2 (i.e., in KE part)
TLS with session resumption
I
I
I
I
I
client and server already established session and hold master key
client resumes session later
new session key is derived using (old) master key and fresh nonces
can also be though of as a multi-stage key exchange (keeps state)
related: TLS renegotiation considered as phases (GKS @ CCS’13)
but renegotiation is new key exchange, not reusing the master key
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 4
Model for Multi-Stage Key Exchange
corruption
key Ki reveal
eavesdroppig
pkB , skA
active attacks
pkA , skB
KE
???
K1
$
K1
test Ki
K2
...
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 5
K2
That’s it?
Model for Multi-Stage Key Exchange
Security Aspects to consider
I
(Session-)Key Dependence
I multi-stage ⇒ derived keys might build upon each other
I
we have to disallow trivial reveal queries
ex: QUIC
Client C
ephemeral eskC , epkC
K1 = DH(eskC , pkS )
Server S
epkC
{epkS }K1
K2 = DH(eskC , epkS )
K1 = DH(epkC , skS )
ephemeral eskS , epkS
K2 = DH(epkC , eskS )
disclosure of K1 compromises K2
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 6
Model for Multi-Stage Key Exchange
Security Aspects to consider
I
(Session-)Key Dependence
I multi-stage ⇒ derived keys might build upon each other
I
we have to disallow trivial reveal queries
I
I
key-dependent KE: disclosure of Ki before acceptance of Ki+1 compromises Ki+1
key-independent KE: disclosure of Ki before acceptance of Ki+1 without harm
I
Note: revealing Ki after acceptance of Ki+1 is okay (even with testing Ki+1 )
state of execution
K1
K1
K2
K2
K3
K3
key dependence
reveal K2
key dependence
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 6
Model for Multi-Stage Key Exchange
Security Aspects to consider (cont’d)
I
Forward Security
I multi-stage ⇒ forward security might kick in only at some stage j
I
has to be considered in case of corruptions
I
non-forward-secure KE: all session keys compromised by corruption
stage-j-forward-secure KE: accepted keys at stages i ≥ j remain secure
ex: QUIC aims at stage-2 forward security
I
I
Unilateral Authentication
I
I
I
I
(independent of multi-stage setting)
distinguish one side authenticated vs. both sides authenticated
unilateral authentication: only one side authenticated (here: responder)
mutual authentication: both sides authenticated
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 7
Model for Multi-Stage Key Exchange
Let’s talk about security. . .
Multi-Stage Security
I
Bellare–Rogaway-like key secrecy in the multi-stage setting
I
adversary has to distinguish real from random keys
I
adversary must not reveal and test same key (in single or partnered sessions)
I
Flavors
+
+
key-dependent
non-forward-secure
unilateral authentication
or
or
or
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 8
key-independent
stage-j-forward-secure
mutual authentication
Model for Multi-Stage Key Exchange
Multi-Stage Security Flavors
I
key dependence, forward security, unilateral authentication are orthogonal
I
in principle one can think of any combination
I
combinations form an ordered hierarchy
KD,1-FS,M
KD,M-FS,M
KD,2-FS,M
KD,1-FS,U
KI,NFS,U
KI,M-FS,U
KI,2-FS,U
KI,1-FS,U
KI,NFS,M
KI,M-FS,M
KI,2-FS,M
KI,1-FS,M
KD,2-FS,U
KD,NFS,M
KD,M-FS,U
KD,NFS,U
key-dependent (KD), stage-2-forward-secure (2-FS), unilateral authentication (U)
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 9
Model for Multi-Stage Key Exchange
pkB , skA
pkA , skB
KE
???
K1
K1
K2
K2
$
Channel
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 10
What about composition?
Composition
recap: BR-secure KE + symmetric-key protocol = secure composition (BFWW’11)
can we have the same for multi-stage key exchange?
Goal
I
secure multi-stage key exchange
(with some properties. . . )
I
+ symmetric-key protocol using keys of stage i
I
= secure composition
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 11
Composition
Our Composition Result
Take
I
secure multi-stage key exchange protocol
I
I
I
I
I
key-independent
stage-j-forward-secure
mutual authentication (extension to unilateral case possible)
efficient session matching (BFWW’11)
symmetric-key protocol
I
secure w.r.t. some security notion
session partnering deducible
from adversary communication
Then composition is secure for forward-secure stages (i ≥ j).
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 12
Composition
Proof idea (similar to BR-secure composition)
protocol1 ($)
1. key replacement
I
I
protocol2 ($)
gradually replace session keys Ki by random values (hybrid)
A distinguishes ⇒ we break Multi-Stage security
...
protocolλ ($)
protocolλ+1 (K)
...
2. reduction to protocol security
I all keys random ⇒ independent of KE
I
breaking is equivalent to breaking protocol security directly
composition
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 13
protocol
Composition
Proof ingredient example: key independence
I
guarantees that compromising (reveal) Ki 0 (i 0 < i) doesn’t affect stage-i keys
I
otherwise replacing Ki with random key can be inconsistent
...
reveal Ki 0
...
Ki 0
Ki 0
Ki
$
key dependence
hybrid proof step
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 14
Google’s Quick UDP Internet Connections
UDP (+ handling)
Client C
knows server’s pkS
ephemeral eskC , epkC
K1 = KDF (DH(n, eskC , pkS ))
K2 = KDF (DH(n, eskC , epkS ))
public scfg
(certified)
inchoate hello
scfg, [nonceS ]
strike
register
Server S
skS
KE
nonceC , epkC
{data}K1
{epkS }K1
{data}K2
K1 = KDF (DH(n, epkC , skS ))
ephemeral eskS , epkS
K2 = KDF (DH(n, epkC , eskS ))
AEAD: AES-GCM, Salsa20/Poly1305
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 15
Google’s QUIC
Client C
ephemeral eskC , epkC
K1 = KDF (DH(n, eskC , pkS ))
Server S
nonceC , epkC
{epkS }K1
K2 = KDF (DH(n, eskC , epkS ))
K1 = KDF (DH(n, epkC , skS ))
ephemeral eskS , epkS
K2 = KDF (DH(n, epkC , eskS ))
Our (Multi-Stage) Security Result for QUIC’s 0-RTT Key Exchange
I
key-dependent
I
stage-2-forward-secure
I
(responder-authenticated) unilateral
assuming
I
I
I
Gap-Diffie-Hellman is hard
authenticated channel for 2nd message {epkS }K1
(HMAC-based) key derivation function: extraction, expansion = random oracles
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 16
Google’s QUIC
What about Composition?
I
requirements:
I
I
I
key independence
stage-j forward security
mutual authentication
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 17
Google’s QUIC
What about Composition?
I
what QUIC achieves:
I
I
I
I
7
3
(3)
but QUIC can be easily turned into a key-independent variant QUICi:
I
I
I
key independence
stage-2 forward security
unilateral authentication
TLS-like idea: keep some (master) secret not exposed in Reveals
let an additional secret value from KDF in stage 1 enter KDF in stage 2
QUICi + composition result ⇒ (forward-)secure channels from stage 2
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 17
Summary
So far, KE models could not capture protocols that establish more than one key.
We
I
I
I
propose a model for multi-stage key exchange
give composition results under certain conditions
(session-key independence matters!)
show that Google’s QUIC is multi-stage secure
(key-dependent, stage-2-forward-secure, unilateral)
for our composition: add key-independence
Thank You!
November 6th, 2014 | ACM CCS 2014, Scottsdale, Arizona, USA | Felix Günther (TU Darmstadt) | 18
K1
K1
K2
K2
K3
K3
composition
Client C
ephemeral eskC , epkC
K1 = DH(eskC , pkS )
protocol
Server S
epkC
{epkS }K1
K2 = DH(eskC , epkS )
Reveal
K1 = DH(epkC , skS )
ephemeral eskS , epkS
K2 = DH(epkC , eskS )