1. business and industrial
2. company
3. bankruptcy

Modul
Kryptographische Protokolle
Chapter 1: Preliminaries and Definitions
Chapter 2: AKE Protocols: The Extended Bellare-Rogaway Model
Chapter 3: Transport Layer Security
Chapter 4: The ACCE Security Model
Chapter 5: TLS with Ephemeral Diffie-Hellman is a Secure ACCE
Protocol
Chapter 6: Signed Diffie-Hellman SSH is a secure server-only ACCE
protocol
Chapter 7: 2-Message Protocols: HMQV
Autor:
Prof. Dr. Jörg Schwenk
1. Auflage
Ruhr - Universität Bochum
© 2015 Jörg Schwenk
Ruhr - Universität Bochum
Universitätsstraße 150
44801 Bochum
1. Auflage (4. März 2015)
Didaktische und redaktionelle Bearbeitung:
Das Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwendung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung
der Verfasser unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen,
Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in
elektronischen Systemen.
Um die Lesbarkeit zu vereinfachen, wird auf die zusätzliche Formulierung der weiblichen Form bei Personenbezeichnungen verzichtet. Wir weisen deshalb darauf hin,
dass die Verwendung der männlichen Form explizit als geschlechtsunabhängig verstanden werden soll.
Inhaltsverzeichnis
Seite 3
Inhaltsverzeichnis
Einleitung zu den Studienbriefen
I.
Abkürzungen der Randsymbole und Farbkodierungen . . . . . . . . . . . . . . . . . . . . . . . . . .
II. Zu den Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III. Modullehrziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
6
7
Chapter 1
Preliminaries and Definitions
1.1 Alan Turing: On computable numbers, with an application to the Entscheidungsproblem (1937)
1.1.1 Turing Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Complexity Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Efficiently Decideable Languages: The class P . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Efficiently Verifiable Languages: The class NP . . . . . . . . . . . . . . . . . . . . . .
1.2.3 Polynomial Time Reductions and NP-Completeness . . . . . . . . . . . . . . . . . . .
1.3 Cryptographic Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Collision-resistant hash functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2 Digital Signature Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3 Pseudo-Random Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.4 Message Authentication Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.5 Stateful Length-Hiding Authenticated Encryption . . . . . . . . . . . . . . . . . . . . .
1.3.6 Buffered stateful authenticated encryption . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Complexity Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1 The Decisional Diffie-Hellman Assumption . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2 The PRF-Oracle-Diffie-Hellman Assumption . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
11
12
12
13
14
14
14
15
16
16
17
18
18
19
Chapter 2
AKE Protocols: The Extended Bellare-Rogaway Model
2.1 Execution Environment . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Adversarial Model . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Security Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Basic AKE Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Mutual Authentication Protocol 1 (MAP1) . . . . . . . . . . .
2.4.2 Authenticated Key Exchange Protocol 1 (AKEP1) . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
21
22
26
26
29
Chapter 3
Transport Layer Security
3.1 Description of TLS handshake messages . . . . . . . . . . . . . . . . . .
3.2 Truncated TLS with Ephemeral Diffie-Hellman is a Secure AKE Protocol
3.2.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Indistinguishability of Keys . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
34
38
39
45
Chapter 4
The ACCE Security Model
4.1 Execution environment . . . . . . . . . . . . . . . . .
4.2 Security Definition . . . . . . . . . . . . . . . . . . .
4.3 Relation to the AKE Security Definition from Section 2
4.4 Choosing the Right Model . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
49
50
51
52
Chapter 5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TLS with Ephemeral Diffie-Hellman is a Secure ACCE Protocol
Chapter 6
Signed Diffie-Hellman SSH is a secure server-only ACCE protocol
6.1 Protocol description for SSH signed-Diffie–Hellman ciphersuite . . . . . . . . . . .
6.1.1 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2 Signed-DH sub-protocol—all authentication modes . . . . . . . . . . . . . .
6.1.3 Sub-protocol—no client authentication . . . . . . . . . . . . . . . . . . . .
6.1.4 Sub-protocol—password client authentication . . . . . . . . . . . . . . . . .
6.1.5 Sub-protocol—public-key client authentication . . . . . . . . . . . . . . . .
6.2 Challenges with security proofs for SSH . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Server-only-authentication mode . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
64
64
65
66
66
67
68
70
Seite 4
6.4
Inhaltsverzeichnis
Mutual authentication mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 7
2-Message Protocols: HMQV
Verzeichnisse
I.
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
II. Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III. Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
75
77
77
77
77
Einleitung zu den Studienbriefen
Seite 5
Einleitung zu den Studienbriefen
I. Abkürzungen der Randsymbole und Farbkodierungen
Axiom
A
Beispiel
B
Definition
D
Exkurs
E
Kontrollaufgabe
K
Merksatz
M
Quelle
Q
Satz
S
Übung
Ü
Seite 6
Einleitung zu den Studienbriefen
II. Zu den Autoren
Prof. Jörg Schwenk leitet den Lehrstuhl Netz- und Datensicherheit an der Ruhr-Uni Bochum seit dem Jahr 2003. Von 1993 bis 2001 arbeitete er im Bereich Sicherheit der Deutschen Telekom in verschiedenen Industrieprojekten. Anschließend lehrte er zwei Jahre
lang an der Georg-Simon-Ohm FH Nürnberg. Er hat mehr als 60 Patente und mehr als
40 wissenschaftliche Publikationen verfasst. Seine Forschungsinteressen umfassen kryptographische Protokolle (SSL/TLS, IPSec), XML- und Webservice-Security, sowie Webund Internetsicherheit.
Modullehrziele
Seite 7
III. Modullehrziele
Die Studierenden verstehen die Besonderheit kryptographischer Protokolle, bei denen nicht mehr ein Algorithmus
im Vordergrund steht, sondern die Interaktion verschiedener Einheiten. Die Studenten erkennen die praktische Relevanz der Kryptographie und begreifen die Schwierigkeit, kryptographische Protokolle - wie sie im Internet eingesetzt
werden - formal auf ihre Sicherheit hin zu analysieren. Die Studenten kennen wichtige Sicherheitsziele und Sicherheitsmodelle, welche sie auf echte Protokolle anwenden können.
Chapter 1 Preliminaries and Definitions
Seite 9
Chapter 1 Preliminaries and Definitions
In this section, we recall the definitions that will be used in the sequel. We denote with
∅ the empty string, and with [n] = {1, . . . , n} ⊂ N the set of integers between 1 and
$
n. Given a bitstring x ∈ {0, 1}∗ we denote by |x| its length. If A is a set, then a ← A
denotes the action of sampling a uniformly random element from A. If A is a probabilistic
$
algorithm, then a ← A denotes that A is run with fresh random coins and returns a.
Definition 1.1
D
A function f : N → R+ is called negligible if for every polynomial p(λ) and all
1
sufficiently great λ holds that f (λ) < p(λ)
1.1 Alan Turing: On computable numbers, with an application
to the Entscheidungsproblem (1937)
In 1937 a young mathematician named Alan Turing published an article about computability [Tur37]. No computers existed at that point of time (Turing was to build one of
the first in Bletchley Park during WW II), but the problem was already famous and wellknow in the mathematical community: Which functions can be computed by constructive
means, i.e. by some kind of algorithm?
1.1.1 Turing Machines
To answer this question, first the term “algorithms” had to be defined in a mathematically
precise way. Turing achieved this through the definition of a construct that is now called
a Turing Machine (TM) (see Definition 1.2).
Turing observed himself while doing computations on a sheet of squared paper: He read
symbols written on the paper, applied some short mental operations (e.g. multiplying or
adding single numbers) to them, and wrote the results back to the paper.
Example 1. The prototype of such operations is manual multiplication or division of large
integer numbers. Here the human performs a finite set of elementary operations in his
mind (e.g. multiplying two integer numbers from the set {0, ..., 9} (“Kleines Einmaleins”),
and writes intermediate results on the paper. Later he adds columns of numbers, another
elementary operation.
6
·
2
2
4 2
4
1 2
5 2
By changing the elementary operations, the algorithm can be ported to other domains,
e.g. binary numbers or polynomial multiplication/division.
Seite 10
D
Chapter 1 Preliminaries and Definitions
Definition 1.2
A Turing Machine M is a tuple M = (Q, Γ, β, Σ, δ, q0 , F ), where
Q is a finite, non-empty set of states,
Γ is the tape alphabet,
β ∈ Γ is the blank symbol,
Σ ⊆ Γ\{β} is the input alphabet,
q0 ∈ Q is the initial state,
F ⊆ Q is the set of final or accepting states and
δ : (Q\F ) × Γ → Q × Γ × {L, R} is a partial function called the transition
function.
A Turing machine is started by setting its internal state to q0 , writing the input string
on the (infinite) tape, and positioning its read/write head on the first input symbol.
As long as no accepting state is reached, δ(s, q) = (s0 , q 0 , m) is evaluated, where s
is the actual state of the TM, and q is the symbol read by the read/write head from
the tape. As a result of this evaluation of δ, the internal state of M is set to s0 , the
symbol q 0 is written on the tape by overwriting q, and the read/write head either
moves right (m = R) or left (m = L).
Turing then simplified his observations into a purely mathematical model:
• Instead of the two-dimensional array of squared paper (“kariertes Papier”), he used
a one-dimensional tape with cells which may contain exactly one symbol from the
tape alphabet Γ. This tape is infinitely long in both directions.
• Instead of the human brain he used a finite state automaton. This is a set Q of
different states (shown as octagons in Figure 1.1) and a partial function called
transition function.
• The finite state automaton may read and overwrite symbols on the tape. This is
similar to a mathematician working with pencil and eraser.
Let’s exemplify the execution of a Turing machine with the example from Figure 1.1.
Here the read head is on the token “i”. So the automaton is in the corresponding state
“q0” and makes a transition to state “q9” by replacing the read-in token with an “i” (so
the written token is the same as the read-in token and there is no visible effect) and
the read/write-head moves one position to the right. This can shortly be described by
δ(q0, i) = (q9, i, R).
The configuration or snapshot of a Turing Machine is a description of the status of a
computation at a certain step. It contains
1. the contents of the tape,
2. the position of the read/write head,
3. and the current state of the finite automaton.
1.2 Complexity Theory
Seite 11
Figure 1.1: Turing Machine.
(if; if,R) q0 q9 (ý;ý,R) (f;f,R) (☐;☐,R) q1 (o;o,R) q2 ... β f o r ☐ i = 0 ☐ t f1 q3 (r;r,R) o ☐ 1 7 ☐ d o β β β ... A step of a Turing Machine M is defined as reading the contents of the tape, evaluating δ
with respect to the current state and content of the cell, overwriting the content of the cell
and moving the read/write head.
Definition 1.3
D
Let M be a Turing Machine and let T : N → N be a function. We say that M has
running time T if for all x ∈ {0, 1}∗ it holds that M , starting in state q0 on input x,
finally reaches a state q 0 ∈ F after at most T (|x|) steps. If f : {0, 1}∗ → {0, 1}∗ ,
we say that M computes f in time T if M runs in time T and, when x is the content
of the input tape, outputs f (x).
1.2 Complexity Theory
Definition 1.4
A language L is a subset of Σ∗ .
An example is the language LDDH = {g a , g b , g ab } = {g a , g b , g c |g c = g ab } where g
$
is a generator of a group G of order p and a, b, c ← Zp . This particular language plays
an important role in cryptography. The related Diffie-Hellman assumption is defined in
Definition 1.14
D
Seite 12
Chapter 1 Preliminaries and Definitions
1.2.1 Efficiently Decideable Languages: The class P
Let L ⊆ {0, 1}∗ be a language. We associate a function fL with L as follows:
(
1, if x ∈ L
fL (x) =
0, if x ∈
/L
In words, fL evaluates to 1 on input x whenever x ∈ L and to 0 otherwise.
Let t : N → N. The class DTIME(t) consists of all languages L such that there exists a
turing machine ML that computes fL according to Definition 1.3 in time O(t).
D
Definition 1.5
DTIME(t) := {L ⊆ {0, 1}∗ s.t. it exists ML that computes fL in time O(t)}
The complexity class P contains all languages that are decidable in polynomial time:
D
Definition 1.6
S
P = i∈N DTIME(ni ).
Remark 1. Note that here n is the length of the input and i is an arbitrary fixed positive
integer. The class P includes all languages where membership can be determined (accepted) in time polynomial to the input length. An example is the language PRIME, which
contains all prime integers.
1.2.2 Efficiently Verifiable Languages: The class NP
In this section we define another very important complexity class, NP. NP is an abbreviation for non-deterministic polynomial time (in contrast to P - polynomial time).
Informally, NP is the set of all Languages where a proof of membership can be checked
by Turing Machines with running time bounded by O(ni ) for some i ∈ N.
D
Definition 1.7
A language L ⊆ {0, 1}∗ is in NP if there exists a polynomial p : N → N and a
polynomialtime Turing machine M such that for every x ∈ {0, 1}∗ it holds that
x ∈ L ⇔ ∃ u ∈ {0, 1}p(|x|) s.t. M (x, u) = 1
One of the big questions in Complexity Theory today is if P = NP. It is assumend that
this is not the case. Namely, it is assumed that there are problems which are in NP but not
in P . The relation between these two classes can be seen in Figure 1.2.
1.2 Complexity Theory
Seite 13
Figure 1.2: Relation
between classes P and
NP.
1.2.3 Polynomial Time Reductions and NP-Completeness
It turns out that some languages, e.g. 3-SAT, that are contained in the complexity class NP
are as hard to decide as any other language in NP up to a polynomially bounded overhead.
Stated otherwise, if 3-SAT is contained in P then so is any other language in NP. In the
sequel we will formalize this.
Definition 1.8
A language L ⊆ {0, 1}∗ is polynomial-time reducible to a language L0 ⊆ {0, 1}∗ if
it exists a polynomial-time computable function f : {0, 1}∗ → {0, 1}∗ such that for
every x ∈ {0, 1}∗ it holds that x ∈ L ⇔ f (x) ∈ L0 . In this case, we say L ≤p L0 .
D
Obviously, given some languages L and L0 such that L ≤p L0 , then L0 ∈ P ⇒ L ∈ P .
Next, we define NP-hardness, and NP-completeness.
Definition 1.9
We say that L0 is NP-hard if L ≤p L0 for every L ∈ NP. We say that L0 is NPcomplete if L0 is NP-hard and L0 ∈ NP.
Some problems (like Travelling Salesman, SAT, 3-SAT) in NP are known to be NPcomplete. There are very few problems in NP which are related to daily life (GRAPHISO). There also exist the classes of P, which we already discussed and CO-NP, which is
an overlapping set of NP. The interesection of CO-NP and NP are problems on which
todays cryptography is based. This is illustrated in Figure 1.3.
It holds the following Theorem regarding polynomial-time reducibility.
Theorem 1.
1. If L ≤p L0 and L0 ≤p L00 , then L ≤p L00 .
2. If language L is NP-hard and L ∈ P then P = NP.
D
Seite 14
Chapter 1 Preliminaries and Definitions
3. If language L is NP-complete then L ∈ P if and only if P = NP.
The proof is left as a task to the reader.
Figure 1.3: Relationship between classes
P and NP and NPCompleteness.
1.3 Cryptographic Primitives
Here, we recall the cryptographic primitives that we will refer to lateron.
1.3.1 Collision-resistant hash functions
An unkeyed hash function H : {0, 1}∗ → {0, 1}µ is a deterministic algorithm. The
advantage of A in finding a collision in H is
h
i
0
0
0 $
Advcr
H (A) = Pr H(x) = H(x ) ∧ x 6= x : (x, x ) ← A() .
1.3.2 Digital Signature Schemes
A digital signature scheme is a triple of PPT- algorithms SIG = (SIG.Gen, SIG.Sign,
$
SIG.Vfy), consisting of a key generation algorithm (sk, pk) ← SIG.Gen(1κ ) generating a
(public) verification key pk and a secret signing key sk when input the security parameter
$
κ, a signing algorithm σ ← SIG.Sign(sk, m) generating a signature for message m, and a
verification algorithm SIG.Vfy(pk, σ, m) returning 1, if σ is a valid signature for m under
key pk, and 0 otherwise.
Example 2 (RSA Full Domain Hash [BR93]). Variants of the RSA-Full Domain Hash
are widely used in practice. The scheme works as follows:
Key Generation. When input the security parameter 1k in unary, the key generation
$
algorithm samples two primes p, q of length k bits. It sets N = p · q, samples e ←
−1
ZN such that gcd(e, (p − 1) · (q − 1)) = 1 and computes e
mod (p − 1) · (q − 1).
The public key is (N, e) and the private key is (N, d).
1.3 Cryptographic Primitives
Seite 15
Signing. The signing algorithm computes a signature on a message m as follows: First,
it computes m0 = H(m) where H : {0, 1}∗ → Z∗N is a publicly known collision
d
resistant hash function. It returns σ as σ ← m0 mod N .
Verification. The verification algorithm verifies a signature σ over message m as follows. It computes m0 = H(m) and accepts if σ e = m0 mod N .
Consider the following security experiment played between a challenger C and an adversary A.
$
1. The challenger generates a public/secret key pair (sk, pk) ← SIG.Gen(1κ ), the
adversary receives pk as input.
2. The adversary may adaptively query arbitrary messages mi to the challenger. The
challenger replies to each query with a signature σi = SIG.Sign(sk, mi ). Here i is
an index, ranging between 1 ≤ i ≤ q for some q ∈ N.
3. Eventually, the adversary outputs a message/signature pair (m, σ).
Definition 1.10
D
We say that SIG is (t, SIG )-secure against existential forgeries under adaptive
chosen-message attacks (EUF-CMA), if for all adversaries A that run in time t it
holds that
h
i
$
Pr (m, σ) ← AC (1κ , pk) : SIG.Vfy(pk, m, σ) = 1 ∧ m 6∈ {m1 , . . . , mq } ≤ SIG .
Note that we have q ≤ t, i.e. the number of allowed queries q is bound by the
running time t of the adversary.
1.3.3 Pseudo-Random Functions
A pseudo-random function is an algorithm PRF. This algorithm implements a deterministic function z = PRF(k, x), taking as input a key k ∈ KPRF and some bit string x, and
returning a string z ∈ {0, 1}µ .
Consider the following security experiment played between a challenger C and an adversary A.
$
$
1. The challenger samples k ← KPRF uniformly random, and tosses a coin b ←
{0, 1}.
2. The adversary may query arbitrary values xi to the challenger. Here i is an index,
ranging between 1 ≤ i ≤ q for some q ∈ N. Queries can be made adaptively.
• If b = 0, the challenger replies to each query with zi0 := PRF(k, xi ).
$
• If b = 1, the challenger replies to each query with zi1 ← {0, 1}µ .
3. Finally, the adversary outputs a guess b0 ∈ {0, 1}.
Seite 16
D
Chapter 1 Preliminaries and Definitions
Definition 1.11
We say that PRF is a (t, PRF )-secure pseudo-random function, if an adversary running in time t has at most an advantage of PRF to distinguish the PRF from a truly
random function, i.e.
|Pr [b = b0 ] − 1/2| ≤ PRF .
Again the number of allowed queries q is upper bounded by t (see Def. 1.10).
Remark 2. Definition 1.11 is a slight modification of the standard definition: In the standard definition, the challenger answers all queries from the adversary with pseudorandom
values. The cahllenger only flips a coin when he receives a value x together with a special
symbol >. However, both definitions are polynomially equivalent.
1.3.4 Message Authentication Codes
A message authentication code is an algorithm MAC. This algorithm implements a deterministic function w = MAC(Kmac , m), taking as input a (symmetric) key Kmac ∈ {0, 1}κ
and a message m, and returning a string w.
Consider the following security experiment played between a challenger C and an adversary A.
$
1. The challenger samples Kmac ← {0, 1}κ uniformly random.
2. The adversary may query arbitrary messages mi to the challenger. The challenger
replies to each query with wi = MAC(Kmac , mi ). Here i is an index, ranging
between 1 ≤ i ≤ q for some q ∈ N. Queries can be made adaptively.
3. Eventually, the adversary outputs a pair (m, w).
D
Definition 1.12
We say that MAC is a (t, MAC )-secure message authentication code, if for all adversaries A that run in time t holds that
h
i
$
Pr (m, w) ← AC (1κ ) : w = MAC(Kmac , m) ∧ m 6∈ {m1 , . . . , mq } ≤ MAC .
As in Def. 1.10 and 1.11 it holds that q ≤ t, where q is the number of allowed
queries.
1.3.5 Stateful Length-Hiding Authenticated Encryption
Let us now describe the stateful variant of LHAE security (the following description and
security model was obtained from the authors of [PRS11] via personal communication).
See [PRS11] for a detailed discussion and motivation of this model.
1.3 Cryptographic Primitives
Seite 17
Encrypt(m0 , m1 , len, H):
u := u + 1
(0)
Decrypt(C, H):
v := v + 1
$
(C (0) , ste ) ← StE.Enc(k, len, H, m0 , ste )
If b = 0, then return ⊥
(1) $
(C (1) , ste ) ← StE.Enc(k, len, H, m1 , ste )
If C (0) = ⊥ or C (1) = ⊥ then return ⊥
(m, std ) = StE.Dec(k, H, C, std )
If v > u or C 6= Cv , then phase := 1
If phase = 1 then return m
Return ⊥
(b)
(Cu , ste ) := (C (b) , ste )
Return Cu
Figure 1.4: Encrypt and
Decrypt oracles in the
stateful LHAE security
experiment.
A stateful symmetric encryption scheme consists of two algorithms StE =
$
(StE.Enc, StE.Dec). Algorithm (C, st0e ) ← StE.Enc(k, len, H, m, ste ) takes as input a seκ
cret key k ∈ {0, 1} , an output ciphertext length len ∈ N, some header data H ∈ {0, 1}∗ ,
a plaintext m ∈ {0, 1}∗ , and the current state ste ∈ {0, 1}∗ , and outputs either a ciphertext C ∈ {0, 1}len and an updated state st0e or an error symbol ⊥ if for instance the output
length len is not valid for the message m. Algorithm (m0 , st0d ) = StE.Dec(k, H, C, std )
takes as input a key k, header data H, a ciphertext C, and the current state std ∈ {0, 1}∗ ,
and returns an updated state st0d and a value m0 which is either the message encrypted in
C, or a distinguished error symbol ⊥ indicating that C is not a valid ciphertext. Both encryption state ste and decryption state std are initialized to the empty string ∅. Algorithm
StE.Enc may be probabilistic, while StE.Dec is always deterministic.
Definition 1.13
D
We say that a stateful symmetric encryption scheme StE = (StE.Init, StE.Enc,
StE.Dec) is (t, sLHAE )-secure, if Pr[b = b0 ] ≤ sLHAE for all adversaries A running in time at most t in the following experiment.
$
$
• Choose b ← {0, 1} and k ← {0, 1}κ , and set ste := ∅ and std := ∅,
$
• run b0 ← AEncrypt,Decrypt .
Here AEncrypt,Decrypt denotes that A has access to two oracles Encrypt and Decrypt.
The encryption oracle Encrypt(m0 , m1 , len, H) takes as input two messages m0
and m1 , length-parameter len and header data H. It maintains a counter u which is
initialized to 0. Oracle Decrypt(C, H) takes as input a ciphertext C and header H,
and keeps a counter v and a variable phase, both are initialized to 0. Both oracles
process a query as defined in Figure 1.4.
1.3.6 Buffered stateful authenticated encryption
Paterson et al. [PW10] introduced buffered stateful authenticated encryption (BSAE) for
appropriately modeling the security of the SSH auth-enc channel.
A similar notion (stateful length-hiding authenticated encryption (sLHAE)) is used to
model the auth-enc channel in TLS [PRS11, JKSS12]. These notions encompass both
confidentiality (indistinguishability under chosen ciphertext attack) and stateful ciphertext
integrity.
The main difference of BSAE to previous definitions for authenticated encryption schemes is that the decryption oracle buffers partial ciphertexts until a complete ciphertext
block is received, before answering a decryption query.
Seite 18
Figure 1.5: Encrypt and
Decrypt oracles in the
buffered stateful authenticated encryption security experiment. The values u, v and phase are
all initialized to 0 at the
beginning of the security
game. The Decrypt query accounts for buffering
in the third line.
Chapter 1 Preliminaries and Definitions
Decrypt(C):
Encrypt(m0 , m1 ):
1: u ← u + 1
$
2: (C (0) , st0e ) ← Enc(k, m0 , st0e )
3:
4:
5:
6:
7:
8:
$
(C (1) , st1e ) ← Enc(k, m1 , st1e )
if C (0) = ⊥ or C (1) = ⊥ then
return ⊥
end if
C[u] ← C (b)
return C (b)
1:
2:
3:
4:
5:
6:
7:
8:
9:
v ←v+1
(m, std ) ← Dec(k, C, std )
if m = ⊥p then return ⊥
if b = 0 then return ⊥
if v > u or C 6= C[v] then
phase ← 1
end if
if phase = 1 then return m
return ⊥
A BSAE scheme is a pair of algorithms StE = (Enc, Dec) described in Figure 1.5; our presentation adapts the chosen ciphertext security and integrity notions for buffered stateful
authenticated encryption given by Paterson and Watson [PW10] to the combined setting
used in the ACCE experiment of Jager et al. [JKSS12].
$
• The encryption algorithm Enc(k, C, ste ) → (m, st0e ), takes as input a symmetric
secret key k ∈ {0, 1}κ , a plaintext m ∈ {0, 1}∗ , and an encryption state ste ,
outputs either a ciphertext c ∈ {0, 1}` or an error ⊥, and an updated encryption
state st0e .
• The decryption algorithm Dec(k, c, std ) → m0 processes secret key k, ciphertext c, and decryption state std . It returns the new decryption state std (possibly
containing yet unprocessed ciphertext chunks) and a value m0 which is either the
message encrypted in c, a pending state symbol ⊥p to signal that it has not received
enough ciphertext bytes to decrypt, or a distinguished error symbol ⊥e indicating
that c is not a valid ciphertext.
Security of a BSAE is defined via the following security game played between a challenger C and adversary A.
$
$
1. The challenger picks b ← {0, 1} and k ← {0, 1}κ .
2. The adversary may adaptively query the encryption oracle Encrypt and decryption
oracle Decrypt which respond as shown in Figure 1.5.
3. The adversary outputs a guess b0 ∈ {0, 1}.
The
advantage of A in breaking the BSAE scheme StE is Advbsae
StE (A)
Pr(b = b0 ) − 1 .
2
=
1.4 Complexity Assumptions
In this section, we recall the computational complexity assumptions we will rely on in the
sequel.
1.4.1 The Decisional Diffie-Hellman Assumption
Let G be a group of prime order q and let g be a generator of G. Given, (g, g a , g b , g c )
$
for a, b, c ← Zq the decisional Diffie-Hellman (DDH) assumption says that it is hard to
decide whether c = ab mod q.
1.4 Complexity Assumptions
Seite 19
Definition 1.14
D
We say that the DDH problem is (t, DDH )-hard in G, if for all adversaries A that
run in time t it holds that
Pr A(g, g a , g b , g ab ) = 1 − Pr A(g, g a , g b , g c ) = 1 ≤ DDH ,
$
where a, b, c ← Zq .
1.4.2 The PRF-Oracle-Diffie-Hellman Assumption
Let G be a group with generator g. Let PRF be a deterministic function z = PRF(X, m),
taking as input a key X ∈ G and some bit string m, and returning a string z ∈ {0, 1}µ .
Consider the following security experiment played between a challenger C and an adversary A.
1. The adversary A outputs a value m.
$
$
2. The Challenger samples u, v ← [q], z1 ← {0, 1}µ uniformly random and sets
z0 := PRF(g uv , m). Then it tosses a coin b ∈ {0, 1} and returns zb , g u and g v to
the adversary.
3. The adversary may query a pair (X, m0 ) with X 6= g u to the challenger. The challenger replies with PRF(X v , m0 ).
4. Finally the adversary outputs a guess b0 ∈ {0, 1}.
Definition 1.15
D
We say that the PRF-ODH problem is (t, prfodh )-hard in with respect to G and PRF,
if for all adversaries A that run in time t it holds that
|Pr [b = b0 ] − 1/2| ≤ prfodh .
The PRF-Oracle-Diffie-Hellman (PRF-ODH) assumption is a variant of the ODH assumption introduced by Abdalla, Bellare and Rogaway in [ABR01], adopted from hash
functions to PRFs. In contrast to allowing a polynomial number of queries as in the original assumption [ABR01], we allow only a single oracle query.
Chapter 2 AKE Protocols: The Extended Bellare-Rogaway Model
Seite 21
Chapter 2 AKE Protocols: The Extended Bellare-Rogaway
Model
While the established security models for, say, encryption (e.g. IND-CPA or IND-CCA
security), or digital signatures (e.g., EUF-CMA), are clean and simple, a more complex
model is required to model the capabilities of active adversaries to define secure authenticated key-exchange. An important line of research [BWJM97, CK01, LLM07, Cre09]
dates back to Bellare and Rogaway [BR94], where an adversary is provided with an ‘execution environment’, which emulates the real-world capabilities of an active adversary. In
this model, the adversary has full control over the communication network, which allows
him to forward, alter, or drop any message sent by the participants, or insert new messages. In the sequel we describe a variant of this model, which captures adaptive corruptions,
perfect forward secrecy, and security against key-compromise impersonation attacks in a
public-key setting.
2.1 Execution Environment
Consider a set of parties {P1 , . . . , P` }, ` ∈ N, where each party Pi ∈ {P1 , . . . , P` } is a
(potential) protocol participant and has a long-term key pair (pki , ski ). To model several
sequential and parallel executions of the protocol, each party Pi is modeled by a collection
of oracles πi1 , . . . , πid for d ∈ N. Each oracle πis represents a process that executes one
single instance of the protocol. All oracles πi1 , . . . , πid representing party Pi have access to
the same long-term key pair (pki , ski ) of Pi and to all public keys pk1 , . . . , pk` . Moreover,
each oracle πis maintains as internal state the following variables:
• Λ ∈ {accept, reject}.
• k ∈ K, where K is the keyspace of the protocol.
• Π ∈ {1, . . . , `} containing the intended communication partner, i.e., an index j
that points to a public key pkj used to perform authentication within the protocol
execution.1
• Variable ρ ∈ {Client, Server}.
• Some additional temporary state variable st (which may, for instance, be used to
store ephemeral Diffie-Hellman exponents or the transcript of all messages sent/received during the TLS Handshake).
. The internal state of each oracle is initialized to (Λ, k, Π, ρ, st) = (∅, ∅, ∅, ∅, ∅), where
V = ∅ denotes that variable V is undefined. Furthermore, we will always assume (for
simplicity) that k = ∅ if an oracle has not reached accept-state (yet), and contains the
computed key if an oracle is in accept-state, so that we have
k 6= ∅ ⇐⇒ Λ = ‘accept0 .
(2.1)
2.2 Adversarial Model
An adversary may interact with these oracles by issuing the following queries.
1 We
assume that each party Pi is uniquely identified by its public key pki . In practice, several keys may be
assigned to one identity. Furthermore, there may be other ways to determine identities, for instance by using
certificates. However, this is out of scope of this paper.
Seite 22
Chapter 2 AKE Protocols: The Extended Bellare-Rogaway Model
• Send(πis , m): The adversary can use this query to send message m to oracle πis .
The oracle will respond according to the protocol specification, depending on its
internal state.
If the attacker asks the first Send-query to oracle πis , then the oracle checks whether m = > consists of a special ‘initialization’ symbol >. If true, then it sets its
internal variable ρ := Client and responds with the first protocol message. Otherwise it sets ρ := Server and responds as specified in the protocol.2
The variables Λ, k, Π, st are also set after a Send-query. When and how depends
on the considered protocol.
• Reveal(πis ): Oracle πis responds to a Reveal-query with the contents of variable k.
Note that we have k 6= ∅ if and only if Λ = ‘accept’, see (2.1).
• Corrupt(Pi ): Oracle πi1 responds with the long-term secret key ski of party Pi .3
If Corrupt(Pi ) is the τ -th query issued by A, then we say that Pi is τ -corrupted.
For parties that are not corrupted we define τ := ∞. If only static corruptions are
allowed, we may omit the parameter τ . After a Corrupt(Pi ) query has been asked,
the party Pi and all its oracles are marked as (τ -)corrupted.
• Test(πis ): This query may be asked only once throughout the game. If πis has state
Λ 6= accept, then it returns some failure symbol ⊥. Otherwise it flips a fair coin
$
b, samples an independent key k0 ← K, sets k1 = k to the ‘real’ key computed by
πis , and returns kb .
The Send-query enables the adversary to initiate and run an arbitrary number of protocol instances, sequential or in parallel, and provides full control over the communication
between all parties. The Reveal-query may be used to learn the session keys used in previous/concurrent protocol executions. The Corrupt-query allows the attacker to learn ski
of party Pi , it may for instance be used by A to impersonate Pi . The Test-query will be
used to define security.
2.3 Security Definition
Bellare and Rogaway [BR94] have introduced the notion of matching conversations in
order to define correctness and security of an AKE protocol precisely.
We denote with Ti,s the sequence that consists of all messages sent and received by πis in
chronological order (not including the initialization-symbol >). We also say that Ti,s is
the transcript of πis . For two transcripts Ti,s and Tj,t , we say that Ti,s is a prefix of Tj,t ,
if Ti,s contains at least one message, and the messages in Ti,s are identical to and in the
same order as the first |Ti,s | messages of Tj,t .
D
Definition 2.1
We say that πis has a matching conversation to πjt , if
• Tj,t is a prefix of Ti,s and πis has sent the last message(s), or
• Ti,s is a prefix of Tj,t and πjt has sent the last message(s).
2 Note
that we do not include the identity of the (intended) communication partner in the Send-query. Instead,
we assume that the exchange of identities of communication partners (which is necessary to determine the
public-key used to perform authentication) is part of the protocol.
3 Note, that the adversary does not ‘take control’ of oracles corresponding to a corrupted party. But he learns
the long-term secret key, and can henceforth simulate these oracles.
2.3 Security Definition
Seite 23
Remark 3. We remark that matching conversations in the above sense can also be seen as
post-specified session identifiers. The ‘asymmetry’ of the definition (i.e., the fact that we
have to distinguish which party has sent the last message) is necessary, due to the fact that
protocol messages are sent sequentially. For instance in the TLS Handshake protocol (see
Figure 3.1) the last message of the client is the ‘client finished’ message finC , and then
it waits for the ’server finished’ message finS before acceptance. In contrast, the server
sends finS after receiving finC . Therefore the server has to ‘accept’ without knowing
whether its last message was received by the client correctly. We have to take this into
account in the definition of matching conversations, since it will later be used to define
security of the protocol in presence of an active adversary that simply drops the last
protocol message.
Security of AKE protocols is now defined by requiring that (i) the protocol is a secure
authentication protocol, and (ii) the protocol is a secure key-exchange protocol, thus an
adversary cannot distinguish the session key k from a random key.
We formalize this in the following games and definitions. To have a controlled environment and to guarantee that all queries by the adversary will indeed be answered, the
network, the different parties, and all process oracles will be simulated by a challenger C.
The challenger simulates the original games faithfully, i.e. all the process oracles fully adhere to the protocol specification, and all queries by the adversary are answered correctly.
that means that the winning probability of the adversary in this simulation is exactly the
same as if the adversary would interact with a real network like the internet, and with a
real implementation of the protocol.
During each proof, we will modify the simulation slightly step by step, and we will carefully argue how these modifications may alter the winning probability of the adversary.
The goal of this process is to end up with a modified game where the winning probability directly depends on combinatorics only, or on one well-established cryptographic
assumption. Going backwards from this final winning probability, we will compute an
upper bound on the winning probability of the adversary in the original game, taking into
account all modifications made in between the original and teh final game.
Definition 2.2
We say that an adversary (t, )-breaks an authentication (A-) protocol ΠA in game
GA , if A runs in time t, and the following condition holds:
1. When A terminates, then with probability at least there exists an oracle πis
such that
• πis ‘accepts’ when A issues its τ0 -th query with intended partner Π =
j, and
• there is no unique oracle πjt such that πis has a matching conversation
to πjt .
If an oracle πis accepts in the above sense, then we say that πis accepts maliciously.
We say that an AKE protocol is (t, )-secure, if there exists no adversary that (t, )breaks it.
D
Seite 24
Chapter 2 AKE Protocols: The Extended Bellare-Rogaway Model
Authentication Game GA .
In this game, the adversary A is only allowed to ask Send queries, i.e. he acts as an active
adversary. Since we do not consider the secrecy of the session key in this game, Reveal
and Test queries do not make sense. The adversary wins the game if he can force an
arbitrary oracle to accept, but there is no second oracle with a matching conversation.
AKE Game Gstat
AKE with Static Corruptions.
In this game, the adversary A tries to break either the authentication propoerty of the
protocol, or the secrecy of the session key. He is therefore allowed to ask polynomially
many Send and Reveal, and one Test query. In addition we allow static corruptions, i.e.
the adversary must send all Corrupt queries at the beginning of the game (this helps to
make the proof simpler).
D
Definition 2.3
We say that an adversary (t, )-breaks an AKE protocol ΠAKE in game Gstat
AKE , if
A runs in time t, and at least one of the following two conditions holds:
1. When A terminates, then with probability at least there exists an uncorrupted oracle πis such that
• πis ‘accepts’ with uncorrupted intended partner Π = j, and
• there is no unique oracle πjt such that πis has a matching conversation
to πjt .
If an oracle πis accepts in the above sense, then we say that πis accepts maliciously.
2. When A issues a Test-query to any uncorrupted oracle πis and
• πis ‘accepts’ with uncorrupted intended partner Π = j,
• A does not issue a Reveal-query to πis , nor to πjt such that πis has a
matching conversation to πjt (if such an oracle exists), and
then the probability that A outputs b0 which equals the bit b sampled by the
Test-query satisfies
|Pr[b = b0 ] − 1/2| ≥ .
If an adversary A outputs b0 such that b0 = b and the above conditions are
met, then we say that A anwers the Test-challenge correctly.
We say that an AKE protocol is (t, )-secure, if there exists no adversary that (t, )breaks it.
AKE Game with Perfect Forward Secrecy.
We formally capture this notion as a game, played between an adversary A and a challenger C. The challenger implements the collection of oracles {πis : i ∈ [`], s ∈ [d]}. At the
beginning of the game, the challenger generates ` long-term key pairs (pki , ski ) for all
2.3 Security Definition
Seite 25
i ∈ [`]. The adversary receives the public keys pk1 , . . . , pk` as input. Now the adversary
may start issuing Send, Reveal and Corrupt queries, as well as one Test-query. Finally,
the adversary outputs a bit b0 and terminates.
Definition 2.4
We say that an adversary (t, )-breaks an AKE protocol, if A runs in time t, and at
least one of the following two conditions holds:
1. When A terminates, then with probability at least there exists an oracle πis
such that
• πis ‘accepts’ when A issues its τ0 -th query with intended partner Π =
j, and
• Pj is τj -corrupted with τ0 < τj ,a and
• there is no unique oracle πjt such that πis has a matching conversation
to πjt .
If an oracle πis accepts in the above sense, then we say that πis accepts maliciously.
2. When A issues a Test-query to any oracle πis and
• πis ‘accepts’ when A issues its τ0 -th query with intended partner Π =
j, and Pj is τj -corrupted with τ0 < τj ,
• A does not issue a Reveal-query to πis , nor to πjt such that πis has a
matching conversation to πjt (if such an oracle exists), and
then the probability that A outputs b0 which equals the bit b sampled by the
Test-query satisfies
|Pr[b = b0 ] − 1/2| ≥ .
If an adversary A outputs b0 such that b0 = b and the above conditions are
met, then we say that A anwers the Test-challenge correctly.
We say that an AKE protocol is (t, )-secure, if there exists no adversary that (t, )breaks it.
is, Pj is not corrupted when πis ‘accepts’. Recall that uncorrupted parties are τ -corrupted with
τ = ∞.
a That
Remark 4. Note that the above definition even allows to corrupt oracles involved in the
Test-session (of course only after the Test-oracle has reached accept-state, in order
to exclude trivial attacks). Thus, protocols secure with respect to this definition provide
perfect forward secrecy. Note also that we allow the ‘accepting’ oracle to be corrupted
even before it reaches accept-state, which provides security against key-compromise
impersonation attacks.
Remark 5. There is a subtle difference between Definition 2.4 and the classical definition
of Bellare and Rogaway from [BR94], which we want to highlight due to its importance.
Bellare and Rogaway made the restriction that the Test-query is the adversary’s last. It
was pointed out (see Remark 5 in [BPR00]) that this does not guarantee security for
certain applications.
It is however folklore [BPR00] that simply removing the restriction suffices to solve the
D
Seite 26
Chapter 2 AKE Protocols: The Extended Bellare-Rogaway Model
issue. Accordingly, we allow the adversary explicitly to make further queries after the
Test-query.
2.4 Basic AKE Protocols
As mentioned before, the analysis of authenticated key exchange protocols goes back
to Bellare and Rogaway [BR94]. In their seminal work, the authors did also propose
protocols that are provably secure with respect to the proposed models. Here, we discuss
these protocols.
2.4.1 Mutual Authentication Protocol 1 (MAP1)
Figure 2.1: The MAP1
protocol from [BR94].
M AP 1 protocol
B
k = kAB
A
k = kAB
$
RA ← {0, 1}κ
[A.RB ]k :=
(A.RB , PRF(k, A.RB ))
RA
−
−−−−−−−−−−−
→
−
$
RB ← {0, 1}κ
[B.A.RA .RB ]k :=
(B.A.RA .RB , PRF(k, B.A.RA .RB ))
[B.A.RA .RB ]k
−−−−−−−−−−−
−
−
←
[A.RB ]k
−
−−−−−−−−−−−
→
−
Security Proof of MAP1
Theorem 2. If PRF is (t0 , 0 )-secure then MAP1 is a (t, )-secure authentication protocol
with t ≈ t0 and
(l · d)2
l·d
≤
+ 0 + κ .
κ
2
2
Beweis. We have to show that there is no adversary that (t, )-breaks MAP1 according to
Definition 2.2 if PRF is (t0 , 0 )-secure.
Game 0.
We start with the original game GA where a challenger C faithfully simulates MAP1, and
correctly answers all Send queries from the adversary A. Thus, for some we have
(A)
Pr[break0 ] = .
2.4 Basic AKE Protocols
Seite 27
Game 1.
In this game, we add an abort rule to the simulation: If any nonce value appears twice, the
game will be aborted.
This abort condition may occur with a certain probability, which we approximate as follows: If an oracle generates a nonce, this nonce is compared with all previously issued
nonces. The more nonces have already been generated, the higher the probability of a
match is. If we therefore have a look at the last nonce that may be generated, the nonce of
the last activated oracle, which is number ` · d. The probability that this nonce is equal to
. For all nonces generated earlier,
one of the (` · d) − 1 onces already generated is (`·d)−1
2κ
this probability is smaller.
Thus we may state that the probability that any of the newly generated nonces is equal to
a previously generated nonce is strictly smaller than (`·d)
2κ , for all ` · d nonces that may be
generated during the simulation. Thus we get an upper bound for the abort event
Pr[abortnoncecollission ] <
(` · d)2
.
2κ
Note: This is a very generous upper bound, which can of course be improved. For the purpose of this proof it is however only important that this upper bound is negligible, which
is guaranteed by the fact that the numerator term is ploynomial, whereas the denominator
term is exponential in the security parameter κ.
If we assume that adversary A could win the original game with probability 1 in case the
abort condition occurs, we know that
(A)
(A)
Pr[break0 ] < Pr[break1 ] +
(` · d)2
.
2κ
Please note that starting from the present game, replay attacks are no longer possible,
since each nonce is unique.
Game 2.
In this game, we successively replace the PRF computations for each long-lived key by
the evaluation of a truly random fuction f (·). 4 Thus we create a sequence of subgames
`·(`−1)
G02 , G12 , . . . , G2
, where game Gk2 contains ` − k PRF evaluations, and k evaluations
of the random funtion f (·).
(k+1)
More precisely, we proceed as follows: In game G2
we randomly choose one of the
long-lived keys kij shared between parties Pi and Pj , which was used in game Gk2 to
evaluate the pseudorandom function. Instead of computing
[x]kij := (x, P RF (kij , x)),
the challenger computes
[x]kij := (x, f (kij .x)).
This can be achieved using the standard database trick: In each simulation, the challenger
sets up a empty database to construct a truly random function value by value:
4 Such
truly random functions are sometimes called non-programmable Random Oracles.
Seite 28
Chapter 2 AKE Protocols: The Extended Bellare-Rogaway Model
• If f (·) is evaluated for the first time on value y, then f (y) is chosen randomly and
the pair (y, f (y)) is stored in the database.
• If f (·) has already been evaluated on value y, then f (y) is retrieved from the
database.
The adversary A is not able to evaluate the PRF since he doesn’t know any of the longlived keys, thus it is legitimate to prevent the adversary from accessing f (·).
Claim 1. The winning probability of the adversary in any two consecutive games Gk2 and
Gk+1
only differs negligibly.
2
Beweis. We prove this claim by contradiction. Suppose there is at least one value k for
wich the winning probability of the adversary in games Gk2 and Gk+1
has a non-negligible
2
difference ∆. We show that in this case we can break the PRF-assumption from Definition
1.11.
Our A-challenger C, who simulates the games Gk2 , guesses the value k where the non1
.
negligible winning difference occurs. His guess will be correct with probability `·(`−1)
Now C randomly chooses a long-lived key kij from the set of keys that were still used
in Gk2 to compute the pseudorandom values exchanged between parties Pi and Pj . However, instead of replacing the pseudorandom function evaluation with the evaluation of
the random function f (·), C lets the PRF-challenger from Definition 1.11 compute the
checksums. 5
Let b be the bit chosen by the PRF-challenger.
• If b = 0, the new game equals Gk2 , although with kij replaced by an unknown
(k,A)
value k. Thus the winning probability of the adversary equals Pr[break2
].
• If b = 1, the new game equals Gk+1
. Thus the winning probability of the adversary
2
(k+1,A)
equals Pr[break2
].
C may now break the PRF assumption by issuing b0 = 0 in case A wins the new game,
$
and setting b0 ← {0, 1}κ else. If b = 0, the winning probability is higher by an amount of
∆, so the advantage of C in breaking the PRF assumption is ∆.
This is a contradiction to our assumption that PRF is a secure PRF, and thus we have
proven the claim.
Game 3.
In the present game, all checksums are random values computed by evaluating f (·). Since
each value over which the checksum is computed contains at least one different nonce, the
adversary A may only guess the correct checksum. This succeeds only with probability
`·d
1
2κ for a single oracle, and at most with probability 2κ for any oracle. Thus we have
(A)
Pr[break3 ] ≤
5 Since
`·d
.
2κ
random nonces are unique in the current game, all query values sent to the PRF-challenger will be
different from the values queried to f (·), so the adversary A is not able to detect this.
2.4 Basic AKE Protocols
Seite 29
Description of Mutual Authentication Protocol 2 (MAP2)
Figure 2.2: The MAP2
protocol from [BR94].
MAP2 protocol
A
k = kAB
B
k = kAB
$
RA ← {0, 1}κ
RA .T ext1
−−−−−−−−−−−−−−−−−−
→
$
RB ← {0, 1}κ
[B.A.RA .RB .T ext1 .T ext2 ]k
←
−
−−−−−−−−−−−−−−−−−−−−−
−
[A.RB .T ext3 ]k
−−−−−−−−−−−−−−−−−−→
−
MAP2 (cf. Figure 2.2) is an extension of MAP1: Three authenticated texts
T ext1 , T ext2 , T ext3 are transported. This extension does not change the security properties of the protocol, the proof for MAP1 can be re-used without change. Please note that
according to the security proof, parties A and B will only accept if there is a matching
conversation with a partner oracle. This implies that B knows that T ext1 and T ext3 are
authentic messages from A, and A knows that T ext2 is an authentic message from B.
2.4.2 Authenticated Key Exchange Protocol 1 (AKEP1)
Figure 2.3: The AKEP1
protocol from [BR94].
AKEP1 protocol
B
enc
int
, kenc = kAB
kint = kAB
A
enc
int
, kenc = kAB
kint = kAB
$
RA ← {0, 1}κ
RA
−−−−−−−−−−−−−−−−−
→
[B.A.RA .RB .{k}kenc ]kint
−
←
−−−−−−−−−−−−−−−−−−−−
[A.RB ]kint
−−−−−−−−−−−−−−−−−
→
$
RB ← {0, 1}κ
$
k ← {0, 1}κ
{k}kenc :=
(r, PRF0 (kenc , r) ⊕ k)
Security Proof of AKEP1
Theorem 3. If PRF is (t0 , 0 )-secure then AKEP1 is a (static) (t, )-secure AKE protocol
with t ≈ t0 and
1
2
0
≤ (d · `) · + κ
2
.
Beweis. We have to show that there is no adversary that (t, )-breaks AKEP1 according
to Definition 2.3. Since the adversary may win the game either by breaking condition 1 or
Seite 30
Chapter 2 AKE Protocols: The Extended Bellare-Rogaway Model
condition 2 of 2.3, the overall winning probability of the adversary is upper bounded by
the sum of these two probabilities:
A
A
A
A
P r[breakAKE
] ≤ P r[breakA
] + P r[6 (breakA
)ˆ
advTest
]
Dealing with static corruptions is relatively easy: A may ask a polynomial number of
Corrupt(Pi ) queries at the beginning of the game, and the simulator will answer with the
long-lived keys of (kPi P1 , . . . , kPi P` ) of this party. Breaking a protocol session in which
one of these keys is used does not constitute a winning event for the adversary, so we dot
not have to consider these sessions any more.
Since AKEP1 is, as an authentication protocol, only a special case of MAP2 (with
T ext1 = ∅, T ext2 = {k}kenc and T ext3 = ∅), for all sessions using uncorrupted longlived keys the probability that A breaks property 1 is bounded by Theorem 2.
We may thus assume that any oracle that accepts in such a session has a partnered oracle
with a matching conversation. I.e. that message 2 in AKEP1 was generated by an oracle
under the control of the simulator. This oracle behaved according to the protocol specification, and has chosen the session key randomly from the key space.
Game 0.
We start with the original game GA where a challenger C faithfully simulates AKEP1,
and correctly answers all Send, Corrupt and Reveal queries from the adversary A. Thus,
for some we have
(A)
Pr[break0 ] = .
Game 1.
In this game, we try to guess in which session the adversary will ask the Test query. We
abort the game if our guess was wrong. Tus we get
(A)
(A)
Pr[break0 ] ≤ Pr[break1 ] · (d · `)2 .
In the following let πis and πjt the two oracles participating in the Test session.
Game 2.
In this game, we replace the PRF computations in the testsession by the evaluation of a
truly random fuction f (·).
enc
More precisely, we proceed as follows: In game G2 we take the long-lived key kij
shared
k
between parties Pi and Pj , which was used in game G2 to evaluate the pseudorandom
function. Instead of computing
enc
enc := (r, P RF (k
{k}kij
ij , r) ⊕ k),
the challenger computes
enc
enc := (r, f (k
{k}kij
ij .r) ⊕ k).
2.4 Basic AKE Protocols
Seite 31
This can be achieved using the standard database trick: In each simulation, the challenger
sets up a empty database to construct a truly random function value by value:
• If f (·) is evaluated for the first time on value y, then f (y) is chosen randomly and
the pair (y, f (y)) is stored in the database.
• If f (·) has already been evaluated on value y, then f (y) is retrieved from the
database.
The adversary A is not able to evaluate the PRF since he doesn’t know any of the longlived keys, thus it is legitimate to prevent the adversary from accessing f (·).
Claim 2. The winning probability of the adversary in any two consecutive games G1 and
G2 only differs negligibly.
Beweis. We prove this claim by contradiction. Suppose that the winning probability of
the adversary in games G1 and G2 has a non-negligible difference ∆. We show that in
this case we can break the PRF-assumption from Definition 1.11.
Our AKE-challenger C, who simulates the games G1 , replaces the PRF function in all
sessions shared between Pi and Pj by the PRF-challenger from Definition 1.11.
Let b be the bit chosen by the PRF-challenger.
• If b = 0, the new game equals G1 , although with kij replaced by an unknown
(A)
value k. Thus the winning probability of the adversary equals Pr[break1 ].
• If b = 1, the new game equals G2 . Thus the winning probability of the adversary
(A)
equals Pr[break2 ].
C may now break the PRF assumption by issuing b0 = 0 in case A wins the new game,
$
and setting b0 ← {0, 1}κ else. If b = 0, the winning probability is higher by an amount of
∆, so the advantage of C in breaking the PRF assumption is ∆.
This is a contradiction to our assumption that PRF is a secure PRF, and thus we have
proven the claim.
In the present game, the keystream used to encrypt the session key in the Test session
is a random value computed by evaluating f (·). Thus we have a one-time pad 6 , and all
possible session keys are equally likely, and thus
(A)
Pr[break2 ] ≤
6 How
to guaratntee that r does never repeat?
1
.
2κ
Chapter 3 Transport Layer Security
Chapter 3 Transport Layer Security
T RANSPORT L AYER S ECURITY (TLS) is the single most important Internet security mechanism today. Therefore, its security studied many times in the literature. However, due
to a subtle interleaving of the TLS Handshake protocol with the data encryption in the
TLS Record Layer it is impossible to prove the security of TLS using well-established
security models [BR94, CK01, Can01] which define security via indistinguishability of
keys. This interleaving provides a ‘check value’ that allows to test whether a given key
is ‘real’ or ‘random’. More precisely, the final messages of the TLS Handshake protocol
(the Finished messages), which are essential to provide security against active adversaries like e.g. man-in-the-middle attackers, are first prepended with constant byte values
(which provides us with known plaintext), then integrity protected by a MAC (which is
instantiated with a pseudo-random function) and encrypted with the keys obtained from
the TLS Handshake protocol. Thus, whenever an adversary receives a challenge key in
response to a Test query, he can try to decrypt the Finished message and check validity of the MAC. If this succeeds, he will output ‘real’, and otherwise ‘random’. Even
changing the behavior of the Test query to only return the decryption keys (and not the
MAC keys) does not help, since the adversary could still use the known plaintext bytes
to answer the Test query successfully. Therefore it is impossible to prove the full TLS
Handshake protocol secure in any security model based on indistinguishability of keys.
Morissey et al. [MSW08] have therefore introduced a truncated TLS Handshake protocol,
where the final encryption of the Finished messages is omitted.
However, because of its eminent role, TLS and its building blocks have nonetheless been
subject to several security analyses. In 1996, Schneier and Wagner presented several minor flaws and some new active attacks against SSL 3.0 [WS96]. Starting with the famous
Bleichenbacher attack [Ble98], many papers focus on various versions of the PKCS#1
standard [Kal98] that defines the encryption padding used in TLS with RSA-encrypted
key transport [CJNP00, JK02, KP09, KOS10]. At Crypto’02, Johnson and Kaliski showed that a simplified version of TLS with padded RSA is IND-CCA secure when modeling TLS as a ‘tagged key-encapsulation mechanism’ (TKEM) [JK02] under the strong
non-standard assumption that a ‘partial RSA decision oracle’ is available.
In an independent line of research, several works analysed (simplified versions of) TLS
using automated proof techniques in the Dolev-Yao model [DY83]. Proofs that rely on the
Dolev-Yao model view cryptographic operations as deterministic operations on abstract
algebras. There has been some work on simplified TLS following the theorem proving and
model checking approach, i.e. Mitchell et al. used a finite-state enumeration tool named
Murphi [Mit98] while Ogata and Futatsugi used the interactive theorem prover OTS/CafeObj [OF05]. Paulson used the inductive method and the theorem prover Isabelle [Pau99].
Unfortunately it is not known if these proofs are actually cryptographically sound.
Bhargavan et al. [BFCZ08] go two steps farther: First, they automatically derive their
formal model from the source code of an TLS implementation, and second they try to
automatize computational proofs using the CryptoVerif tool. Chaki and Datta [CD09] also
use source code of TLS, automatically find a weakness in OpenSSL 0.9.6c, and claim that
SSL 3.0 is correct.
In 2008, Gajek et al. presented the first security analysis of the complete TLS protocol, combining Handshake and Record Layer, in the Universal Composability framework [Can01] for all three key exchange protocols static Diffie-Hellman, ephemeral signed Diffie-Hellman, and encrypted key transport [GMP+ 08]. The nonces rC and rS
exchanged between client and server can be seen as an instantiation of the protocol of
Barak et al. [BLR04] to agree on a globally unique session id. However, the ideal func-
Seite 33
Seite 34
Chapter 3 Transport Layer Security
tionalities described in this paper are strictly weaker than the security guarantees we expect from TLS: For the Handshake part, only unauthenticated key exchange is modelled
(FKE ), and thus the secure communication channel functionality (FSCS ) only guarantees
confidentiality, not authenticity of endpoints. The paper further assumes that RSA-OEAP
is used for encrypted key transport, which is not the case for current versions of TLS.
Küsters and Tuengerthal [KT11] claim to prove composable security for TLS assuming only local session identifiers, but leave out all details of the proof and only point
to [GMP+ 08].
Morissey et al. [MSW08] analysed, in a paper that is closest to our results, the security
of the truncated TLS Handshake protocol (cf. Section 3.2) in the random oracle model
and provided a modular proof of security for the established application keys. They make
extensive use of the random oracle model to separate the three layers they define in the
TLS Handshake, and to switch from computational to indistinguishability based security
models. The proof of Morissey et al. proceeds in three steps, and the order of messages of
the TLS Handshake is slightly changed to better separate these three steps. They first consider a very weak class of passively secure key exchange protocols where the session key
cannot be computed from the session transcript. As an example, when considering encrypted key transport (of the premaster secret) this requirement can easily be fulfilled if the
employed public key encryption scheme is OW-CPA secure. Next they define a slightly
stronger security notion that additionally protects against unknown key share attacks and
show that it applies to the master secret key exchange of TLS. As before security of the
key is defined in a one-way sense. In the last step they show that the ‘application keys’
(i.e. the encryption keys and MAC keys) produced by TLS fulfill the standard notion of
security, namely indistinguishability from random values. The use of the random oracle
model is justified by the authors by the fact that it seems impossible to prove the PKCS#1 v1.5 based ciphersuites of TLS secure in the standard model. This argumentation
does not affect our work, since we only consider Diffie-Hellman-based ciphersuites.
The work of Morissey et al. [MSW08], which can be seen as a reference for the TLS
Handshake protocol, considers also security of RSA based ciphersuites, and thus is much
broader in scope than our paper, but it does not cover our analysis of the TLS-DHE ciphersuite. The modular proof strategy used in this paper is essentially bound to the Random
Oracle Model, since secure protocols for the premaster phase only yield secure protocols
for the master phase if the master secret is derived from the premaster secret by evaluating
a Random Oracle. Thus the ROM is used not only to allow a security proof for TLS-RSA
ciphersuites, but also to allow for a modular proof technique.
Paterson, Ristenpart, and Shrimpton [PRS11] introduce the notion of length-hiding authenticated encryption, which aims to capture the properties from the TLS Record Layer
protocols. Most importantly, they were able to show that CBC-based ciphersuites of TLS
1.1 and 1.2 meet this security notion. This work matches nicely our results on the TLS
Handshake protocol. Their paper extends the seminal work of Bellare and Namprempre [BN00, BN08] on authenticated encryption, and on the analysis of different Mac-thenEncode-then-Encrypt (MEE) schemes analysed by Krawczyk [Kra01] and Maurer and
Tackmann [MT10].
Brzuska et al. [BFS+ 12] proposed relaxed game-based security notions for key exchange.
This independent approach may serve as an alternative to ACCE to circumvent the impossibility of proving the TLS Handshake secure in a key-indistinguishability-based security
model.
3.1 Description of TLS handshake messages
Seite 35
3.1 Description of TLS handshake messages
The current version (which we describe below) of TLS is 1.2 [DR08] and coexists with
its predecessors TLS 1.0 [DA99] and TLS 1.1 [DR06].
In the following we give a description of all messages sent during the TLS Handshake with
ephemeral Diffie-Hellman key exchange and client authentication (i.e. for ciphersuites
TLS_DHE_*). This description and its illustration in Figure 3.1 are valid for all TLS
versions since v1.0. Our description makes use of several ‘state variables’ (Λ, k, Π, ρ, st).
For instance, variable Λ ∈ {accept, reject} determines whether one party ‘accepts’ or
‘rejects’ an execution of the protocol, or variable k stores the session key. These variables
will also appear later in our security model (Section 2).
C
S
(IC = pkC , skC )
(IS = pkS , skS )
$
m1 ← Client Request()
m1
$
m2 , . . . , m6
(m2 , . . . , m6 ) ← Server Response(m1 )
$
(m7 , . . . , m11 ) ← Client Response(m2 , . . . , m6 )
m7 , . . . , m11
m12 , m13
(m12 , m13 ) ← Server Accept(m7 , . . . , m11 )
Client Accept(m12 , m13 )
pre-accept phase
————————————————————————————————————————————
post-accept phase
Client
StE.Enc(kenc
, len, H, data, ste )
Server
StE.Enc(kenc
, len, H, data, ste )
The TLS-DHE Handshake Protocol consists of 13 messages, whose content ranges from
constant byte values to tuples of cryptographic values. Not all messages are relevant for
our security proof, we list them merely for completeness. All messages are prepended
with a numeric tag that identifies the type of message, a length value, and the version
number of TLS. All messages are sent through the TLS Record Layer, which at startup
provides no encryption nor any other cryptographic transformations.
C LIENT H ELLO . Message m1 is the Client Hello message. It contains four values,
two of which are optional. For our analysis the only important value is rC , the random
value chosen by the client. It consists of 32 bytes (256 Bits), where 4 Bytes are usually
used to encode the local time of the client. The remaining 28 Bytes are chosen randomly
by the client. This is followed by a list cs-list of ciphersuites, where each ciphersuite
is a tuple of key exchange method, signing, encryption and MAC algorithms, coded as two
bytes. Data compression is possible before encryption and is signaled by the inclusion of
zero or more compression methods.
S ERVER H ELLO AND S ERVER K EY E XCHANGE . The Server Hello message m2
has the same structure as Client Hello, with the only exception that at most one ciphersuite and one compression method can be present. In our analysis the random value
rS is important. The server may send a TLS session ID sID to the client. Message m3
may contain a chain of certificates, starting from the TLS server certificate up to a direct
child of a root certificate. Since we do not include public key infrastructures in our analysis (the identity of each party is its public key pkS ), one certificate certS containing
Figure 3.1: TLS handshake for ciphersuites
TLS_DHE_* with client
authentication
Seite 36
Chapter 3 Transport Layer Security
pkS (which may be self-signed) is sufficient for this paper. When the certificate certS
is received, the client sets its partner id Π := S. The public key in the certificate must
match the ciphersuite chosen by the server. For ephemeral Diffie-Hellman key exchange,
the public key may be any key that can be used to sign messages. The Diffie-Hellman
(DH) key exchange parameters are contained in the Server Key Exchange message
m4 , including information on the DH group (e.g. prime number p and generator g for a
prime-order q subgroup of Z∗p ), the DH share TS , and a signature computed over these
values plus the two random numbers rC and rS . The next two messages are very simple:
the Certificate Request message m5 only contains a list of certificate types that
the client may use to authenticate itself, and the Server Hello Done message m6
does not contain any data, but consists only of a constant tag with byte-value ‘14’ and a
length value ‘0’.
C LIENT K EY E XCHANGE AND C LIENT F INISHED . Having received these messages, the
signature σS is verified. If this fails, the client ‘rejects’ and aborts. Otherwise, after successful verification, the client is able to complete the key exchange and to compute the
cryptographic keys. The Client Certificate message m7 contains a signing certificate certC with the public key pkC of the client. Message m8 is called Client Key
Exchange, and contains the Diffie-Hellman share TC of the client. When the certificate
certC is received by the server, the server sets its partner id Π := C. To authenticate the
client, a signature σC is computed on a concatenation of all previous messages (up to m8 )
and padded prefixes, thus including the two random nonces and the two Diffie-Hellman
shares. This signature is contained in the Certificate Verify message m9 .
The client is now also able to compute the premaster secret pms, from which all further secret values are derived. After computing the master secret ms, it is stored for the
lifetime of the TLS session, and pms is erased from memory. The master secret ms is subsequently used, together with the two random nonces, to derive all encryption and MAC
keys as well as the Client Finished message finC . More precisely, the key material
S→C
Client
S→C
C→S
Client
C→S
) is computed as
, Kmac
) and kdec
:= (Kenc
, Kmac
kenc
:= (Kenc
C→S
S→C
C→S
S→C
Kenc
||Kenc
||Kmac
||Kmac
:= PRF(ms, label2 ||rC ||rS )
(3.1)
Client
is used to encrypt and authenticate data sent from the client to the server,
where kenc
Client
and kdec is used to decrypt and verify data received from the server.
After these computations have been completed, the keys are handed over to the TLS Record Layer of the client, which is now able to encrypt and MAC any data. To signal
the ‘start of encryption’ to the server, a single message m10 (Change Cipher Spec)
with byte value ‘1’ (f lagenc ) is sent unencrypted to S. Then message m11 consists of an
authenticated encryption of the Client Finished message finC .
Remark 6. Please note that a padding is applied to finC before encryption and that this
padding allows for (partially) known plaintext attacks on m11 . Thus if we analyse TLS
in a key-indistinguishability-based security model, the answer to a Test query could
be determined by simply decrypting m11 , and checking if the resulting plaintext has the
appropriate padding. Thus TLS is not provably secure in any such model.
S ERVER F INISHED . After the server has received messages m7 , m8 , m9 , the server verifies the signature in m9 . If this fails, the server ‘rejects’ (i.e. sets Λ = ‘reject’) and
aborts. Otherwise it first determines pms and ms. From this the encryption and MAC keys
Server
S→C
S→C
Server
C→S
C→S
kenc
:= (Kenc
, Kmac
) and kdec
:= (Kenc
, Kmac
) are computed as in (3.1).1 It
can then decrypt m11 and check finC by computing the pseudo-random value on the messages sent and received by the server. If this check fails, it ‘rejects’ and aborts. If the check
is successful, it ‘accepts’ (i.e. sets Λ = ‘accept’), computes the Server Finished
1 Note
Server = k Client and k Server = k Client .
that we have kenc
enc
dec
dec
3.1 Description of TLS handshake messages
Seite 37
message finS and sends messages m12 and m13 to the client. If the check of finS on the
client side is successful, the client also ‘accepts’.
E NCRYPTED PAYLOAD T RANSMISSION . The obtained keys can now be used to transmit payload data in the TLS Record Layer using a stateful symmetric encryption scheme
StE = (StE.Enc, StE.Dec) (cf. Section 1.3.5). The CBC-based TLS Record Layer protocols work as follows. The state ste of the encryption algorithm consists of a sequence
number, which is incremented on each encryption operation. The encryption algorithm
takes a message m and computes a MAC over m, the sequence counter, and some additional header data H (such as version numbers, for instance). Then message and MAC
are encoded into a bit string by using a padding to a specified length len and encrypted
(‘MAC-then-Encode-then-Encrypt’).
The state std of the decryption algorithm consists of a sequence number, which is incremented on each decryption operation. Given a ciphertext, the algorithm decrypts and
verifies the MAC using its own sequence counter. See [PRS11] for details.
A BBREVIATED TLS H ANDSHAKES , SIDE - CHANNELS , AND CROSS - PROTOCOL ATTACKS . In our analysis, we do not consider abbreviated TLS Handshakes, but we note
that the server can always enforce a full TLS Handshake. Moreover, we do not consider
attacks based on side-channels, such as error messages or implementation issues like the
cross-protocol attack from [WS96].
Client_Response()
Client_Request()
ρ := Client
Π := S, S is determined from certS
if SIG.Vfy(pkΠ , σS , rC ||rS ||p||g||TS ) = 0 then
Λ := ‘reject’ and abort
else
$
$
rC ← {0, 1}λ
m1 := (rC , cs-list)
Server_Response()
ρ := Server
$
rS ← {0, 1}λ
$
tS ← Zq , TS := g tS mod p
σS := SIG.Sign(skS , rC ||rS ||p||g||TS )
m2 := (rS , cs-choice)
m3 := certS
m4 := (p, g, TS , σS )
m5 := get-cert
m6 := done
Client_Accept()
If finC 6= PRF(ms, label3 ||m1 || . . . ||m10 ) then
Λ := ‘reject’ and abort
else
Λ := ‘accept’ and output k
tC ← Zq , TC := g tC mod p
(m7 , m8 ) := (certC , TC )
σC := SIG.Sign(skC , m1 || . . . ||m8 )
t
pms := TSC mod p, ms := PRF(pms, label1 ||rC ||rS )
C→S
S→C
C→S
S→C
Kenc
||Kenc
||Kmac
||Kmac
:= PRF(ms, label2 ||rC ||rS )
Client
C→S
C→S
Client
S→C
S→C
kenc
:= (Kenc
, Kmac
), kdec
:= (Kenc
, Kmac
)
Client
Client
k := (kenc
, kdec
)
(m9 , m10 ) := (σC , f lagenc )
finC := PRF(ms, label3 ||m1 || . . . ||m10 )
Client
m11 := StE.Enc(kenc
, len, H, finC , ste )
Server_Accept()
Π := C, C is determined from certC
if SIG.Vfy(pkΠ , σC , m1 || . . . ||m8 ) = 0 then
Λ := ‘reject’ and abort
else
t
pms := TCS mod p, ms := PRF(pms, label1 ||rC ||rS )
C→S
S→C
C→S
S→C
Kenc
||Kenc
||Kmac
||Kmac
:= PRF(ms, label2 ||rC ||rS )
Server
S→C
S→C
Server
C→S
C→S
kenc
:= (Kenc
, Kmac
), kdec
:= (Kenc
, Kmac
)
Server
Server
k := (kenc
, kdec
)
m12 := f lagenc
finS := PRF(ms, label4 ||m1 || . . . ||m12 )
Server
m13 := StE.Enc(kenc
, len, H, finS , ste )
If finC 6= PRF(ms, label3 ||m1 || . . . ||m10 ) then
Λ := ‘reject’ and abort
else
Λ := ‘accept’ and output k
Figure 3.2: Computation
of Client/Server Handshake Messages
Seite 38
Chapter 3 Transport Layer Security
3.2 Truncated TLS with Ephemeral Diffie-Hellman is a Secure
AKE Protocol
In this section we prove the security of a modified version of the TLS Handshake protocol. As discussed in the introduction, it is impossible to prove the full TLS Handshake
protocol secure in any security model based on key-indistinguishability, like the model
from Section 2, because the encryption and MAC of the Finished messages provide a
‘check value’, that can be exploited by an adversary to determine the bit b chosen by the
Test-query.
Therefore we consider a ‘truncated TLS’ protocol as in [MSW08, MSW10]. In this truncated version, we assume that the Finished messages are sent in clear, that is, neither
encrypted nor authenticated by a MAC. More precisely, we modify the TLS protocol depicted in Figure 3.1 such that
Client
• message m11 contains only finC (instead of StE.Enc(kenc
, len, H, finC , ste )),
and
Server
• message m13 contains only finS (instead of StE.Enc(kenc
, len, H, finS , ste )).
This simple modification allows to prove security in the key-indisinguishability-based
security model from Section 2.
Theorem 4. Let µ be the output length of PRF and let λ be the length of the nonces rC and
rS . Assume that the pseudo-random function PRF is (t, prf )-secure, the signature scheme
is (t, sig )-secure, the DDH-problem is (t, ddh )-hard in the group G used to compute the
TLS premaster secret, and the PRF-ODH-problem is (t, prfodh )-hard with respect to G
and PRF.
Then for any adversary that (t0 , ttls )-breaks the truncated ephemeral Diffie-Hellman TLS
Handshake protocol in the sense of Definition 2.4 with t ≈ t0 holds that
5
5
1
d`
+
`
·
+
·
+
·
+
d`
+
+
.
ttls ≤ 4 · d`
sig
ddh
prf
prfodh
prf
2λ
4
2
2µ
Remark 7. In 2008, Fouque et al. [FPZ08] showed that the HMAC-based key-derivation
function of TLS is a pseudo-random function for 1) KP RF = S, where S is a prime-order
group of size |S| = q that is either defined over an elliptic curve or as a subgroup of Z∗p
such that q|p − 1, and 2) KP RF = {0, 1}l where l is the size of the master-secret (l =
384). The underlying security assumptions are all related to the fact that the compression
function of the hash function used in HMAC behaves like a pseudo-random function. More
details can be found in [FPZ08].
We consider three types of adversaries:
1. Adversaries that succeed in making an oracle accept maliciously, such that the first
oracle that does so is a Client-oracle (i.e., an oracle with ρ = Client). We call such
an adversary a Client-adversary.
2. Adversaries that succeed in making an oracle accept maliciously, such that the first
oracle that does so is a Server-oracle (i.e., an oracle with ρ = Server). We call such
an adversary a Server-adversary.
3. Adversaries that do not succeed in making any oracle accept maliciously, but which
answer the Test-challenge. We call such an adversary a Test-adversary.
3.2 Truncated TLS with Ephemeral Diffie-Hellman is a Secure AKE Protocol
We prove Theorem 4 by proving three lemmas. Lemma 1 bounds the probability client
that a Client-adversary succeeds, Lemma 2 bounds the probability server that a Serveradversary succeeds, and Lemma 3 bounds the success probability ke of a Test-adversary.
Then we have
ttls ≤ client + server + ke .
3.2.1 Authentication
Lemma 1. For any adversary A running in time t0 ≈ t, the probability that there exists
an oracle πis with ρ = Client that accepts maliciously is at most
1
d`
+ ` · sig + d` prfodh + prf + µ
client ≤ d`
2λ
2
where all quantities are defined as stated in Theorem 4.
Beweis. The proof proceeds in a sequence of games, following [BR06, Sho04]. The first
game is the real security experiment. We then describe several intermediate games that
modify the original game step-by-step, and argue that our complexity assumptions imply
that each game is computationally indistinguishable from the previous one. We end up in
the final game, where no adversary can break the security of the protocol.
(1)
Let breakδ be the event that occurs when the first oracle that accepts maliciously in the
sense of Definition 2.4 with ρ = Client in Game δ.
Game 0.
This game equals the AKE security experiment described in Section 2. Thus, for some
client we have
(1)
Pr[break0 ] = client .
Game 1.
In this game we add an abort rule. The challenger aborts, if there exists any oracle πis
that chooses a random nonce rC or rS which is not unique. More precisely, the game
is aborted if the adversary ever makes a first Send query to an oracle πis , and the oracle
0
replies with random nonce rC or rS such that there exists some other oracle πis0 which
has previously sampled the same nonce.
In total less than d` nonces rC and rS are sampled, each uniformly random from {0, 1}λ .
Thus, the probability that a collision occurs is bounded by (d`)2 2−λ , which implies
(2)
(2)
Pr[break0 ] ≤ Pr[break1 ] +
(d`)2
.
2λ
Note that now each oracle has a unique nonce rC or rS , which is included in the signatures.
We will use this to ensure that each oracle that accepts with non-corrupted partner has a
unique partner oracle.
Seite 39
Seite 40
Chapter 3 Transport Layer Security
Game 2.
We try to guess which client oracle will be the first oracle to accept maliciously. If our
guess is wrong, i.e. if there is another (Client or Server) oracle that accepts before, then
we abort the game.
Technically, this game is identical, except for the following. The challenger guesses two
$
random indices (i∗ , s∗ ) ← [`] × [d]. If there exists an oracle πis that ‘accepts’ maliciously,
∗ ∗
and (i, j) 6= (i , j ) and πis has ρ 6= Client, then the challenger aborts the game. Note
that if the first oracle πis that ‘accepts’ maliciously has ρ = Client, then with probability
1/(d`) we have (i, j) = (i∗ , j ∗ ), and thus
(2)
(2)
Pr[break1 ] = d` · Pr[break2 ].
Note that in this game the attacker can only break the security of the protocol, if oracle
∗
πis∗ is the first oracle that ‘accepts’ maliciously and has ρ = Client, as otherwise the game
is aborted.
Game 3.
Again the challenger proceeds as before, but we add an abort rule. We want to make sure
∗
that πis∗ receives as input exactly the Diffie-Hellman value TS that was selected by some
∗
other uncorrupted oracle that received the nonce rC chosen by πis∗ as first input (note
that there may be several such oracles, since the attacker may send copies of rC to many
oracles).
∗
Technically, we abort and raise event abortsig , if oracle πis∗ ever receives as input a message m3 = certS indicating intended partner Π = j and message m4 = (p, g, TS , σS ) such
that σS is a valid signature over rC ||rS ||p||g||TS , but there exists no oracle πjt which has
previously output σS . Clearly we have
(1)
(1)
P r[break2 ] ≤ Pr[break3 ] + Pr[abortsig ].
∗
Note that the experiment is aborted, if πis∗ does not accept maliciously, due to Game 2.
∗
This means that party Pj must be τj -corrupted with τj = ∞ (i.e., not corrupted) when πis∗
s∗
accepts (as otherwise πi∗ does not accept maliciously). To show that Pr[abortsig ] ≤ `·sig ,
we construct a signature forger as follows. The forger receives as input a public key pk ∗
$
and simulates the challenger for A. It guesses an index φ ← [`], sets pkφ = pk ∗ , and
generates all long-term public/secret keys as before. Then it proceeds as the challenger in
Game 3, except that it uses its chosen-message oracle to generate a signature under pkφ
when necessary.
If φ = j, which happens with probability 1/`, then the forger can use the signature
∗
received by πis∗ to break the EUF-CMA security of the signature scheme with success
probability sig , so Pr[abortsig ]/` ≤ sig . Therefore if Pr[abortsig ] is not negligible, then
sig is not negligible as well and we have
(1)
(1)
P r[break2 ] ≤ Pr[break3 ] + ` · sig .
∗
Note that in Game 3 oracle πis∗ receives as input a Diffie-Hellman value TS such that TS
was chosen by another oracle, but not by the attacker. Note also that there may be multiple
oracles that issued a signature σS containing rC , since the attacker may have sent several
copies of rC to several oracles.
3.2 Truncated TLS with Ephemeral Diffie-Hellman is a Secure AKE Protocol
Game 4.
In this game we want to make sure that we know which oracle πjt will issue the signature
∗
σS that πis∗ receives. Note that this signature includes the random nonce rS , which is
unique due to Game 1. Therefore the challanger in this game proceeds as before, but
$
additionally guesses two indices (j ∗ , t∗ ) ← [`] × [d]. It aborts, if the attacker does not
∗
∗
make a Send-query containing rC to πjt ∗ , and πjt ∗ responds with messages containing σS
∗
such that σS is forwarded to πis∗ .
We know that there must exists at least one oracle that outputs σS such that σS is forwar∗
ded to πis∗ , due to Game 3. Thus we have
(1)
(1)
Pr[break3 ] ≤ d` · Pr[break4 ].
∗
Note that in this game we know exactly that oracle πjt ∗ chooses the Diffie-Hellman share
∗
TS that πis∗ uses to compute its premaster secret.
Game 5.
∗
Recall that πis∗ computes the master secret as ms = PRF(TStc , label1 ||rC ||rS ), where TS
∗
denotes the Diffie-Hellman share received from πjt ∗ , and tc denotes the Diffie-Hellman
∗
∗
exponent chosen by πis∗ . In this game we replace the master secret ms computed by πis∗
∗
with an independent random value ms.
f Moreover, if πjt ∗ receives as input the same Diffie∗
∗
Hellman share TC that was sent from πis∗ , then we set the master secret of πjt ∗ equal to
ms.
f Otherwise we compute the master secret as specified in the protocol. We claim that
(1)
(1)
P r[break4 ] ≤ Pr[break5 ] + PRF-ODH .
Suppose there exists an adversary A that distinguishes Game 5 from Game 4. We show
that this implies an adversary B that solves the PRF-ODH problem.
Adversary B outputs (label1 ||rC ||rS ) to its oracle and receives in response (g, g u , g v , R),
$
where either R = PRF(g uv , label1 ||rC ||rS ) or R ← {0, 1}µ . It runs A by implementing
∗
u v
the challenger for A, and embeds (g , g ) as follows. Instead of letting πis∗ choose TC =
$
g tC for random tC ← Zq , B defines TC := g u . Similarly, the Diffie-Hellman share TS of
∗
∗
πjt ∗ is defined as TS := g v . Finally, the master secret of πis∗ is set equal to R.
∗
∗
Note that πis∗ computes the master secret after receiving TS from πjt ∗ , and then it sends
∗
∗
m8 = TC . If the attacker decides to forward m8 to πjt ∗ , then the master secret of πjt ∗ is
∗
set equal to R. If πjt ∗ receives TC 0 6= TC , then B queries its oracle to compute ms0 =
∗
PRF(TCv 0 , label1 ||rC ||rS ), and sets the master secret of πjt ∗ equal to ms0 .
∗
∗
Note that in any case algorithm B ‘knows’ the master secret of πis∗ and πjt ∗ , and thus
is able to compute all further protocol messages (in particular the finished messages
∗
finC and finS ) and answer a potential Reveal-query to πjt ∗ as required (note that the∗
re is no Reveal-query to πis∗ , as otherwise the experiment is aborted, due to Game 2).
If R = PRF(g uv , label1 ||rC ||rS ), then the view of A is identical to Game 4, while if
$
R ← {0, 1}µ then it is identical to Game 5, which yields the above claim.
Seite 41
Seite 42
Chapter 3 Transport Layer Security
Game 6.
∗
In this game we replace the function PRF(ms,
f ·) used by πis∗ with a random func∗
t∗
tion. If πj ∗ uses the same master secret ms
f as πis∗ (cf. Game 5), then the function
∗
PRF(ms,
f ·) used by πjt ∗ is replaced as well. Of course the same random function is used
for both oracles sharing the same ms.
f In particular, this function is used to compute the
Finished messages by both partner oracles.
Distinguishing Game 6 from Game 5 implies an algorithm breaking the security of the
pseudo-random function PRF, thus
(1)
(1)
Pr[break5 ] ≤ Pr[break6 ] + prf
Game 7.
Finally we use that the full transcript of all messages sent and received is used to compute
the Finished messages, and that Finished messages are computed by evaluating a
∗
∗
truly random function that is only accessible to πis∗ and (possibly) πjt ∗ due to Game 6.
∗
This allows to show that any adversary has probability at most 21µ of making oracle πis∗
∗
accept without having a matching conversation to πjt ∗ .
Thus, this game proceeds exactly like the previous game, except that the challenger now
∗
∗
aborts if oracle πis∗ accepts without having a matching conversation to πjt ∗ . Thus we have
(1)
Pr[break7 ] = 0.
The Finished messages are computed by evaluating a truly random function Fms
f,
which is only accessible to oracles sharing ms,
f and the full transcript containing all
previous messages is used to compute the Finished messages. If there is no oracle
∗
having a matching conversation to πis∗ , the adversary receives no information about
(1)
−µ
Fms
and
f (label3 ||m1 || · · · ||m12 ). Therefore we have Pr[break7 ] = 2
(1)
(1)
Pr[break6 ] ≤ Pr[break7 ] +
1
1
= µ.
2µ
2
Collecting probabilities from Game 0 to Game 7 yields Lemma 1.
Lemma 2. For any adversary A running in time t0 ≈ t, the probability that there exists
an oracle πis with ρ = Server that accepts maliciously is at most
d`
1
server ≤ d`
+ ` · sig + ddh + 2 · prf + µ
2λ
2
where all quantities are defined as stated in Theorem 4.
(2)
Beweis. Let breakδ be the event that occurs when the first oracle that accepts maliciously
in the sense of Definition 2.4 with ρ = Server in Game δ.
Game 0.
This game equals the AKE security experiment described in Section 2. Thus, for some
server we have
(2)
Pr[break0 ] = server .
3.2 Truncated TLS with Ephemeral Diffie-Hellman is a Secure AKE Protocol
Game 1.
In this game we add an abort rule. The challenger aborts, if there exists any oracle πis that
chooses a random nonce rC or rS which is not unique. With the same arguments as in
Game 1 from the proof of Lemma 1 we have
(2)
(2)
Pr[break0 ] ≤ Pr[break1 ] +
(d`)2
.
2λ
Game 2.
This game is identical, except for the following. The challenger guesses two random in$
dices (i∗ , s∗ ) ← [`] × [d]. If there exists an oracle πis that ‘accepts’ maliciously, and
(i, j) 6= (i∗ , j ∗ ) and πis has ρ 6= Server, then the challenger aborts the game. Note that if
the first oracle πis that ‘accepts’ maliciously has ρ = Server, then with probability 1/(d`)
we have (i, j) = (i∗ , j ∗ ), and thus
(2)
(2)
Pr[break1 ] = d` · Pr[break2 ].
Note that in this game the attacker can only break the security of the protocol, if oracle
∗
πis∗ is the first oracle that ‘accepts’ maliciously and has ρ = Server, as otherwise the
game is aborted.
Game 3.
The challenger proceeds as before, but we add an abort rule. We want to make sure that
∗
πis∗ receives as input exactly the Diffie-Hellman value m8 = TC that was selected by
some other uncorrupted oracle.
∗
Technically, we abort and raise event abortsig , if oracle πis∗ ever receives as input a
message m7 = certC indicating intended partner Π = j and message m9 = σC =
SIG.Sign(skC , m1 || . . . , ||m8 ) such that σC is a valid signature but there exists no oracle
πjt which has previously output σC . Clearly we have
(2)
(2)
P r[break2 ] ≤ Pr[break3 ] + Pr[abortsig ].
∗
Note that the experiment is aborted, if πis∗ does not accept maliciously, due to Game 2.
∗
This means that party Pj must be τj -corrupted with τj = ∞ (i.e., not corrupted) when πis∗
accepts. To show that Pr[abortsig ] ≤ `·sig , we construct a signature forger as follows. The
forger receives as input a public key pk ∗ and simulates the challenger for A. It guesses an
$
index φ ← [`], sets pkφ = pk ∗ , and generates all long-term public/secret keys as before.
Then it proceeds as the challenger in Game 3, except that it uses its chosen-message oracle
to generate a signature under pkφ when necessary.
If φ = j, which happens with probability 1/`, then the forger can use the signature
∗
received by πis∗ to break the EUF-CMA security of the signature scheme with success
probability sig , so Pr[abortsig ]/` ≤ sig . Therefore if Pr[abortsig ] is not negligible, then
sig is not negligible as well and we have
(2)
(2)
P r[break2 ] ≤ Pr[break3 ] + ` · sig .
Seite 43
Seite 44
Chapter 3 Transport Layer Security
∗
Note that in Game 3 oracle πis∗ receives as input a Diffie-Hellman value TC such that TC
was chosen by another oracle, but not by the attacker. Note also that this oracle is unique,
since the signature includes the client nonce rC , which is unique due to Game 1. From
∗
now on we denote this unique oracle with πjt ∗ .
∗
∗
Note also that πis∗ and πjt ∗ share a premaster secret pms = TCtS = TStC , where TC = g tC
∗
∗
and TS = g tS for random exponents tS and tC chosen by πis∗ and πjt ∗ , respectively.
Game 4.
∗
∗
In this game, we replace the premaster secret pms = g tC tS shared by πis∗ and πjt ∗ with
$
a random value g r , r ← Zq . The fact that the challenger has full control over the Diffie∗
∗
Hellman shares TC and TS exchanged between πis∗ and πjt ∗ , due to the modifications
introduced in the previous games, provides us with the leverage to prove indistinguishability under the Decisional Diffie-Hellman assumption.
∗
∗
Technically, the challenger in Game 4 proceeds as before, but when πis∗ and πjt ∗ compute
the premaster secret as pms = g tC tS , the challenger replaces this value with a uniformly
$
random value pms
g = g r , r ← Z∗p , which is in the following used by both partner oracles.
Suppose there exists an algorithm distinguishing Game 4 from Game 3. Then we can
construct an algorithm B solving the DDH problem as follows. Algorithm B receives as
input a DDH challenge (g, g u , g v , g w ). The challenger defines TC := g u and TS := g v
∗
∗
for the Diffie-Hellman shares chosen by πis∗ and πjt ∗ , respectively. Instead of computing
the Diffie-Hellman key as in Game 3, it sets pms = g w both for the ‘client’ and the
‘server’ oracle. Now if w = uv, then this game proceeds exactly like Game 3, while if w
is random than this game proceeds exactly like Game 4. The DDH assumption therefore
implies that
(2)
(2)
Pr[break3 ] ≤ Pr[break4 ] + ddh .
∗
∗
Note that in Game 4 the premaster secret of πis∗ and πjt ∗ is uniformly random, and independent of TC and TS . This will provide us with the leverage to replace the function
PRF(pms,
g ·) with a truly random function in the next game.
Game 5.
∗
∗
In Game 5 we make use of the fact that the premaster secret pms
g of πis∗ and πjt ∗ is
chosen uniformly random, and independent of TC and TS . We thus replace the value
ms = PRF(pms,
g label1 ||rC ||rS ) with a random value ms.
f
Distinguishing Game 5 from Game 4 implies an algorithm breaking the security of the
pseudo-random function PRF, thus
(2)
(2)
Pr[break4 ] ≤ Pr[break5 ] + prf .
Game 6.
∗
∗
In this game we replace the function PRF(ms,
f ·) used by πis∗ and πjt ∗ with a random
∗
∗
function. Of course the same random function is used for both oracles πis∗ and πjt ∗ . In
particular, this function is used to compute the Finished messages by both partner
oracles.
3.2 Truncated TLS with Ephemeral Diffie-Hellman is a Secure AKE Protocol
Distinguishing Game 6 from Game 5 again implies an algorithm breaking the security of
the pseudo-random function PRF, thus
(2)
(2)
Pr[break5 ] ≤ Pr[break6 ] + prf .
Game 7.
Finally we use that the full transcript of all messages sent and received is used to compute
the Finished messages, and that Finished messages are computed by evaluating a
∗
∗
truly random function that is only accessible to πis∗ and πjt ∗ due to Game 6. This allows to
∗
show that any adversary has probability at most 21µ of making oracle πis∗ accept without
∗
having a matching conversation to πjt ∗ .
Thus, this game proceeds exactly like the previous game, except that the challenger now
∗
∗
aborts if oracle πis∗ accepts without having a matching conversation to πjt ∗ . Therefore we
(1)
have Pr[break7 ] = 0.
The Finished messages are computed by evaluating a truly random function Fms
f,
which is only accessible to oracles sharing ms,
f and the full transcript containing all
previous messages is used to compute the Finished messages. If there is no oracle
∗
having a matching conversation to πis∗ , the adversary receives no information about
Fms
f (label3 ||m1 || · · · ||m10 ). Thus we have
(1)
(1)
Pr[break6 ] ≤ Pr[break7 ] +
1
1
= µ.
2µ
2
Collecting probabilities from Game 0 to Game 7 yields Lemma 2.
3.2.2 Indistinguishability of Keys
Lemma 3. For any adversary A running in time t0 ≈ t, the probability that A answers
the Test-challenge correctly is at most 1/2 + ke with
ke ≤ client + server + d` · (ddh + 2 · prf ) .
where client + server is an upper bound on the probability that there exists an oracle that
accepts maliciously in the sense of Definition 2.4 (cf. Lemmas 1 and 2) and all other
quantities are defined as stated in Theorem 4.
Beweis. Assume without loss of generality that the A always asks a Test-query such that
(3)
all conditions in Property 2 of Definition 2.4 are satisfied. Let breakδ denote the event
0
that b = b in Game δ, where b is the random bit sampled by the Test-query, and b0
is either the bit output by A or (if A does not output a bit) chosen by the challenger. Let
(3)
Advδ := Pr[breakδ ]−1/2 denote the advantage of A in Game δ. Consider the following
sequence of games.
Game 0.
This game equals the AKE security experiment described in Section 2. For some ke we
have
1
1
(3)
Pr[break0 ] = + ke = + Adv0 .
2
2
Seite 45
Seite 46
Chapter 3 Transport Layer Security
Game 1.
The challenger in this game proceeds as before, but it aborts and chooses b0 uniformly
random, if there exists any oracle that accepts maliciously in the sense of Definition 2.4.
Thus we have
Adv0 ≤ Adv1 + client + server ,
where client + server is an upper bound on the probability that there exists an oracle that
accepts maliciously in the sense of Definition 2.4 (cf. Lemmas 1 and 2).
Recall that we assume that A always asks a Test-query such that all conditions in Property 2 of Definition 2.4 are satisfied. In particular it asks a Test-query to an oracle πis
that ‘accepts’ after the τ0 -th query of A with intended partner Π = j, such that Pj is τj corrupted with τj > τ0 . Note that in Game 1 for any such oracle πis there exists a unique
‘partner oracle’ πjt such that πis has a matching conversation to πjt , as the game is aborted
otherwise.
Game 2.
$
The challenger in this game proceeds as before, but in addition guesses indices (i∗ , s∗ ) ←
[`] × [d]. It aborts and chooses b0 at random, if the attacker issues a Test(πis )-query with
(i, j) 6= (i∗ , s∗ ). With probability 1/(d`) we have (i, j) = (i∗ , s∗ ), and thus
Adv1 ≤ d` · Adv2 .
∗
Note that in Game 2 we know that A will issue a Test-query to oracle πis∗ . Note also that
∗
∗
πis∗ has a unique ‘partner’ due to Game 1. In the sequel we denote with πjt ∗ the unique
∗
∗
∗
oracle such that πis∗ has a matching conversation to πjt ∗ , and say that πjt ∗ is the partner of
∗
πis∗ .
Game 3.
∗
Let Ti∗ ,s∗ = g u denote the Diffie-Hellman share chosen by πis∗ , and let Tj ∗ ,t∗ = g v
∗
denote the share chosen by its partner πjt ∗ . Thus, both oracles compute the premaster
secret as pms = g uv .
The challenger in this game proceeds as before, but replaces the premaster secret pms of
∗
∗
$
πis∗ and πjt ∗ with a random group element pms
g = g w , w ← Zq . Note that both g u and
∗
∗
∗
g v are chosen by oracles πis∗ and πjt ∗ , respectively, as otherwise πis∗ would not have a
∗
matching conversation to πjt ∗ and the game would be aborted.
Suppose that there exists an algorithm A distinguishing Game 3 from Game 2. Then
we can construct an algorithm B solving the DDH problem as follows. B receives as
input (g, g u , g v , g w ). It implements the challenger for A as in Game 2, except that it
∗
∗
sets Ti∗ ,s∗ := g u and Tj ∗ ,t∗ := g v , and the premaster secret of πis∗ and πjt ∗ equal to
∗
∗
pms := g w . Note that B can simulate all messages exchanged between πis∗ and πjt ∗
properly, in particular the finished messages using knowledge of pms = g w . Since all
other oracles are not modified, B can simulate these oracles properly as well.
If w = uv, then the view of A when interacting with B is identical to Game 2, while if
$
w ← Zq then it is identical to Game 3. Thus, the DDH assumption implies that
Adv2 ≤ Adv3 + ddh .
3.2 Truncated TLS with Ephemeral Diffie-Hellman is a Secure AKE Protocol
Game 4.
∗
∗
In Game 4 we make use of the fact that the premaster secret pms
g of πis∗ and πjt ∗ is chosen
uniformly random. We thus replace the value ms = PRF(pms,
g label1 ||rC ||rS ) with a
random value ms.
f
Distinguishing Game 4 from Game 3 implies an algorithm breaking the security of the
pseudo-random function PRF, thus
Adv3 ≤ Adv4 + prf .
Game 5.
∗
∗
In this game we replace the function PRF(ms,
f ·) used by πis∗ and πjt ∗ with a random
s∗
t∗
function Fms
f . Of course the same random function is used for both oracles πi∗ and πj ∗ .
In particular, this function is used to compute the key material as
C→S
S→C
C→S
S→C
Kenc
||Kenc
||Kmac
||Kmac
:= Fms
f (label2 ||rC ||rS )
Distinguishing Game 5 from Game 4 again implies an algorithm breaking the security of
the pseudo-random function PRF. Moreover, in Game 5 the adversary always receives
a random key in response to a Test-query, thus receives no information about b0 , which
implies Adv5 = 0 and
Adv4 ≤ Adv5 + prf = prf .
Collecting probabilities from Game 0 to Game 5 yields Lemma 3.
Summing up probabilities from Lemmas 1 to 3, we obtain that
ttls ≤ client + server + ke
≤ 2 · (client + server ) + d` · (ddh + 2 · prf )
≤ 4 · max{client , server } + d` · (ddh + 2 · prf )
1
d`
+
`
·
+
+
2
·
+
d`
+
+
+ d` · (ddh + 2 · prf )
≤ 4 · d`
sig
ddh
prf
prfodh
prf
2λ
2µ
5
5
1
d`
+
`
·
+
·
+
·
·
+
d`
+
+
,
= 4 · d`
sig
ddh
prf
prfodh
prf
2λ
4
2
2µ
which yields Theorem 4.
Seite 47
Chapter 4 The ACCE Security Model
Chapter 4 The ACCE Security Model
An authenticated and confidential channel establishment (ACCE) protocol is a protocol
executed between two parties. The protocol consists of two phases, called the ‘pre-accept’
phase and the ’post-accept’ phase.
Pre-accept phase. In this phase a ‘handshake protocol’ is executed. In terms of functionality this protocol is an AKE protocol as in Section 2, that is, both communication partners are mutually authenticated, and a session key k is established. However,
it need not necessarily meet the security definition for AKE protocols (Definition 2.4). This phase ends, when both communication partners reach an accept-state
(i.e. Λ = ‘accept’).
Post-accept phase. This phase is entered, when both communication partners reach
an accept-state. In this phase data can be transmitted, encrypted and authenticated
with key k.
The prime example for an ACCE protocol is TLS. Here, the pre-accept phase consists of
the TLS Handshake protocol. In the post-accept phase encrypted and authenticated data
is transmitted over the TLS Record Layer.
To define security of ACCE protocols, we combine the security model for authenticated key exchange from Section 2 with stateful length-hiding encryption in the sense
of [PRS11]. Technically, we provide a slightly modified execution environment that extends the types of queries an adversary may issue.
4.1 Execution environment
The execution environment is very similar to the model from Section 2, except for a few
simple modifications. We extend the model such that in the post-accept phase an adversary is also able to ‘inject’ chosen-plaintexts by making an Encrypt-query,1 and chosenciphertexts by making a Decrypt-query. Moreover, each oracle πis keeps as additional
$
internal state a bit bsi ← {0, 1}, chosen at random at the beginning of the game, two counters u and v required for the security definition, and two state variables ste and std for
encryption and decryption with a stateful symmetric cipher. In the sequel we will furtherρ
ρ
more assume that the key k consists of two different keys k = (kenc
, kdec
) for encryption
and decryption. Their order depends on the role ρ ∈ {Client, Server} of oracle πis . This is
the case for TLS (see Section 3).
An adversary may interact with the provided oracles by issuing the following queries.
• Sendpre (πis , m): This query is identical to the Send-query in the AKE model from
Section 2, except that it replies with an error symbol ⊥ if oracle πis has state Λ =
‘accept’. (Send-queries in an accept-state are handled by the Decrypt-query below).
• Reveal(πis ) and Corrupt(Pi ): These queries are identical to the corresponding queries in the AKE model from Section 2.
• Encrypt(πis , m0 , m1 , len, H): This query takes as input two messages m0 and m1 ,
length parameter len, and header data H. If Λ 6= ‘accept’ then πis returns ⊥.
1 This
models that an adversary may trick one party into sending some adversarially chosen data. A practical
example for this attack scenario are cross-site request forgeries [ZF08] on web servers, or Bard’s chosenplaintext attacks on SSL3.0 [Bar04, Bar06].
Seite 49
Seite 50
Chapter 4 The ACCE Security Model
Otherwise, it proceeds as depicted in Figure 4.1, depending on the random bit
$
bsi ← {0, 1} sampled by πis at the beginning of the game and the internal state
variables of πis .
• Decrypt(πis , C, H): This query takes as input a ciphertext C and header data H.
If πis has Λ 6= ‘accept’ then πis returns ⊥. Otherwise, it proceeds as depicted in
Figure 4.1.
Figure 4.1: Encrypt and
Decrypt oracles in the
ACCE security experiment.
Encrypt(πis , m0 , m1 , len, H):
u := u + 1
(0)
ρ
, len, H, m0 , ste )
(C (0) , ste ) ← StE.Enc(kenc
$
(1) $
ρ
(C (1) , ste ) ← StE.Enc(kenc
, len, H, m1 , ste )
If C (0) = ⊥ or C (1) = ⊥ then return ⊥
s
(bs
i)
(Cu , ste ) := (C (bi ) , ste
Return Cu
)
Decrypt(πis , C, H):
v := v + 1
If bsi = 0, then return ⊥
ρ
(m, std ) = StE.Dec(kdec
, H, C, std )
If v > u or C 6= Cv , then phase := 1
If phase = 1 then return m
ρ
ρ
Here u, v, bsi , ρ, kenc
, kdec
denote the values stored in the corresponding internal variables of πis .
This behaviour of the Decrypt oracle in this combined definition for confidentiality and
integrity can be somewhat difficult to understand, so we give a brief explanation. From
a high level, when b = 0, the adversary always receives ⊥ from Decrypt queries. When
b = 1, if the adversary successfully manipulates the integrity of the scheme — either by
injecting a new valid ciphertext or messing around with the order of ciphertexts but still
getting them to successfully decrypt — then Decrypt outputs the message m which is not
equal to ⊥, so the adversary learns that b = 0 not 1.
Note that phase is stateful, so if it is ever set to 1 it remains 1. This allows the experiment
to capture the following property. Suppose the adversary calls Encrypt to get a (valid)
ciphertext C1 , then calls Decrypt on an invalid ciphertext C10 . Next, the adversary calls
Encrypt to get another (valid) ciphertext C2 , then calls Decrypt on C2 . Since the adversary
previously called Decrypt on an invalid ciphertext, it should be that std has diverge and
all future ciphertexts should decrypt: thus if C2 does decrypt successfully, the scheme
should be considered insecure.
4.2 Security Definition
Security of ACCE protocols is defined by requiring that (i) the protocol is a secure authentication protocol and (ii) in the post-accept phase all data is transmitted over an authenticated and confidential channel in the sense of Definition 1.13.
Again this notion is captured by a game, played between an adversary A and a challenger
C. The challenger implements the collection of oracles {πis : i ∈ [`], s ∈ [d]}. At the
beginning of the game, the challenger generates ` long-term key pairs (pki , ski ) for all i ∈
[`]. The adversary receives the public keys pk1 , . . . , pk` as input. Now the adversary may
start issuing Send, Reveal, Corrupt, Encrypt, and Decrypt queries. Finally, the adversary
outputs a triple (i, s, b0 ) and terminates.
4.3 Relation to the AKE Security Definition from Section 2
Definition 4.1
Seite 51
D
We say that an adversary (t, )-breaks an ACCE protocol, if A runs in time t, and at
least one of the following two conditions holds:
1. When A terminates, then with probability at least there exists an oracle πis
such that
• πis ‘accepts’ when A issues its τ0 -th query with partner Π = j, and
• Pj is τj -corrupted with τ0 < τj , and
• there is no unique oracle πjt such that πis has a matching conversation
to πjt .
If an oracle πis accept in the above sense, then we say that πis accepts maliciously.
2. When A terminates and outputs a triple (i, s, b0 ) such that
• πis ‘accepts’ when A issues its τ0 -th query with intended partner Π =
j, and Pj is τj -corrupted with τ0 < τj ,
• A did not issue a Reveal-query to πis , nor to πjt such that πis has a
matching conversation to πjt (if such an oracle exists), and
then the probability that b0 equals bsi is bounded by
|Pr[bsi = b0 ] − 1/2| ≤ .
If an adversary A outputs (i, s, b0 ) such that b0 = bsi and the above conditions
are met, then we say that A anwers the encryption-challenge correctly.
We say that an ACCE protocol is (t, )-secure, if there exists no adversary that (t, )breaks it.
Remark 8. Note that the above definition even allows to corrupt the oracle πis whose
internal secret bit the attacker tries to determine. Of course this is only allowed after πis
has reached an accept-state, in order to exclude trivial attacks. Thus, protocols secure
with respect to this definition provide perfect forward secrecy. Note also that again we allow the ‘accepting’ oracle to be corrupted even before it reaches an accept-state, which
provides security against key-compromise impersonation attacks.
4.3 Relation to the AKE Security Definition from Section 2
Note that an ACCE protocol can be constructed in a two-step approach.
1. (AKE part) First an authenticated key-exchange (AKE) protocol is executed. This
protocol guarantees the authenticity of the communication partner, and provides
a cryptographically ‘good’ (i.e., for the attacker indistinguishable from random)
session key.
2. (Symmetric part) The session key is then used in a symmetric encryption scheme
providing integrity and confidentiality.
Seite 52
Chapter 4 The ACCE Security Model
This modular approach is simple and generic, and therefore appealing. It can be shown formally that this two-step approach yields a secure ACCE protocol, if the ‘AKE part’ meets
the security in the sense of Definition 2.4, and the ‘symmetric part’ consists of a suitable
authenticated symmetric encryption scheme (e.g. secure according to Definition 1.13).
However, if the purpose of the protocol is the establishment of an authenticated confidential channel, then it is not necessary that the ‘AKE-part’ of the protocol provides full
indistinguishability of session keys. It actually would suffice if encrypted messages are
indistinguishable, and cannot be altered by an adversary. These requirements are strictly
weaker than indistinguishability of keys in the sense of Definition 2.4, and thus easier to
achieve (possibly from weaker hardness assumptions, or by more efficient protocols).
We stress that our ACCE definition is mainly motivated by the fact that security models
based on key indistinguishability do not allow for a security analysis of full TLS, as
detailed in the introduction. We do not want to propose ACCE as a new security notion
for key exchange protocols, since it is very complex and the modular two-step approach
approach seems more useful in general.
4.4 Choosing the Right Model
Authenticated key exchange (AKE) is a basic building block in modern cryptography. Many secure protocols for two-party and group key agreement have been proposed, including
generic compilers that transform simple key agreement protocols into authenticated key
agreement protocols, with many additional security properties. However, since many different formal models for different purposes exist, choice of the right model is not an easy
task, and must be considered carefully.
The main guideline for this choice is the fact that we cannot modify any detail of the TLS
protocol, nor of the network protocols preceding it.
First, we need a model were entity authentication is addressed as a security goal. This goal
is often omitted in newer models, in order to make them suitable for two-party authenticated key agreement protocols [Kra05]. However, explicit authentication is an important
security goal for TLS, in many practical applications authentication is more important
than encryption. For example, in a Single Sign-On scenario, an encrypted security token
may be passed from the identity provider through the browser to a relying party. Since the
security token itself is encrypted, confidentiality is not an issue, but the authenticity of the
channel through which this token was received is crucial.
Second, there is no way to modularize the security proof of TLS in the sense of [CK01],
since several protocol messages of TLS come without authenticator. Thus we cannot use
the authenticated link model (AM).
Third, we have chosen not to use a Universal Composability (UC) [Can01] approach.
We think that a formalization in the UC model first requires a thorough analysis in the
standard model. Since the exchange of nonces rC and rS in the first two messages of the
TLS Handshake can be regarded as an instantiation of the Barak compiler [BLR04], it
seems in principle possible to model TLS within the UC framework.
On the other hand, we have to make a choice about the enhanced adversarial capabilities newer models offer. We allow for RevealKey queries, but do not take into account
RevealState queries. The reason for this omittance is that in TLS there are several successive internal states: Computation of the premaster secret, computation of the master secret,
computation of the session keys. After transition from one state to another, internal data is
erased. So to be precise, we would have to specify several different RevealState queries,
4.4 Choosing the Right Model
which would have added tremendous complexity to both the model and the proof and
rendered the paper unreadable.
Seite 53
Chapter 5 TLS with Ephemeral Diffie-Hellman is a Secure ACCE Protocol
Chapter 5 TLS with Ephemeral Diffie-Hellman is a Secure
ACCE Protocol
Theorem 5. Let µ be the output length of PRF and let λ be the length of the nonces rC and
rS . Assume that the pseudo-random function PRF is (t, prf )-secure, the signature scheme
is (t, sig )-secure, the DDH-problem is (t, ddh )-hard in the group G used to compute the
TLS premaster secret, and the PRF-ODH-problem is (t, prfodh )-hard with respect to G
and PRF. Suppose that the stateful symmetric encryption scheme is (t, sLHAE )-secure.
Then for any adversary that (t0 , tls )-breaks the ephemeral Diffie-Hellman TLS protocol
in the sense of Definition 4.1 with t ≈ t0 holds that
5
5
1
1
d`
+ ` · sig + · ddh + · prf + · sLHAE + d` prfodh + prf + µ
.
tls ≤ 4·d`
2λ
4
2
4
2
To prove Theorem 5, we divide the set of all adversaries into two categories:
1. Adversaries that succeed in making an oracle accept maliciously. We call such an
adversary an authentication-adversary.
2. Adversaries that do not succeed in making any oracle accept maliciously, but
which answer the encryption-challenge. We call such an adversary an encryptionadversary.
We prove Theorem 4 by two lemmas. Lemma 4 bounds the probability client that
an authentication-adversary succeeds, Lemma 5 bounds the probability enc that an
encryption-adversary succeeds. Then we have
tls ≤ auth + enc .
We prove Theorem 5 via the following lemmas.
Lemma 4. For any adversary A running in time t0 ≈ t, the probability that there exists
an oracle πis that accepts maliciously is at most
d`
1
auth ≤ 2 · d`
+
`
·
+
+
2
·
+
d`
+
+
sig
ddh
prf
prfodh
prf
2λ
2µ
where all quantities are defined as stated in Theorem 5.
Note that auth ≤ client + server , where client is an upper bound on the probability that there exists an oracle with ρ = Client that accepts maliciously in the sense of Definition 4.1,
and server is an upper bound on the probability that there exists an oracle with ρ = Client
that accepts maliciously. We claim that
d`
1
client ≤ d`
+
`
·
+
d`
+
+
sig
prfodh
prf
2λ
2µ
d`
1
server ≤ d`
+ ` · sig + ddh + 2 · prf + µ
λ
2
2
and thus
auth ≤ client + server ≤ 2 · d`
d`
1
+
`
·
+
+
2
·
+
d`
+
+
.
sig
ddh
prf
prfodh
prf
2λ
2µ
Seite 55
Seite 56
Chapter 5 TLS with Ephemeral Diffie-Hellman is a Secure ACCE Protocol
The bounds on client and server are derived exactly like in the proofs of Lemma 1 and
Lemma 2, therefore we omit the details.
Lemma 5. For any adversary A running in time t0 ≈ t, the probability that A anwers
the encryption-challenge correctly is at most 1/2 + with
enc ≤ auth + d` (ddh + 2 · prf + sLHAE ) .
where auth is an upper bound on the probability that there exists an oracle that accepts
maliciously in the sense of Definition 4.1 (cf. Lemma 4) and all other quantities are defined
as stated in Theorem 5.
The proof of this lemma extends the proof of Lemma 3 by one game-hop that exploits the
sLHAE-security of the encryption scheme.
Beweis. Assume without loss of generality that the A always outputs (i, s, b0 ) such that
(4)
all conditions in Property 2 of Definition 4.1 are satisfied. Let breakδ denote the event
0
that b = b in Game δ, where b is the random bit sampled by the Test-query, and b0
is either the bit output by A or (if A does not output a bit) chosen by the challenger. Let
(4)
Advδ := Pr[breakδ ]−1/2 denote the advantage of A in Game δ. Consider the following
sequence of games.
Game 0.
This game equals the ACCE security experiment described in Section 2. For some enc we
have
1
1
(3)
Pr[break0 ] = + enc = + Adv0 .
2
2
Game 1.
The challenger in this game proceeds as before, but it aborts and chooses b0 uniformly
random, if there exists any oracle that accepts maliciously in the sense of Definition 4.1.
Thus we have
Adv0 ≤ Adv1 + auth ,
where auth an upper bound on the probability that there exists an oracle that accepts
maliciously in the sense of Definition 4.1 (cf. Lemma 4).
Recall that we assume that A always outputs (i, s, b0 ) such that all conditions in Property 2
of Definition 4.1 are satisfied. In particular it outputs (i, s, b0 ) such that πis ‘accepts’ after
the τ0 -th query of A with intended partner Π = j, and Pj is τj -corrupted with τj > τ0 .
Note that in Game 1 for any such oracle πis there exists a unique ‘partner oracle’ πjt such
that πis has a matching conversation to πjt , as the game is aborted otherwise.
Game 2.
$
The challenger in this game proceeds as before, but in addition guesses indices (i∗ , s∗ ) ←
[`] × [d]. It aborts and chooses b0 at random, if the attacker outputs (i, s, b0 ) with (i, j) 6=
(i∗ , s∗ ). With probability 1/(d`) we have (i, j) = (i∗ , s∗ ), and thus
Adv1 ≤ d` · Adv2 .
Chapter 5 TLS with Ephemeral Diffie-Hellman is a Secure ACCE Protocol
Seite 57
∗
Note that in Game 2 we know that A will output (i∗ , s∗ , b0 ). Note also that πis∗ has a
∗
unique ‘partner’ due to Game 1. In the sequel we denote with πjt ∗ the unique oracle such
∗
∗
∗
∗
that πis∗ has a matching conversation to πjt ∗ , and say that πjt ∗ is the partner of πis∗ .
Game 3.
The challenger in this game proceeds as before, but replaces the premaster secret pms of
∗
∗
$
πis∗ and πjt ∗ with a random group element pms
g = g w , w ← Zq . Note that both g u and
∗
∗
∗
g v are chosen by oracles πis∗ and πjt ∗ , respectively, as otherwise πis∗ would not have a
∗
matching conversation to πjt ∗ and the game would be aborted.
With the same arguments as in Game 3 in the proof of Lemma 3, we have
Adv2 ≤ Adv3 + ddh .
Game 4.
As in Game 4 in the proof of Lemma 3, we now make use of the fact that the premaster
∗
∗
secret pms
g of πis∗ and πjt ∗ is chosen uniformly random. We thus replace the value ms =
PRF(pms,
g label1 ||rC ||rS ) with a random value ms.
f
Distinguishing Game 4 from Game 3 implies an algorithm breaking the security of the
pseudo-random function PRF, thus
Adv3 ≤ Adv4 + prf .
Game 5.
∗
As in Game 5 in the proof of Lemma 3, we replace the function PRF(ms,
f ·) used by πis∗
∗
.
Of
course
the
same
random
function
is used for
and πjt ∗ with a random function Fms
f
t∗
s∗
both oracles πi∗ and πj ∗ . In particular, this function is used to compute the key material
as
C→S
S→C
C→S
S→C
Kenc
||Kenc
||Kmac
||Kmac
:= Fms
f (label2 ||rC ||rS )
Distinguishing Game 5 from Game 4 again implies an algorithm breaking the security of
the pseudo-random function PRF, thus we have
Adv4 ≤ Adv5 + prf .
∗
C→S
S→C
C→S
S→C
Note that in Game 5 the key material Kenc
||Kenc
||Kmac
||Kmac
of oracles πis∗ and
t∗
πj ∗ is uniformly random and independent of all TLS Handshake messages exchanged in
the pre-accept phase.
Game 6.
∗
∗
C→S
S→C
C→S
S→C
Now we use that the key material Kenc
||Kenc
||Kmac
||Kmac
used by πis∗ and πjt ∗
in the stateful symmetric encryption scheme uniformly at random and independent of all
TLS Handshake messages.
Seite 58
Chapter 5 TLS with Ephemeral Diffie-Hellman is a Secure ACCE Protocol
In this game we construct a simulator B that uses a successful ACCE attacker A to break
the security of the underlying sLHAE secure symmetric encryption scheme (Definition 1.13). By assumption, the simulator B is given access to an encryption oracle Encrypt
and a decryption oracle Decrypt. B embeds the sLHAE experiment by simply forwar∗
∗
ding all Encrypt(πis∗ , ·) queries to Encrypt, and all Decrypt(πjt ∗ , ·) queries to Decrypt.
Otherwise it proceeds as the challenger in Game 5.
Observe that the values generated in this game are exactly distributed as in the previous
game. We thus have
Adv5 = Adv6 .
If A outputs a triple (i∗ , s∗ , b0 ), then B forwards b0 to the sLHAE challenger. Otherwise it
outputs a random bit. Since the simulator essentially relays all messages it is easy to see
that an attacker A having advantage 0 yields an attacker B against the sLHAE security of
the encryption scheme with success probability at least 1/2 + 0 .
Since by assumption any attacker has advantage at most sLHAE in breaking the sLHAE
security of the symmetric encryption scheme, we have
Adv6 ≤ 1/2 + sLHAE .
Addig up probabilities from Lemmas 4 and 5, we obtain that
tls ≤ auth + enc
≤ 2 · auth + d` (ddh + 2 · prf + sLHAE )
d`
5
5
1
1
≤ 4 · d`
+ ` · sig + · ddh + · prf + · sLHAE + d` prfodh + prf + µ
2λ
4
2
4
2
which yields Theorem 5.
On Proving Security of TLS-DHE from Standard Assumptions
In this section we illustrate why we had to make the PRF-ODH-assumption in the proofs
of Lemmas 1 and 4, and why we can prove Lemma 2 based on the standard DDH assumption. In order to allow a comprehensive exposition, let us consider the simplified protocol
from Figure 5.1 which abstracts the TLS-DHE Handshake.
Let us start with an informal description of the issue. Suppose we are given a Clientadversary, that is, an adversary which always makes Client-oracle C := πis (i.e., a particular oracle πis with ρ = Client) accept maliciously with intended partner Π = S. Suppose
we want to argue that the adversary is not able to forge the finS -message received by C
(which we would have to, since the finS -message is the only message that cryptographically protects all messages previously received by πis , and thus is required to ensure that
πis has a matching conversation), and that we want to assume only that the PRF is secure
in the standard sense (Definition 1.11). Then at some point in the proof we would have to
replace the premaster secret computed by πis as pms = TStC = g tC tS with an independent
random value.
Note that in order to replace pms with a random value and argue in the proof with indistinguishability, we must not know any of the exponents tC and tS in TC = g tC and
TS = g tS , as otherwise we can trivially distinguish the real pms = g tC tS from a random
pms0 . The problematic property of TLS-DHE is, that an adversary may test whether the
challenger ‘knows’ tS , and then make Client-oracle πis accept maliciously only if this
holds. This works as follows.
Chapter 5 TLS with Ephemeral Diffie-Hellman is a Secure ACCE Protocol
Client C
Seite 59
Server S
$
rC ← {0, 1}λ
m1 := rC
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→
−
$
rS ← {0, 1}λ
tS ← Zq , TS := g tS mod p
σS := SIG.Sign(skS , (rC , rS , TS ))
m2 := (rS , TS , σS )
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
←
$
tC ← Zq , TC := g tC mod p
ms := PRF(TStC mod p, label1 ||rC ||rS )
f inC := PRF(ms, m1 ||m2 ||(TC , σC ))
σC := SIG.Sign(skS , (rC , rS , TS , TC ))
m3 := (TC , σC , f inC )
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→
−
ms := PRF(TCtS mod p, label1 ||rC ||rS )
f inS := PRF(ms, m1 || . . . ||m3 )
m4 := f inS
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
←
$
1. The adversary establishes a communication between two oracles πis (representing
the client C) and πjt (representing the server S) by simply forwarding the messages
m1 and m2 between C and S.
2. The C will respond with m3 = (TC , σC , finC ). This message is not forwarded.
3. Instead, the adversary corrupts some party P ∗ 6∈ {Pi , Pj }, and obtains the secret
key sk ∗ of this party. Then it computes
∗
$
a) T ∗ := g t mod p for random t∗ ← Zq ,
b) σ ∗ := SIG.Sign(sk ∗ ; (rC , rS , TS , T ∗ )) using the corrupted key sk ∗ ,
∗
c) ms∗ := PRF(TSt , label1 ||rC ||rS ) using knowledge of t∗ , and
d) fin∗C := PRF(ms∗ , m1 ||m2 ||(T ∗ , σ ∗ )).
and sends m∗3 := (T ∗ , σ ∗ , fin∗C ) to S. Note that S cannot determine that its communication partner has changed, because any messages previously received by S were
perfectly anonymous.
4. If S responds with a correct fin∗S message (note that the adversary is able to compute
∗
all keys, in particular pms∗ := TSt , since it ‘knows’ t∗ , and thus is able to verify
the validity of fin∗S ), then adversary concludes that the challenger ‘knows’ tS and
forges the required finS -message to make πis accept without matching conversations.
Otherwise the adversary aborts.
Note that the above adversary is a valid, successful adversary in the real security experiment. It does not issue any Reveal-query and only one Corrupt-query to an unrelated
party, such that the intended communication partner Π = S of C = πis remains uncorrupted, but still it makes C = πis ‘accept’ and there is no oracle that C has a matching
conversation to.
Figure 5.1: Abstraction
of the TLS-DHE handshake.
Seite 60
Chapter 5 TLS with Ephemeral Diffie-Hellman is a Secure ACCE Protocol
However, we will not be able to use this adversary in a simulated security experiment
where the challenger does not know the exponent tS of TS = g tS . Intuitively, the reason
is that in this case the challenger would first have to compute the Finished-message
fin∗S , where
fin∗S = PRF(ms, m1 || . . . ||m3 ) and
∗
ms = PRF(TSt , label1 ||rC ||rS ),
but ‘knowing’ neither tS = log TS , nor t∗ = log T ∗ . This is the technical problem we are
faced with, if we want to prove security under a standard assumption like DDH. Under
the PRF-ODH-assumption, we can however use the given oracle to compute first ms, and
from this the Finished-message fin∗S .
S ERVER - ADVERSARIES . Interestingly, the above technical problem does not appear if we
consider Server-adversaries (i.e., adversaries that make an oracle πis accept maliciously
with ρ = Server) instead of Client-adversaries. This is due to the asymmetry of the TLSDHE Handshake protocol. The reason is, that in this case the adversary is not allowed
to corrupt the intended partner of the server (in order to exclude trivial attacks), and is
therefore not able to inject an adversarially-chosen Diffie-Hellman share T ∗ . Note here
that the signature sent from the client to the server is computed over both Diffie-Hellman
shares received and chosen by the client. Therefore in this case the server is able to verify
whether its intended partner has received the correct Diffie-Hellman share, and thus the
standard DDH assumption is sufficient to prove security.
D ISALLOWING CORRUPTIONS . One possibility to circumvent the above problem, and
thus to avoid the PRF-ODH-assumption, is to consider a weaker security model. If we
disallow Corrupt-queries in the model, then the adversary will not be able to inject an
adversarially-chosen, validly signed Diffie-Hellman share. This prevents the above ‘test’
and again allows a proof under the DDH assumption. However, a security model without
corruptions is rather weak. Albeit it may be reasonable for certain applications, it is certainly not adequate for the way how TLS-DHE is used on the Internet.
A DOPTING Σ0 TO TLS. In [CK02] Canetti and Krawczyk describe a protocol called Σ0 ,
which exhibits many similarities to the TLS-DHE Handshake protocol and the simplified
protocol from Figure 5.1, but is provably secure under standard assumptions (in particular
under DDH instead of PRF-ODH). Let us discuss why the differences between Σ0 and
TLS-DHE, albeit subtle, are crucial.
In Figure 5.2 we describe a simple variant Σ of Σ0 , which essentially extends Σ0 with
a server nonce rS and replaces the MAC computed over identities in Σ0 with a MAC
(implemented with PRF) computed over all previous protocol messages. Note that these
messages include the identities, so the security analysis of Σ0 carries over to Σ.
The major difference between Σ0 and TLS-DHE is, that the client ‘accepts’ already after
receiving m2 . There is no message m4 sent from the server to the client (which thus need
not be simulated in a security experiment). This m4 -message is not required in Σ0 , since
the client Diffie-Hellman share g c is sent already in message m1 (before m2 !), and thus
finS can be contained in m2 .
We stress that one could make TLS-DHE provably secure under DDH by making it more
similar to Σ0 :
1. Include the client Diffie-Hellman share g c in
• the first message m1 of TLS-DHE and
• in the signature sent from client to server.
Chapter 5 TLS with Ephemeral Diffie-Hellman is a Secure ACCE Protocol
Client C
Seite 61
Server S
$
rC ← {0, 1}λ
$
tC ← Zq , TC := g tC mod p
m1 := (rC , TC )
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
→
$
rS ← {0, 1}λ
$
tS ← Zq , TS := g tS mod p
σS := SIG.Sign(skS , (rC , rS , TC , TS ))
ms := PRF(TCtS mod p, label1 ||rC ||rS )
finS := PRF(ms, m1 || . . . ||m3 )
m2 := (rS , TS , σS , finS )
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
←
ms := PRF(TStC mod p, label1 ||rC ||rS )
finC := PRF(ms, m1 ||m2 ||(TC , σC ))
σC := SIG.Sign(skS , (rC , rS , TS , TC ))
m3 := (TC , σC , finC )
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
→
2. Include all data in m4 of TLS-DHE into message m2 of TLS-DHE, and omit m4 .
This modification would allow to carry the security analysis of Σ0 from [CK02] over to
TLS-DHE, and thus allow a security proof under DDH instead of PRF-ODH (and the
additional standard assumptions on the security of the PRF, the signature scheme, and
(considering full TLS-DHE) the stateful encryption scheme).
This would of course require changes to the TLS-DHE protocol, and may therefore be
unrealistic. This section should therefore merely be seen as an additional discussion of
the issue analysed in this section.
I NCLUDING IDENTITIES IN THE CLIENT NONCE . Another way (the ‘engineeringapproach’) to circumvent the problem, and thus allow a proof under the DDH assumption
instead of PRF-ODH, is to modify TLS such that the client C is able to verify that the
server has indeed intended partner C, and not some third party C 0 . Note that the client
nonce rC is included in both signatures, in particular in the signature σS sent from the
server to the client. According to [DA99, DR06, DR08] the nonce rC consists of 28 random bytes (=224 bits). The only requirement on the nonces in the proof is that a collision
occurs with sufficiently small probability, for which 160 bits should be sufficient in practice. One could use the remaining 64 bits to encode an ‘identity’ that refers uniquely to
the client certificate. The server would have to check whether this identity matches the
received client certificate. This would, again, require changes to the TLS-DHE protocol,
and may therefore be unrealistic, even though these changes are minimal.
Figure 5.2: Provably
secure TLS-DHE Adopting Σ0 variant, adopted
to the client/server setting and our notation.
Chapter 6 Signed Diffie-Hellman SSH is a secure server-only ACCE protocol
Chapter 6 Signed Diffie-Hellman SSH is a secure server-only
ACCE protocol
While the Transport Layer Security (TLS) protocol secures web communication, as well
as e-mail transfer and many other network protocols, the Secure Shell (SSH) protocol1
provides secure remote login and rudimentary virtual private network (VPN) access. It is
of paramount importance to have strong cryptographic assurances of these protocols.
As we have already seen when studying TLS real-world protocols tend to be far more
complex than protocols typically studied in the academic literature (as MAP1, MAP2 and
AKEP1, cf. Section 2.4). These protocols include both key exchange and secure channel
communication, support negotiation of many combinations of cryptographic algorithms
and a variety of authentication modes, and have additional functionality such as renegotiation and error reporting. All of these can affect the practical and theoretical security of
the protocol.
At a high level, the parties run a cryptographic protocol to establish a secure channel,
then communicate arbitrary application data over that channel. More precisely, execution begins with a channel establishment phase, in which parties negotiate which set of
cryptographic parameters they intend to use, establish a shared session key, use long-term
keys for entity authentication (either server-only or mutual), and send key confirmation
messages. This is followed by the communication of application data over a secure channel which provides confidentiality and integrity using the session key from the channel
establishment phase. The secure channel is called the binary packet protocol in SSH. A
complicating factor for SSH (as well as TLS) is that some portions of the channel establishment phase take place in plaintext, and other portions are sent over the secure channel.
The overlap between the channel establishment phase and the secure channel can cause
complications in the analysis of these protocols.
For precision, we will use the following terminology:
• plaintext channel: communication that is not sent via authenticated encryption
using the session key;
• auth-enc channel: communication that is sent via authenticated encryption using
the session key;
• handshake phase: communication of protocol messages to perform entity authentication and establish a secure channel, consisting of a negotiation phase and a
sub-protocol (or ciphersuite) phase;2
• application data phase: communication of application data using the auth-enc
channel.
In this chapter, we analyze the security of single signed-DH SSH ciphersuites, in isolation,
following [BDK+ 14]. We first discuss the messages that are exchanged during a signed
Diffie-Hellman SSH-protocol run.
1 In
this paper, we refer exclusively to SSHv2 [YL06b, YL06a, YL06c].
note that ciphersuite happens to be a TLS-centric term. SSH does not define a single ciphersuite, instead
separately negotiating key exchange, encryption, and MAC algorithms. For consistency, in the case of SSH
we refer to a single combination of these algorithms as a ciphersuite.
2 We
Seite 63
Chapter 6 Signed Diffie-Hellman SSH is a secure server-only ACCE protocol
Figure 6.1: Overview of
SSH protocol flow.
Responder
negotiation
Initiator
plaintext channel
KEXINIT: nonce, ciphersuites
KEXREPLY: nonce, ciphersuites
KEXDH_INIT: g x
accept server
authentication
AUTHREQUEST: Enc(pkinit or pw or none)
auth-enc channel
AUTHOK† : Enc(pkinit )
sub-protocol (ciphersuite)
KEXDH_REPLY: g y , pkresp , sig
handshake phase
Seite 64
AUTHREQUEST† : Enc(pkinit , sig)
accept client
authentication
AUTHSUCCESS
Enc(application data)
†
application
data phase
denotes messages omitted for server-only/password auth.
6.1 Protocol description for SSH signed-Diffie–Hellman
ciphersuite
This description complements Figure 6.1.
6.1.1 Negotiation
The first two messages exchanged negotiate the ciphersuite.
1. Init → Resp: KEXINIT. The initiator is activated with a list sp
~ C of ciphersuite preferences, picks a random nonce rC , generates its KEXINIT message and updates the
per-session variables.
$
1. rC ← {0, 1}µ
2. KEXINIT ← (rC , sp
~ C)
3. π.ρ ← init
4. π.α ← in-progress
2. Resp → Init: KEXREPLY. The responder picks a random nonce rS , generates its
KEXREPLY message, negotiates the optimal ciphersuite and updates the per-session variables.
$
1. rS ← {0, 1}µ
2. KEXREPLY ← (rS , sp
~ S)
3. π.ρ ← resp
6.1 Protocol description for SSH signed-Diffie–Hellman ciphersuite
4. π.α ← in-progress
5. π.c ← neg(sp
~ C , sp
~ S );
3. Init. Upon receiving KEXREPLY, the initiator records the negotiated ciphersuite based
on its sp
~ C and the sp
~ S received from the responder:
1. π.c ← neg(sp
~ C , sp
~ S)
6.1.2 Signed-DH sub-protocol—all authentication modes
We define and name the i-th sub-protocol algorithm for the sub-protocol π.c that updates the per-session variables and sends the appropriate message as according to protocol
specification as SPπ.c .AlgIi or SPπ.c .AlgRi for the initiator and responder respectively.
4. Init → Resp: SPπ.c .AlgI1 → KEXDH_INIT. The initiator now starts the negotiated subprotocol, SPπ.c . The initiator generates and sends an ephemeral Diffie–Hellman key.
$
1. x ← Zqπ.c
x
2. e ← gπ.c
3. KEXDH_INIT ← e
5. Resp → Init: SPπ.c .AlgR1 → KEXDH_REPLY AND NEWKEYS. The responder generates
its ephemeral Diffie–Hellman key, computing a session identifier and session keys, and
signing a hash of the session identifier to provide authentication.
$
1. y ← Zqπ.c
y
2. f ← gπ.c
3. K ← ey
4. (π.sid, π.k) ← PRFπ.c (K, VC kVS kKEXINITkKEXREPLYkpkπ.c kekf )
5. σS ← SIGπ.c .SIG.Sign(skS,π.c , π.sid)
6. KEXDH_REPLY ← (f, pkS,π.c , σS )
where PRFπ.c (K, sid) is as defined in Figure 6.2 and (skS,π.c , pkS,π.c ) denotes the server’s long-term key pair in this sub-protocol.
The responder now also sends a distinguished message NEWKEYS indicating that all following communication sent by the responder will be over the auth-enc channel, using
StEπ.c .Enc.
6. Init → Resp : SPπ.c .AlgI2 → NEWKEYS. The initiator computes the session key and
verifies server authentication. We note that this algorithm combines verifying the server authentication (found below) with sending the appropriate authentication message
AUTHREQUEST.
1. K ← f x
Seite 65
Seite 66
Chapter 6 Signed Diffie-Hellman SSH is a secure server-only ACCE protocol
2. (π.sid, π.k) ← PRFπ.c (K, VC kVS kKEXINITkKEXREPLYkpkπ.c kekf )
3. If SIGπ.c .SIG.Vfy(pkS,π.c , σS , π.sid) = 0, then set π.α ← reject and terminate.
4. π.Π ← S, where PS is the party with public key pkS,π.c
The initiator also sends a distinguished message NEWKEYS indicating that all following
communication sent by the initiator will be over the auth-enc channel.
6.1.3 Sub-protocol—no client authentication
7. Init → Resp: SPπ.c .AlgI2 → AUTHREQUEST. In server-only authentication mode, the
client does not perform public key authentication. It still sends a message (now over the
auth-enc channel) indicating its username and a request for access without public key
authentication.
1. AUTHREQUEST ← usernamekserviceknone
8. Resp → Init: SPπ.c .AlgR2 → AUTHSUCCESS OR AUTHFAILURE. If username is
allowed access to service without authentication, the responder sets π.α ← accept;
otherwise, it sets π.α ← reject. Note that even if the server accepts, it leaves π.Π = ⊥
to indicate an unauthenticated peer.
1. If π.α = accept, send AUTHSUCCESS.
2. If π.α = reject, send AUTHFAILURE and terminate.
11. Init: SPπ.c .AlgI3 . If the initiator receives AUTHFAILURE over the auth-enc channel, it
sets π.α ← reject and terminates. If it receives AUTHSUCCESS, it sets π.α ← accept.
12. Init ↔ Resp: A PPLICATION DATA . The initiator and responder can now exchange
application data over the auth-enc channel.
6.1.4 Sub-protocol—password client authentication
7. Init → Resp: SPπ.c .AlgI2 → AUTHREQUEST. In mutual authentication mode using a
password, the client sends its password pw over the auth-enc channel.
1. AUTHREQUEST ← usernamekservicekpwkpw
8. Resp → Init: SPπ.c .AlgR2 → AUTHSUCCESS OR AUTHFAILURE. If username is
allowed to access service based on password pw, the responder sets π.α ← accept;
otherwise, it sets π.α ← reject. Note that if the server accepts, it sets π.Π = C, where
PC is username.
The server responds with a status message, sent over the auth-enc channel.
1. If π.α = accept, send AUTHSUCCESS.
2. If π.α = reject, send AUTHFAILURE and terminate.
6.1 Protocol description for SSH signed-Diffie–Hellman ciphersuite
11. Init: SPπ.c .AlgI3 . If the initiator receives AUTHFAILURE over the auth-enc channel, it
sets π.α ← reject and terminates. If it receives AUTHSUCCESS, it sets π.α ← accept.
12. Init ↔ Resp: A PPLICATION DATA . The initiator and responder can now exchange
application data over the auth-enc channel.
6.1.5 Sub-protocol—public-key client authentication
SSH in the case of mutual authentication differs from the server-only mode after the server
sends its Diffie–Hellman key exchange message KEXDH_REPLY, namely, from message 5
onwards.
7. Init → Resp: SPπ.c .AlgI2 → AUTHREQUEST. In mutual authentication mode using
public keys, the initiator sends (over the auth-enc channel) an authentication request message asking to perform client authentication using a given public key; the client does not
demonstrate possession of the corresponding private key at this point.
1. AUTHREQUEST ← usernamekservicekpublic-keyk0kalgkpkC,π.c where alg is
the name of the public key algorithm (RSA, DSA, ECDSA) and pkC,π.c is the
client’s public key for this ciphersuite.
8. Resp → Init: SPπ.c .AlgR2 → AUTHOK OR AUTHFAILURE. If username is not allowed
access to service by public-key authentication, it sets π.α ← reject.
The server responds with a status message, sent over the auth-enc channel.
1. If π.α = in-progress, send AUTHOK ← algkpkC,π.c .
2. If π.α = reject, send AUTHFAILURE and terminate.
9. Init → Resp: SPπ.c .AlgI3 → AUTHREPLY. The client computes its signature of session identifier and authentication information and sends it to the server over the auth-enc
channel.
1. A ← usernamekservicekpublic-keyk1kalgkpkC,π.c
2. σC ← SIGπ.c .SIG.Sign(skC,π.c , π.sid, A)
3. AUTHREPLY ← AkσC
10. Resp → Init: SPπ.c .AlgR3 → AUTHSUCCESS. The responder recomputes its own A0
value to see if it matches A, then verifies the client’s signature; if these checks pass, the
server accepts and sends a success method.
1. A0 ← usernamekservicekpublic-keyk1kalgkpkC,π.c
2. If A0 6= A, then π.α ← reject.
3. If SIGπ.c .SIG.Vfy(pkC,π.c , σC , π.sid, A) = 0, then π.α ← reject.
4. If π.α = in-progress, then π.α ← accept.
5. If π.α = accept, send AUTHSUCCESS.
Seite 67
Seite 68
Chapter 6 Signed Diffie-Hellman SSH is a secure server-only ACCE protocol
6. If π.α = reject, send AUTHFAILURE and terminate.
11. Init: SPπ.c .AlgI4 . If the initiator receives AUTHFAILURE over the auth-enc channel, it
sets π.α ← reject and terminates. If it receives AUTHSUCCESS, it sets π.α ← accept.
12. Init ↔ Resp: A PPLICATION DATA . The initiator and responder can now exchange
application data over the auth-enc channel.
6.2 Challenges with security proofs for SSH
Before we prove security of “Signed Diffie-Hellman”-SSH, we note a few challenges one
faces in the proofs, then show authentication and channel security in the server-only and
mutual authentication modes.
ACCE
As noted in the Introduction, challenges are often encountered when trying to analyze
real-world protocols. The first problem that arises when analyzing SSH is the fact that
the messages needed for client authentication are sent encrypted, allowing the adversary
to trivially win key indistinguishability in a standard authenticated key exchange security
experiment; this is resolved by switching to ACCE.
Collision-free hash function must be non-leaking
One feature of SSH is the fact that the hash value to be signed by both parties not only contains a transcript of the most important exchanged messages, but also the secret
Diffie-Hellman key computed by both parties. This poses a non-standard problem with
the definition of collision-free hash functions. To understand the problem, consider the
following function, constructed from a collision-resistant hash function H:
H ∗ (m||k) := H(m||k)||k
If the length of k is fixed, the function H ∗ also is a hash function with constant output
length |H()| + |k|, and it is collision-free since the prefix H(m||k) is collision-free. However, this counter-intuitive, but definition-conforming collision-free hash function may
compromise the security of the protocol: If the signature scheme used has message recovery (e.g. plain RSA Signatures), a (passive) adversary may learn the secret Diffie-Hellman
key by verifying the signature. We solve this problem by requiring that the first hash value
computation must be collision resistant, and that the concatenation of the two hash values
(session id computation and key derivation) must form a pseudorandom function. The
pseudorandomness property guarantees that no bits from the input leak when computing
the hash function.
The SSH PRF
The PRFc function described in Figure 6.2 is used in the SSH protocol to compute
two values: H, which will be used as the session ID (this value is later signed in the
KEXDH_REPLY and AUTHREPLY messages); and k1 kk2 kk3 kk4 kk5 kk6 (which are later used
as encryption keys, IVs, and authentication keys). PRFc computes these values using the
hash function Hc negotiated by the ciphersuite. While PRFc is superficially similar to
HMAC, it varies sufficiently that it merits independent analysis.
6.2 Challenges with security proofs for SSH
PRFc (K, x):
1: H ← Hc (xkK)
2: label ← [A, B, C, D, E, F ]
3: for i ∈ {1, . . . , 6} do
4:
ki ← Hc (KkHklabeli kH)
5: end for
6: return (H, k1 kk2 kk3 kk4 kk5 kk6 )
We cannot prove security for SSH from the assumption that Hc is a collision-resistant
hash function: in SSH the hash value H to be signed by both parties not only contains a
transcript of the most important exchanged messages, but also the secret Diffie-Hellman
key K computed by both parties. If Hc leaks information about K, the protocol cannot
be proven secure. Therefore we need the assumption that PRFc is a secure PRF, which is
how our security proof of SSH proceeds in the rest of this section.
Under the assumption that Hc is a random function, it is straightforward to see that PRFc
is a secure PRF.
Analysis of PRFc under weaker, standard-model assumptions on Hc is more challenging. One way of analyzing key derivation functions is Krawczyk’s extract-thenexpand paradigm [Kra10]. In this paradigm, first a pseudorandom key K ← H(SKM )
is extracted from the secret key material (such as the Diffie–Hellman shared secret) SKM using a hash function H, then application keying material KM ←
F (K, “1”kinfo)kF (K, “2”kinfo)k . . . is expanded from the pseudorandom key K using
a PRF F . Although PRFc does seemingly have an extract phase (line 1) and then an
expand phase (line 4), the extract-then-expand paradigm does not directly apply because
the pseudorandom key (H, in the case of PRFc ) is subsequently used in another area
of the SSH protocol: H is signed by the signature scheme and the signature is transmitted over the channel. Thus H and the signature on H must not leak anything about the
Diffie–Hellman shared secret.
It may be possible to adapt extract-then-expand to analyze the SSH PRF, but we leave
that as future work. Our main security proof of SSH is entirely standard model, so any
future work improving the analysis of PRFc from random oracle model to standard model
immediately yields a full standard model proof of SSH.
Session IDs vs. matching conversations
A secure authentication protocol can, loosely speaking, be defined as a protocol where
the success probabilities of active and passive adversaries are equal, up to a negligible
difference. There are two main possible formalizations of this concept: session IDs and
matching conversations. We initially tried to base our proof that SSH is a secure authentication protocol on the classical notion of matching conversations (when the two parties
have the same transcript of communication), in order to make our result comparable to
previous work. However, SSH itself makes this impossible, because of a special option to
negotiate keys more quickly: the SSH client may choose to start an abbreviated handshake,
by guessing which cryptographic parameters the server would accept, sending messages
KEXINIT and KEXDH_INIT simultaneously. The SSH server however may refuse this option, and in this case, the KEXDH_INIT message is discarded, and replaced by a new message KEXDH_INIT0 to the server. In such a scenario, an adversary may simply change the
original value of KEXDH_INIT arbitrarily, thus breaking the matching conversations condition, and nevertheless make both sessions accept. Instead, the SSH specification itself
suggests the use of a protocol-specific session ID, a hash value H over the initial handshake messages. This hash value is then used to generate and verify the signatures both on
client and server side.
Seite 69
Figure 6.2: Computation
of PRFc using Hc .
Seite 70
Chapter 6 Signed Diffie-Hellman SSH is a secure server-only ACCE protocol
PRF-ODH
Readers may wonder why we do not need the PRF-Oracle-Diffie–Hellman (PFR-ODH)
assumption used in the analysis of signed-DH in TLS [JKSS12, KPW13]. In TLS, a hypothetical adversary who can solve the CDH problem can make a client oracle accept
maliciously by intercepting all messages after ServerKeyExchange, and then faking a
valid ServerFinished message. At the same time, this adversary can refuse to cooperate
in breaking DDH by testing if the DDH challenge was embedded in the current session.
All this may not happen in SSH: here, acceptance directly depends on signature verification.
SHA-1 collisions exist
For any unique hash function, we know that collisions exist due to the pigeonhole principle. Thus there are algorithms that output a collision in constant time: it is just hardwired
into their code. So we do not show that if SSH is insecure then we could output some SHA1 collision; instead we give an algorithm that, if SSH is insecure, helps us in computing
new SHA-1 collisions.
6.3 Server-only-authentication mode
In this section we drop subscripts for ciphersuites: SSH denotes a single ciphersuite of
the signed-Diffie–Hellman SSH protocol described in Section 6, with signature scheme
SIG, Diffie–Hellman group of prime order q generated by g, and hash function H, and the
BSAE scheme StE.
The following theorem shows that, if the hash function H is collision-resistant, the signature scheme SIG is EUF-CMA-secure, the DDH problem for (g, q) is hard, the PRF is a
secure PRF, and the symmetric encryption is a secure BSAE scheme, then the (single ciphersuite) signed-Diffie–Hellman SSH protocol is a secure server-only ACCE protocol.
Theorem 6 (SSH is server-only-ACCE-secure). Let µ be the length of the nonces in
KEXINIT and KEXREPLY (µ = 128), nP the number of participating parties and nS the
maximum number of sessions per party. The algorithms B1 , . . . , B5 given in the proof of
the theorem are such that, for all algorithms A,
Advacce-so-auth
(A) ≤
SSH
(nP nS )2
EUF-CMA
A
+ Advcr
(B2A )
H (B1 ) + nP AdvSIG
2µ
and
Advacce-so-aenc
(A) ≤ Advacce-so-auth
(A)
SSH
SSH
prf
bsae
A
A
A
+ nP nS Advddh
g,q (B3 ) + AdvPRF (B4 ) + AdvStE (B5 )
and B1A , . . . , B5A have approximately the same running time as A.
Lemma 6 (Server-only auth.). The algorithms B1 and B2 explicitly given in the proof of
the lemma, are such that, for all algorithms A,
Advacce-so-auth
(A) ≤
SSH
(nP nS )2
EUF-CMA
A
+ Advcr
(B2A ) ,
H (B1 ) + nP AdvSIG
2µ
(6.1)
where nP , nS , and µ are as in the statement of Theorem 6, and B1A and B2A have approximately the same running time as A.
6.3 Server-only-authentication mode
Seite 71
Proof of Advacce-so-auth
(A) bound. The essence of the proof is the observation that accepSSH
tance of a client session is the result of a successful signature verification. To be able to
use this fact, we have to make sure that all session IDs are different (by aborting if a nonce
is chosen twice or if a collision occurs in the hash computation of the session ID).
(0)
Let breakδ be the event that occurs when a client session accepts maliciously in Game δ.
Game 0.
The game equals the ACCE security experiment. Thus,
(0)
Advacce-so-auth
(A) = Pr(break0 ) .
SSH
(6.2)
Game 1.
In this game we add an abort rule for non-unique nonces ri . Specifically the challenger
collects a list L of all cookies ri sampled by the challenger during the simulation. If one
cookie appears twice, we abort the simulation. Thus
(0)
(0)
Pr(break0 ) ≤ Pr(break1 ) +
(nP nS )2
.
2µ
(6.3)
Game 2.
In this game we exclude hash collisions. Note that in this game we can compute all session
keys and session identifiers honestly, and we maintain a list Coll, where all the input/output pairs of all executions of the hash function H are recorded. We abort if at any time a
pair (in, H(in)) is added to Coll such that there already exists an entry (in0 , H(in0 )) in
Coll with H(in) = H(in0 ) but in 6= in0 . Now we construct B1A as follows: B1 simulates
the SSH protocol and interacts with A. Whenever A wins the acce-so-auth game, B1 inspects the recorded simulation to see if a hash collision occured. If it did, B1 outputs this
collision. Since B1 finds a collision, we have that
(0)
(0)
A
Pr(break1 ) ≤ Pr(break2 ) + Advcr
H (B1 ) .
(6.4)
Game 3.
∗
In this game we exclude signature forgeries. We abort the simulation if some session πis∗
accepts after it receives a signature which was never output of a session with a matching
session identifier. Note that we have excluded nonce and hash collisions, so from now on
all values to be signed are different. Thus any abort event is related to a signature forgery.
Technically, we construct an algorithm B2A which simulates the SSH protocol as in Game
1. B2 interacts with A. B2 receives a public key pk from an EUF-CMA signature challenger for SIG, guesses which public key pkj ∗ the session will use to verify the signature
(which costs us a factor nP in the reduction) and sets pkj ∗ = pk. Since the signing key
has to be uncorrupted it is no problem for the reduction that the secret signing key is unknown. If B2 needs to sign a message on behalf of party Pj ∗ , it makes a signing query to
∗
the EUF-CMA challenger. If the session πis∗ maliciously accepts in Game 3, we know
from the discussion above that the maliciously accepting session has verified a signature
Seite 72
Chapter 6 Signed Diffie-Hellman SSH is a secure server-only ACCE protocol
σ 0 over a session ID H where there is no session πjt ∗ with the same session ID, thus this
signature was not generated with a call to the signature challenger. Thus B2 has found
(H, σ 0 ) as a signature forgery, so
(0)
(0)
EUF-CMA
Pr(break2 ) ≤ Pr(break3 ) + nP AdvSIG
(B2A ) .
(6.5)
Final analysis. Now all signatures are computed by legitimate parties only, and are all
computed for different session IDs. Thus there is no way for a session to accept maliciously, and we have
(0)
Pr(break3 ) = 0
Lemma 7 (Channel security, server-only auth. mode). The algorithms B3 , B4 , and B5 ,
explicitly given in the proof of the lemma, are such that, for all algorithms A,
prf
bsae
A
A
A
Advacce-so-aenc
(A) ≤ Advacce-so-auth
(A)+nP nS (Advddh
SSH
SSH
g,q (B3 )+AdvPRF (B4 )+AdvStE (B5 ))
(6.6)
where nP , nS , and µ are as in the statement of Theorem 6, and B3A , B4A , B5A have approximately the same running time as A.
(1)
(A) bound. Let breakδ be the event that occurs when A answers
Proof of Advacce-so-aenc
SSH
the encryption challenge correctly in Game δ.
Game 0.
This game equals the ACCE security experiment.
Game 1.
This game is identical to Game 3 of Lemma 6 and we abort if some session accepts
maliciously. With the previous sequence of games we ensured unique nonces, excluded
hash collisions and signature forgeries. Thus, in this game any session that accepts nonmaliciously has a unique uncorrupted partner session. From the previous proof, we have
(1)
(1)
Pr(break0 ) ≤ Pr(break1 ) + Advacce-so-auth
(A) .
SSH
(6.7)
∗
From now on, we always have a matching session for the session πis∗ where the adversary
tries to guess the random bit.
Game 2.
In this game, we guess the session for which the adversary outputs the bit b0 . We guess
two indices (i∗ , s∗ ) ∈ [nP ] × [nS ] and abort if the adversary outputs (i, s, b0 ) with
(i∗ , s∗ ) 6= (i, s). This happens with probability nP1nS . We then exploit that no client
session maliciously accepts due to Game 1, so we have that there exists a unique partner
∗
session πjt ∗ which can be easily determined by the simulator. Thus we have:
(1)
(1)
Pr(break1 ) ≤ nP nS · Pr(break2 ) .
(6.8)
6.4 Mutual authentication mode
Seite 73
Game 3.
∗
∗
In this game we replace the value K = g xy computed by πis∗ and πjt ∗ with a random value
K ∗ . Since we have excluded maliciously accepting sessions the adversary cannot influence these values. Any adversary A that can distinguish this game from the previous game
can directly be used to construct an adversary B3A that can break the DDH assumption:
let (g, g u , g v , g w ) be the DDH challenge. We set g x := g u and g y := g v , and K ∗ := g w .
If w = uv, then we have K ∗ = K, and we are in Game 2, otherwise we are in Game 3.
Thus
(1)
(1)
A
Pr(break2 ) ≤ Pr(break3 ) + Advddh
(6.9)
g,q (B3 ) .
Game 4.
∗
∗
In this game we replace the values H, k1 , ..., k6 computed by πis∗ and πjt ∗ as
PRF(K ∗ , sid) with random values H ∗ , k1∗ , ..., k6∗ . Any adversary A that can distinguish this game from the previous game can directly be used to construct an adversary
B4A that can break the PRF assumption: let S = H||k1 ||...||k6 be the output of PRF, and
let S ∗ = H ∗ ||k1∗ ||...||k6∗ be a random string of the same length. For S we are in Game 3,
and for S ∗ in Game 4. Thus
A
Pr(break3 ) ≤ Pr(break4 ) + Advprf
PRF (B4 ) .
(1)
(1)
(6.10)
Final analysis. We now have that the keys k1∗ , ..., k6∗ are information-theoretically independent from the key exchange messages. Thus any adversary A that can guess (i∗ , s∗ , b0 )
correctly can directly be used to construct an adversary B5A that breaks the BSAE scheme.
Technically we exploit the fact that all keys for the encryption scheme are independent
from the handshake and embed a BSAE challenger. Now we simply have to forward A’s
output to the challenger and thus we have
(1)
A
Pr(break4 ) ≤ Advbsae
StE (B5 ) .
(6.11)
Combining the probability bounds from Lemma 6 and Lemma 7 yields Theorem 6.
Remark 9. Forward secrecy. The ACCE definition of Jager et al. [JKSS12] can be extended to include forward secrecy, meaning that the adversary in the channel security
definition is allowed to corrupt the long-term key of the owner of the target session or
its peer after the target session has accepted. We have omitted forward secrecy from this
paper for simplicity, but the result can be easily extended to cover the case of forward secrecy, and the proof of Lemma 7 can be readily adapted using the techniques in [JKSS12].
6.4 Mutual authentication mode
In a similar manner, it can be shown that the (single ciphersuite) signed-Diffie–Hellman
SSH protocol has secure mutual authentication when the client uses public key authentication if the building blocks of SSH are secure, and thus is a secure ACCE protocol with
mutual authentication.
Theorem 7 (SSH is mutual-auth.-ACCE-secure). Let µ be the length of the nonces in
KEXINIT and KEXREPLY, nP the number of participating parties and nS the maximum
Seite 74
Chapter 6 Signed Diffie-Hellman SSH is a secure server-only ACCE protocol
number of sessions per party. The algorithms B1 , . . . , B5 , explicitly given in the proof of
the theorem, are such that, for all algorithms A,
Advacce-auth
(A) ≤
SSH
(nP nS )2
EUF-CMA
A
+ Advcr
(B2A )
H (B1 ) + nP AdvSIG
2µ
(6.12)
and
prf
bsae
A
A
A
Advacce-aenc
(A) ≤ Advacce-auth
(A)+nP nS Advddh
SSH
SSH
g,q (B3 ) + AdvPRF (B4 ) + AdvStE (B5 )
(6.13)
and B1A , . . . , B5A have approximately the same running time as A.
Lemma 8 (SSH has secure mutual authentication). There exist algorithms B1 and B2 ,
explicitly given in the proof of the lemma, such that, for all algorithms A,
Advacce-auth
(A) ≤
SSH
(nP nS )2
EUF-CMA
A
+ Advcr
(B2A ),
H (B1 ) + nP AdvSIG
2µ
where nP , nS , and µ are as in the statement of Theorem 7, and B1A and B2A have approximately the same running time as A.
Beweis. Again, for both client and server sessions, acceptance is the result of a successful
signature verification. Thus with exactly the same sequence of games as in Lemma 6, we
get the same bound.
Lemma 9 (SSH has channel security in mutual auth. mode). The algorithms B3 , B4 , and
B5 , explicitly given in the proof of the lemma, are such that, for all algorithms A,
(nP nS )2
(A) +
(A) ≤ Advacce-auth
Advacce-aenc
SSH
SSH
2µ
prf
bsae
A
A
A
+ nP nS Advddh
g,q (B3 ) + AdvPRF (B4 ) + AdvStE (B5 ) .
where nP , nS , and µ are as in the statement of Theorem 7, and B3A , B4A , B5A have approximately the same running time as A.
Beweis. Again, the proof is very similar to the proof of Lemma 7, with the same sequence
of games and the same bound.
Chapter 7 2-Message Protocols: HMQV
Seite 75
Chapter 7 2-Message Protocols: HMQV
The HMQV protocol is also used in practice. While a security proof for HMQV requires
the so-called forking Lemma and is therefore out of scope of this course, we nonetheless
want to present the protocol here.
Description of HMQV
Figure 7.1: The HMQV
protocol from [Kra05].
HMQV protocol
A
(pkA , skA ) = (A = g a , a)
B
(pkB , skB ) = (B = g b , b)
$
x ← {0, 1}κ ; X := g x
X
−−−−−−−−−−−−−−−−−
→
−
$
y ← {0, 1}κ ; Y := g y
ˆ
ˆ e := H(Y,
ˆ
ˆ
d := H(X,
B),
A)
k := H((X · Ad )y+eb )
ˆ
ˆ e := H(Y,
ˆ
ˆ
d := H(X,
B);
A)
e x+da
k := H((Y · B )
)
Y
−−−−−−−−−−−−−−−−−−
←
The HMQV protocol is very efficient, in that it requires only two messages to be exchanged and that it requires only few local computation by the participating parties.
Verzeichnisse
Seite 77
Verzeichnisse
I. Figures
Figure 1.1
Figure 1.2
Figure 1.3
Figure 1.4
Figure 1.5
Figure 2.1
Figure 2.2
Figure 2.3
Figure 3.1
Figure 3.2
Figure 4.1
Figure 5.1
Figure 5.2
Figure 6.1
Figure 6.2
Figure 7.1
Turing Machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Relation between classes P and NP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Relationship between classes P and NP and NP-Completeness. . . . . . . . . . . . . . . . . . . . .
Encrypt and Decrypt oracles in the stateful LHAE security experiment. . . . . . . . . . . . . . . .
Encrypt and Decrypt oracles in the BSAE security experiment . . . . . . . . . . . . . . . . . . . .
The MAP1 protocol from [BR94]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The MAP2 protocol from [BR94]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The AKEP1 protocol from [BR94]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TLS handshake for ciphersuites TLS_DHE_* with client authentication . . . . . . . . . . . . . . .
Computation of Client/Server Handshake Messages . . . . . . . . . . . . . . . . . . . . . . . . . .
Encrypt and Decrypt oracles in the ACCE security experiment. . . . . . . . . . . . . . . . . . . . .
Abstraction of the TLS-DHE handshake. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Provably secure TLS-DHE Adopting Σ0 variant, adopted to the client/server setting and our notation.
Overview of SSH protocol flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Computation of PRFc using Hc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The HMQV protocol from [Kra05]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
13
14
17
18
26
29
29
35
37
50
59
61
64
69
75
II. Definitionen
Definition 1.1:
Definition 1.2:
Definition 1.3:
Definition 1.4:
Definition 1.5:
Definition 1.6:
Definition 1.7:
Definition 1.8:
Definition 1.9:
Definition 1.10:
Definition 1.11:
Definition 1.12:
Definition 1.13:
Definition 1.14:
Definition 1.15:
Definition 2.1:
Definition 2.2:
Definition 2.3:
Definition 2.4:
Definition 4.1:
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
10
11
11
12
12
12
13
13
15
16
16
17
19
19
22
23
24
25
51
III. Literature
[ABR01] Michel Abdalla, Mihir Bellare, and Phillip Rogaway. The oracle Diffie-Hellman assumptions and an analysis of
DHIES. In David Naccache, editor, CT-RSA 2001, volume 2020 of LNCS, pages 143–158. Springer, April 2001.
[Bar04] Gregory V. Bard. The vulnerability of SSL to chosen plaintext attack. Cryptology ePrint Archive, Report 2004/111,
2004. http://eprint.iacr.org/.
Seite 78
Verzeichnisse
[Bar06] Gregory V. Bard. A challenging but feasible blockwise-adaptive chosen-plaintext attack on SSL. In Manu Malek,
Eduardo Fernández-Medina, and Javier Hernando, editors, SECRYPT, pages 99–109. INSTICC Press, 2006.
[BDK+ 14] Florian Bergsma, Benjamin Dowling, Florian Kohlar, Jörg Schwenk, and Douglas Stebila. Multi-ciphersuite
security of the secure shell (SSH) protocol. In ACM CCS 14, pages 369–381. ACM Press, 2014.
[BFCZ08] Karthikeyan Bhargavan, Cédric Fournet, Ricardo Corin, and Eugen Zalinescu. Cryptographically verified implementations for TLS. In Peng Ning, Paul F. Syverson, and Somesh Jha, editors, ACM CCS 08, pages 459–468. ACM
Press, October 2008.
[BFS+ 12] C. Brzuska, M. Fischlin, N.P. Smart, B. Warinschi, and S. Williams. Less is more: Relaxed yet composable
security notions for key exchange. Cryptology ePrint Archive, Report 2012/242, 2012. http://eprint.iacr.
org/.
[Ble98] Daniel Bleichenbacher. Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS
#1. In Hugo Krawczyk, editor, CRYPTO’98, volume 1462 of LNCS, pages 1–12. Springer, August 1998.
[BLR04] Boaz Barak, Yehuda Lindell, and Tal Rabin. Protocol initialization for the framework of universal composability.
Cryptology ePrint Archive, Report 2004/006, 2004. http://eprint.iacr.org/.
[BN00] Mihir Bellare and Chanathip Namprempre. Authenticated encryption: Relations among notions and analysis of
the generic composition paradigm. In Tatsuaki Okamoto, editor, ASIACRYPT 2000, volume 1976 of LNCS, pages
531–545. Springer, December 2000.
[BN08] Mihir Bellare and Chanathip Namprempre. Authenticated encryption: Relations among notions and analysis of the
generic composition paradigm. Journal of Cryptology, 21(4):469–491, October 2008.
[BPR00] Mihir Bellare, David Pointcheval, and Phillip Rogaway. Authenticated key exchange secure against dictionary
attacks. In Bart Preneel, editor, EUROCRYPT 2000, volume 1807 of LNCS, pages 139–155. Springer, May 2000.
[BR93] Mihir Bellare and Phillip Rogaway. Random oracles are practical: A paradigm for designing efficient protocols. In
V. Ashby, editor, ACM CCS 93, pages 62–73. ACM Press, November 1993.
[BR94] Mihir Bellare and Phillip Rogaway. Entity authentication and key distribution. In Douglas R. Stinson, editor,
CRYPTO’93, volume 773 of LNCS, pages 232–249. Springer, August 1994.
[BR06] Mihir Bellare and Phillip Rogaway. The security of triple encryption and a framework for code-based game-playing
proofs. In Serge Vaudenay, editor, EUROCRYPT 2006, volume 4004 of LNCS, pages 409–426. Springer, May / June
2006.
[BWJM97] Simon Blake-Wilson, Don Johnson, and Alfred Menezes. Key agreement protocols and their security analysis.
In Michael Darnell, editor, 6th IMA International Conference on Cryptography and Coding, volume 1355 of LNCS,
pages 30–45. Springer, December 1997.
[Can01] Ran Canetti. Universally composable security: A new paradigm for cryptographic protocols. In 42nd FOCS, pages
136–145. IEEE Computer Society Press, October 2001.
[CD09] S. Chaki and A. Datta. Aspier: An automated framework for verifying security protocol implementations. In
Computer Security Foundations Symposium, 2009. CSF ’09. 22nd IEEE, pages 172 –185, july 2009.
[CJNP00] Jean-Sébastien Coron, Marc Joye, David Naccache, and Pascal Paillier. New attacks on PKCS#1 v1.5 encryption.
In Bart Preneel, editor, EUROCRYPT 2000, volume 1807 of LNCS, pages 369–381. Springer, May 2000.
[CK01] Ran Canetti and Hugo Krawczyk. Analysis of key-exchange protocols and their use for building secure channels.
In Birgit Pfitzmann, editor, EUROCRYPT 2001, volume 2045 of LNCS, pages 453–474. Springer, May 2001.
Literature
Seite 79
[CK02] Ran Canetti and Hugo Krawczyk. Security analysis of IKE’s signature-based key-exchange protocol. In Moti Yung,
editor, CRYPTO 2002, volume 2442 of LNCS, pages 143–161. Springer, August 2002. http://eprint.iacr.
org/2002/120/.
[Cre09] Cas J. F. Cremers. Session-state reveal is stronger than ephemeral key reveal: Attacking the NAXOS authenticated
key exchange protocol. In Michel Abdalla, David Pointcheval, Pierre-Alain Fouque, and Damien Vergnaud, editors,
ACNS 09, volume 5536 of LNCS, pages 20–33. Springer, June 2009.
[DA99] T. Dierks and C. Allen. The TLS Protocol Version 1.0. RFC 2246 (Proposed Standard), January 1999. Obsoleted
by RFC 4346, updated by RFCs 3546, 5746.
[DR06] T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.1. RFC 4346 (Proposed Standard), April 2006. Obsoleted by RFC 5246, updated by RFCs 4366, 4680, 4681, 5746.
[DR08] T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246 (Proposed Standard), August 2008. Updated by RFCs 5746, 5878.
[DY83] Danny Dolev and Andrew Chi-Chih Yao. On the security of public key protocols. IEEE Transactions on Information
Theory, 29(2):198–207, 1983.
[FPZ08] Pierre-Alain Fouque, David Pointcheval, and Sébastien Zimmer. HMAC is a randomness extractor and applications
to TLS. In Masayuki Abe and Virgil Gligor, editors, ASIACCS 08, pages 21–32. ACM Press, March 2008.
[GMP+ 08] Sebastian Gajek, Mark Manulis, Olivier Pereira, Ahmad-Reza Sadeghi, and Jörg Schwenk. Universally Composable Security Analysis of TLS. In Joonsang Baek, Feng Bao, Kefei Chen, and Xuejia Lai, editors, ProvSec, volume
5324 of LNCS, pages 313–327. Springer, 2008.
[JK02] Jakob Jonsson and Burton S. Kaliski Jr. On the security of RSA encryption in TLS. In Moti Yung, editor, CRYPTO 2002, volume 2442 of LNCS, pages 127–142. Springer, August 2002.
[JKSS12] Tibor Jager, Florian Kohlar, Sven Schäge, and Jörg Schwenk. On the security of TLS-DHE in the standard model.
In Reihaneh Safavi-Naini and Ran Canetti, editors, CRYPTO 2012, volume 7417 of LNCS, pages 273–293. Springer,
August 2012.
[Kal98] B. Kaliski. PKCS #1: RSA Encryption Version 1.5. RFC 2313 (Informational), March 1998. Obsoleted by RFC
2437.
[KOS10] Eike Kiltz, Adam O’Neill, and Adam Smith. Instantiability of RSA-OAEP under chosen-plaintext attack. In Tal
Rabin, editor, CRYPTO 2010, volume 6223 of LNCS, pages 295–313. Springer, August 2010.
[KP09] Eike Kiltz and Krzysztof Pietrzak. On the security of padding-based encryption schemes - or - why we cannot
prove OAEP secure in the standard model. In Antoine Joux, editor, EUROCRYPT 2009, volume 5479 of LNCS, pages
389–406. Springer, April 2009.
[KPW13] Hugo Krawczyk, Kenneth G. Paterson, and Hoeteck Wee. On the security of the TLS protocol: A systematic
analysis. In Ran Canetti and Juan A. Garay, editors, CRYPTO 2013, Part I, volume 8042 of LNCS, pages 429–448.
Springer, August 2013.
[Kra01] Hugo Krawczyk. The order of encryption and authentication for protecting communications (or: How secure is
SSL?). In Joe Kilian, editor, CRYPTO 2001, volume 2139 of LNCS, pages 310–331. Springer, August 2001.
[Kra05] Hugo Krawczyk. HMQV: A high-performance secure Diffie-Hellman protocol. In Victor Shoup, editor, CRYPTO 2005, volume 3621 of LNCS, pages 546–566. Springer, August 2005.
[Kra10] Hugo Krawczyk. Cryptographic extraction and key derivation: The HKDF scheme. In Tal Rabin, editor, CRYPTO 2010, volume 6223 of LNCS, pages 631–648. Springer, August 2010.
Seite 80
Verzeichnisse
[KT11] Ralf Küsters and Max Tuengerthal. Composition theorems without pre-established session identifiers. In Yan Chen,
George Danezis, and Vitaly Shmatikov, editors, ACM CCS 11, pages 41–50. ACM Press, October 2011.
[LLM07] Brian A. LaMacchia, Kristin Lauter, and Anton Mityagin. Stronger security of authenticated key exchange. In
Willy Susilo, Joseph K. Liu, and Yi Mu, editors, ProvSec, volume 4784 of LNCS, pages 1–16. Springer, 2007.
[Mit98] John C. Mitchell. Finite-state analysis of security protocols. In Alan J. Hu and Moshe Y. Vardi, editors, CAV,
volume 1427 of LNCS, pages 71–76. Springer, 1998.
[MSW08] Paul Morrissey, Nigel P. Smart, and Bogdan Warinschi. A modular security analysis of the TLS handshake
protocol. In Josef Pieprzyk, editor, ASIACRYPT 2008, volume 5350 of LNCS, pages 55–73. Springer, December 2008.
[MSW10] Paul Morrissey, Nigel P. Smart, and Bogdan Warinschi. The TLS handshake protocol: A modular analysis.
Journal of Cryptology, 23(2):187–223, April 2010.
[MT10] Ueli Maurer and Björn Tackmann. On the soundness of authenticate-then-encrypt: formalizing the malleability of
symmetric encryption. In Ehab Al-Shaer, Angelos D. Keromytis, and Vitaly Shmatikov, editors, ACM CCS 10, pages
505–515. ACM Press, October 2010.
[OF05] Kazuhiro Ogata and Kokichi Futatsugi. Equational Approach to Formal Analysis of TLS. In ICDCS, pages 795–804.
IEEE Computer Society, 2005.
[Pau99] Lawrence C. Paulson. Inductive Analysis of the Internet Protocol TLS. ACM Trans. Inf. Syst. Secur., 2(3):332–351,
1999.
[PRS11] Kenneth G. Paterson, Thomas Ristenpart, and Thomas Shrimpton. Tag size does matter: Attacks and proofs for
the TLS record protocol. In Dong Hoon Lee and Xiaoyun Wang, editors, ASIACRYPT 2011, volume 7073 of LNCS,
pages 372–389. Springer, December 2011.
[PW10] Kenneth G. Paterson and Gaven J. Watson. Plaintext-dependent decryption: A formal security treatment of SSHCTR. In Henri Gilbert, editor, EUROCRYPT 2010, volume 6110 of LNCS, pages 345–361. Springer, May 2010.
[Sho04] Victor Shoup. Sequences of games: a tool for taming complexity in security proofs. Cryptology ePrint Archive,
Report 2004/332, Nov 2004.
[Tur37] A. M. Turing. On computable numbers, with an application to the entscheidungsproblem. Proceedings of the
London Mathematical Society, s2-42(1):230–265, 1937.
[WS96] David Wagner and Bruce Schneier. Analysis of the SSL 3.0 protocol. In Proceedings of the Second USENIX
Workshop on Electronic Commerce, pages 29–40. USENIX Association, 1996.
[YL06a] T. Ylonen and C. Lonvick. The Secure Shell (SSH) Authentication Protocol. RFC 4252 (Proposed Standard),
January 2006.
[YL06b] T. Ylonen and C. Lonvick. The Secure Shell (SSH) Protocol Architecture. RFC 4251 (Proposed Standard), January
2006.
[YL06c] T. Ylonen and C. Lonvick. The Secure Shell (SSH) Transport Layer Protocol. RFC 4253 (Proposed Standard),
January 2006.
[ZF08] William Zeller and Edward W. Felten. Cross-site request forgeries: Exploitation and prevention. Technical report,
October 2008. Available at http://from.bz/public/documents/publications/csrf.pdf.