Classical Security Protocols for QKD Systems

Nikolaos Papanikolaou
Rajagopal Nagarajan
Department of Computer Science, The University of Warwick

Abstract
The purpose of this report is to document the three principal classes of classic cryptographic protocols which are needed in systems for quantum key distribution. We
will detail the protocols used for secretkey reconciliation by public discussion, privacy amplication by public discussion, and unconditionally secure authentication.
We suggest the use of the model checking method for the analysis of these protocols
and the verication of relevant security requirements; the model checking technique
is described, and the PRISM model checker is presented.
Key words: quantum cryptography secret-key reconciliation privacy
amplication authentication unconditional security model checking

Introduction

The term quantum key distribution (QKD) refers to a set of procedures

which involve the preparation, manipulation and measurement of quantum
states for establishing a common secret key between two or more users; for
the purposes of discussion, we will restrict ourselves to the case of two users,
Alice (the initiator) and Bob (the receiver or responder).
A number of cryptographic protocols implementing quantum key distribution
have been proposed in the literature, among them BB84 [12], B92 [14] and E91
[19]. The use of quantum phenomena for key establishment provides benets
which are otherwise unachievable, namely:
a communications channel that guarantees a certain degree of privacy;
the detection of any attacker with an arbitrarily high probability.

The basic structure of a QKD protocol is roughly as follows. Firstly, Alice

prepares a nite set of quantum particles in a known physical state; she then
applies a particular transformation of her choice to each, and sends the particles to Bob over a quantum channel. Not knowing which transformation Alice
has applied to each particle, Bob performs a quantum measurement of each
and records the outcome. Then Alice and Bob discuss whether his measurements are compatible with her chosen transformations, and any discrepancies
between the two are located and discarded. After this stage of the protocol,
Alice and Bob share a common bit string, known as the raw key. Under ideal
conditions and in the absence of an attacker, this is the same as the nal secret
key.
However, additional procedures normally need to be performed in order to
provide a high level of security (i.e. in order to ensure the privacy of the key).
Not only does a basic QKD protocol with the above structure fail to produce
a secret key in the presence of an attacker, but it fails to provide a unique,
common key in the presence of noise on the communications channel. Furthermore, it does not dierentiate between legitimate users and the attacker. In
order to address these issues, three techniques must be used:
authentication, a technique for ascertaining the identity of a particular user,
so that an impersonation attempt is prevented;
reconciliation, a technique for detecting and correcting any discrepancies
between Alices and Bobs bit strings by disclosing a minimal amount of
information to an attacker;
privacy amplication, a technique for distilling the nal secret key from a
longer, less secure bit string shared by Alice and Bob.
It has been shown [11] that the BB84 protocol [12], if supplemented by reconciliation and privacy amplication procedures, is unconditionally secure (i.e.
the nal key is guaranteed to be secret) against all attacks permitted by the
laws of quantum mechanics. Furthermore, an authentication scheme is known
[13] which is also unconditionally secure in the information-theoretic sense.
It should be noted that the techniques currently known for reconciliation [18],
privacy amplication [16], and unconditionally secure authentication [13] do
not involve the exploitation of any quantum mechanical phenomena and thus
are referred to as classical.
Classical communication protocols and security protocols have always been
regarded as ideal targets for automated verication, i.e. for analysis by computer. Automated verication techniques include model checking and theorem
proving, and are theoretically founded on sound mathematical principles, such
as those of the theory of automata. The former of the two, which is of most
interest to us here, involves an exhaustive search of all possible scenarios that

may arise in practice, including possible attack strategies. This leads to the
e cient detection of protocol aws, and contributes in a direct way to ensuring protocol correctness and suitability for particular applications, even before
the protocols are actually implemented in practice.
Wellknown tools for automated verication of classical security protocols include FDR [5], Mur [6], Brutus [7] and the NRL Protocol Analyzer [8]. Theoretical approaches to this problem include BAN Logic [9], Strand Spaces [10],
and the inductive approach [2] associated with the HOL theorem prover. A
widely known result in the area of automated verication of classical protocols
is the discovery, by Gavin Lowe [3], of a subtle aw in the NeedhamSchroeder
Public Key protocol using the FDR model checker.
1.1 Roadmap
This report will detail some of the most important classical protocols needed
in the design of any practical QKD system, and it will present directions for
research in the formal verication of these protocols. We will discuss the Shell
and Cascade protocols for secret-key reconciliation by public discussion [18],
the privacy amplication techniques discussed in [16], and the WegmanCarter
scheme for unconditionally secure authentication. These will be dealt with in
sections 2, 3 and 4 respectively.
Section 5.1 discusses the model checking technique and presents the probabilistic model checking tool PRISM; this section is based on [32].
1.2 Setup
We assume in the following discussion that Alice and Bob are able to communicate through two channels with dierent properties, namely a quantum
channel for performing QKD and an authenticated public channel. Formally,
the setup involves the two users, Alice and Bob, an attacker Eve, and two
channels between Alice and Bob with the following specications:
(1) a classicalchannel, with perfect authenticity but no privacy;
(2) a quantumchannel, with imperfect privacy but perfect authenticity.
The objective of Alice and Bob, after having performed a basic QKD protocol
on the quantum channel obtaining respective bit strings A and B of length
n, is to establish a shorter, common secret string S. After reconciliation of
strings A and B is performed, a common string T is produced, of length n:
The process of privacy amplication discards some of the bits in T , resulting in

S. Both reconciliation and privacy amplication are performed on the classical

channel. In both cases, the essential goal is to minimize (and when possible
eliminate completely) the amount of correct information Eve has about T and
S.

SecretKey Reconciliation Protocols

The reconciliation problem is to design a protocol RP that runs on strings A

and B to produce a secret string S, while exchanging a minimal quantity Q
of information regarding S over the public channel. We write:
RP (A; B) = [S; Q]
to express the function of protocol RP , and we denote the average amount
of information leaked to an attacker during the protocol by IE (SjQ). The
reconciliation problem forms the object of L. Salvails M.Sc. thesis [20] and
is also presented in [18]; in both of these sources, the emphasis is put on the
design of e cient and implementable reconciliation protocols.
2.1 Components of Reconciliation Protocols
Reconciliation protocols are made up of particular building blocks, also known
as primitives. Primitives usually operate on binary strings (i.e. strings w 2
f0; 1gn for particular n), typically Alices and Bobs strings A; B or substrings
of these. The most common primitives and their interrelationships are presented in this section. The primitives discussed include the computation of
the parity of a given string, an interactive binary search procedure, a procedure for determining whether two strings match, and more. The terminology
used here, and the naming conventions, are based on [20]. The primitives
PARITE, DICHOT, DIPAR, CONFIRME, DICONF will be detailed
in turn. Before proceeding to consider the reconciliation protocols Shell (originally known as Coquille, see [20]) and Cascade [18], a typical so-called
protocol kernel will be presented.
2.1.1 The PARITE Primitive
PARITE is a primitive which Alice and Bob use in order to determine
whether any corresponding substrings of A and B have equal parity (parity is even, i.e. has value 0, when there is an even number of 1s in a string;
similarly, it is odd and had value 1 if there is an odd number of 1s in a string).
4

Ai and Bi denote the ith bit in Alices and Bobs sequence, respectively;
the symbol denotes bitwise exclusive disjunction (the XOR operation). The
PARITE primitive is as follows.
(1) Alice sends to Bob the value:
p :=

n
M

Ai

n
M

Bi

i=1

(2) Bob privately computes the value:

p0 :=

i=1

(3) Bob computes (p p0 ) to determine whether there is an odd or even

number of errors in his received sequence (B) and communicates this to
Alice.
Example 1 Suppose A = f1; 0; 1; 1; 1g and B = f1; 1; 1; 1; 1g. Running PARITE(A; B)
gives p = 0, p0 = 1, and p p0 = 1. Hence there is an odd number of errors in
B, in this example evidently only one.
2.1.2 The DICHOT Primitive
DICHOT is a distributed variation of the binary search algorithm, in which
Alice and Bob recursively divide A and B and compare the parities of corresponding blocks until a discrepancy is found. This allows Alice and Bob to
locate an error in B without divulging the values of individual bits in the
string (except for the erroneous one). DICHOT only succeeds if there is an
odd number of errors. The steps of DICHOT are as follows.
(1) If jAj = 1, then Bob requests the value of A explicitly and Alice sends it
to him. Then the primitive completes successfully.
(2) Otherwise, Alice privately splits A into two halves:
left half : A^ = fA1 ; A2 ; : : : ; AbjAj=2c g
right half : A^0 = fAbjAj=2+1c ; AbjAj=2+2c ; : : : ; AjAj g
(3) Similarly, Bob privately splits B into:
^ = fB1 ; B2 ; : : : ; BbjBj=2c g
left half: B
^ 0 = fBbjBj=2+1c ; BbjBj=2+2c ; : : : ; BjBj g
right half: B
^ B).
^
(4) Alice and Bob perform PARITE(A;

^ B)
^ (recursive
(5) If (pA 6= pB ), then Alice and Bob perform DICHOT(A;
call with left halves).
^ 0 ) (recursive
(6) If (pA = pB ), then Alice and Bob perform DICHOT(A^0 ; B
call with right halves).
Example 2 Suppose A = f1; 0; 1; 1; 1g and B = f1; 1; 1; 1; 1g. Calling DICHOT(A; B)
^ = f1; 1g, for which pA = 1 and pB = 0 reproduces A^ = f1; 0g and B
spectively. The recursive call DICHOT(f1; 0g; f1; 1g) is then made, setting
^ = f1g and pA = pB = 1, so the next recursive call is made on the right
A^ = B
halves of f1; 0g and f1; 1g, i.e. DICHOT(f0g; f1g). Since the length of the
arguments is now 1, the error in the second location of B has been found. In
order to implement DICHOT in practice, the index (with respect to A and
^ must be recorded, so that the actual index
B) of the rst element in A^ and B
of the error can be returned.
A related primitive, known as DIPAR, performs a parity check and calls
DICHOT if the parities of its arguments do not match. We write:
DIPAR(A; B) := If PARITE(A; B) = false then DICHOT(A; B)
DIPAR is used in the protocol Cascade, described later.
2.1.3 The CONFIRME Primitive
The CONFIRME primitive allows Bob to determine if his bit string, B,
diers from A. CONFIRME succeeds in detecting a discrepancy between
A and B (if there is indeed one) with probability 12 ; however, if A and B
are identical, CONFIRME is guaranteed to detect this. If CONFIRME is
applied repeatedly, namely k times, to A and B, it has a probability of failure
of 21k . CONFIRME consists of the following steps:
(1) Alice and Bob decide publicly (i.e. over the public channel) on a random
subset of A and B by choosing a random bit string
2 f0; 1gn
where i = 1 indicates that the ith bit of Alices and Bobs sequences
will be used in the following calculation.
(2) Alice and Bob compare the parities of the chosen subset of A and B
(denoted by A or A, and by B or B respectively, where denotes
bitwise conjuction). In other words, they perform PARITE( A; B).
(3) If (p0 6= p) then Bob knows that A 6= B. Otherwise he concludes A = B.
CONFIRME is part of the DICONFk primitive, discussed next. An illustration of CONFIRME is shown in Example 3.
6

2.1.4 The DICONFk Primitive

DICONFk is a combination of DICHOT and CONFIRME which can correct up to k errors in Bobs received string. The idea of this primitive is to
run CONFIRME repeatedly (k times) on A and B until a random subset
of these containing an error is found; then this particular subset is searched
using DICHOT until the index of the error is located, and this is then corrected. So, every time CONFIRME nds an error, that error is corrected
and the whole procedure is applied to the corrected bit string. Importantly,
DICONFk only succeeds if there is an odd number of errors in Bobs string.
The steps of DICONFk are shown in detail below.
(1) If (k = 1) then return B.
(2) c := CONFIRME (A; B) :
(3) If (c = false) then:
(a) loc := DICHOT( A; B):
0
(b) Bloc
:= Bloc :
(4) Else if (c = true) then B 0 := B:
(5) DICONFk 1 (A; B 0 )
Example 3 Suppose A = f0; 1; 0; 1; 1; 1g and B = f0; 0; 0; 1; 0; 0g. Three errors have occurred. We will run DICONF1 (A; B):
Let = f0; 0; 0; 0; 1; 0g be the random subset chosen by Alice and Bob when
CONFIRME is run; in other words, the chosen subset consists of the second
last bit of A and B respectively. The parities of the subsets are

p=
p0 =

6
M

i=1
6
M

i Ai

= (0 0)

(0 1)

(0 0)

(0 1)

(1 1)

(0 1) = 1

i Bi

= (0 0)

(0 0)

(0 0)

(0 1)

(0 1)

(0 0) = 0

i=1

Since (p0 6= p), Alice and Bob have detected that A 6= B. They now run
BINARY and locate the discrepancy between A5 and B5 . The error is corrected and the procedure nishes with B 0 = f0; 0; 0; 1; 1; 0g.
2.1.5 Kernels for Reconciliation Protocols
A kernel for a reconciliation protocol is a minimum-distance decoding procedure that Bob performs on his received sequence in order to correct some
errors. In [20], the complexity and optimality of such procedures is studied
in detail. The following protocol kernel, which is of interest to us, has been

shown to be optimal for an adequate choice of the integer k. We will name it

KERNEL1 .
(1) Alice and Bob choose at random a function f : f0; 1gn ! f0; 1gk , where
k is a parameter to be determined. The description of f is disclosed on
the public channel.
(2) Alice sends Bob the value of f (A):
(3) Bob computes a sequence B 0 with a minimum Hamming distance from
B, such that f (B 0 ) = f (A). He replaces B by B 0 .
The problem with KERNEL1 is that it involves a random choice between
all functions from binary strings of length n to binary strings of length k
n
(there are 2k2 of these). Assuming k > nh(p), where h(p) is the entropy of
a Bernoulli trial with probability p, to represent such a function one needs
to store k2n bits, and therefore the process of choosing and evaluating such a
function is computationally expensive.
It turns out that we can impose a constraint on the class of functions from
which f is chosen in KERNEL1 , and still maintain optimality. The universal2
hash functions proposed by Wegman and Carter [13] can be used in this context. The operation of selecting at random a universal2 hash function is e cient, and these functions can be computed e ciently also. In practice, the
kernels used in reconciliation protocols involve a random choice of f from the
class of universal2 hash functions.
Denition 4 (universal2 functions) Let H be a class of functions with domain A and co-domain B. The class H is said to be universal2 if, for every
pair of distinct elements x; y 2 A,
H (x; y)

jHj
jBj

where H (x; y) denotes the number of functions in H which map x and y to

the same element in B.
The Cascade reconciliation protocol simply uses the DIPAR primitive as a
kernel, according to [20, p.60].
2.2 The Shell Reconciliation Protocol
The Shell protocol combines the kernel described in section 2.1.5 with the
DICONFk primitive in order to reconcile Alices and Bobs bit strings A
and B. Shell starts by splitting Alices and Bobs sequences into blocks, and
then performs the kernel on each block. For each block, DICONF1 is applied
8

repeatedly in order to locate and correct errors; then pairs of adjacent blocks
are joined together, and the procedure is repeated on the resulting superblocks.
The steps of Shell are detailed below. Each repetition of the procedure is
referred to as a pass.
(1) Alice and Bob split their bit strings into disjoint blocks of length k,
namely
for Alice : A0 [1]; A0 [2]; : : : ; A0 [dn=ke]
for Bob : B0 [1]; B0 [2]; : : : ; B0 [dn=ke]
(2) Alice and Bob perform KERNEL1 (A0 [1]; B0 [1]), KERNEL1 (A0 [2]; B0 [2]),
. . . , KERNEL1 (A0 [dn=ke]; B0 [dn=ke]) in that order.
(3) s := 0: This variable is used as a subscript specifying the current pass.
The following is lrepeated
(s + 1) times.
m
n
(a) For 1 6 i 6 2s k repeat the following:
(i) Alice and Bob perform DICONF1 (As [i]; Bs [i]):
(ii) If Bob locates an error, he asks Alice for the contents of the
whole block that contains the error. He replaces his correspondm block with the block sent by Alice.
l ing
(b) If 2ns k > 1 do the following:
(i) s := s + 1:
(ii) Alice and Bob concatenate the block left of the current one with
the block to the right of the current one and this forms the block
used in the next pass ( denotes concatenation of binary strings):
As [i] : = As 1 [2i
Bs [i] : = Bs 1 [2i

1] As 1 [2i]
1] Bs 1 [2i]

The Shell protocol is optimal, in the sense that the average amount of information gained by an attacker (his equivocation) is minimal. However Shell has
a substantial running time and is not e cient enough to be used for practical
purposes. The Cascade protocol, described next, is more e cient.
2.3 The Cascade Reconciliation Protocol
Reconciliation protocols and the primitives they involve make extensive use of
parity checks; thus, some of the primitives for detecting and correcting errors
can only succeed if there is an odd number of errors in the pairs of strings or
substrings to which they are applied. It follows that an e cient reconciliation
protocol is one which splits Alices and Bobs strings into substrings with an
odd number of errors as frequently as possible. In order to reduce the number
of misses, a protocol should vary the block size used at each pass and perform
parity calculations repeatedly. The Shell protocol has a xed block size k,
9

which is established at the beginning of the protocol; on each pass, the size
of the block is doubled, since adjacent blocks from pass s are joined together
to form the block in pass s + 1. The Cascade protocol, on the other hand, is
distinguished by the following two characteristics:
varying block sizes at each pass;
a random permutation is chosen and applied to the current block at each
pass.
Below is a listing of the Cascade protocol.
(1) Alice sets A0 := A.
(2) Bob sets B0 := B:
(3) For 1 6 i 6 repeat the following:
(a) Alice and Bob select at random a permutation i of f1; 2; : : : ; ng and
exchange the details of this permutation over the public channel.
(b) Alice computes the string Ai := i (Ai 1 ).
(c) Bob computes the string Bi := i (Bi 1 ).
(d) For 1 6 j 6 dn=k1 e repeat the following:
(i) Alice and Bob run DIPAR(Aki i [j]; Biki [j]):
(ii) If Bob corrects a single error in B, then Alice and Bob run
procedure CASCOR, which is detailed in [20].
The CASCOR procedure starts with a block containing an odd number of
errors and splits it repeatedly until all the errors have been corrected. The
idea is to perform the splitting so that on each iteration of CASCOR there
is an odd number of errors to correct, and the details of how this is performed
are to be found in L. Salvails M.Sc. thesis, cited above.
2.4 Summary
In this section we have considered several primitives for detecting and correcting errors in Bobs received bit string, assuming the scenario/setup established
in Section 1.2. Most of the primitives detailed in section 2.1 are combined together to form other primitives (e.g. DICONFk combines BINARY and
CONFIRM, and both of the latter make use of PARITE). Reconciliation
protocols make use of a kernel, which is a basic decoding procedure for correcting some errors in Bobs string. Kernels involve a random choice of a binary
decoding function, and in practice the universal2 class of hash functions is
used. The Shell protocol for reconciliation makes use of a kernel which selects
among universal2 functions, and the protocol has been shown to be optimal
but ine cient [20]. Finally, the Cascade protocol is more e cient than Shell,
and is characterised by a varying choice of block size and the use of a random
permutation.
10

Privacy Amplication Protocols

As discussed in section 1, the purpose of a privacy amplication protocol is to

minimize, and if possible to eliminate completely, any information gained by
the attacker, Eve, by eavesdropping on the classical and/or quantum channel.
Note that the process of reconciliation leaks a certain amount of information
to Eve about the common key T shared by Alice and Bob, since parities
of various subsets of T are disclosed during this process, and information
such as which bits are kept, and which are discarded, is disclosed on the
classical channel. Remember that Eve is allowed to eavesdrop on the classical
channel, but since this channel is authenticated and assumed to be perfect,
Eve cannot tamper with any of the transmissions made thereupon. However,
Eve is assumed to be able to tamper with the quantum channel, e.g. she is able
to delete transmissions, to inject errors etc. In principle, it is quite possible for
Eve to prevent communications between Alice and Bob through this channel
completely; however this particular scenario is of little theoretical interest,
because in this case any attempt at key establishment is impossible.
Privacy amplication comes in several avours, depending on the assumptions
made about the information available to Eve regarding Alices and Bobs keys.
In [15,16] three cases are considered:
(1) The case in which no eavesdropping has occurred on the classical channel during reconciliation, but tampering and transmission errors have
occurred on the quantum channel (public channel eavesdropping).
(2) The case in which a limited amount of eavesdropping has occurred on
the classical channel (and has been detected), but a reconciliation protocol has not been performed (presumably because neither transmission
errors nor tampering are assumed to have occurred). The fact that no
reconciliation protocol has been performed at all deprives Eve of useful
information regarding the key shared by Alice and Bob (private channel
eavesdropping).
(3) The case in which eavesdropping has occurred on the classical channel,
and a reconciliation has been performed by Alice and Bob. This is the
most general case (public and private channel eavesdropping).
We consider only the rst two cases here for simplicity, basing the discussion
primarily on [17,15].
3.1 Reducing the Information of a Public Channel Eavesdropper
Let f : f0; 1gn ! f0; 1gk be the decoding function used during reconciliation
(we assume only KERNEL1 is executed) in this particular case. Eves knowl11

edge includes the description of f and the value of f (T ). Thus Eve knows the
set of all binary strings with length k which are similar to T (i.e. strings Z
with a Hamming distance dist(Z; T ) 6 ` for ` chosen by Eve):
C = fZ 2 f0; 1gn j f (Z) = f (T )g
For Eve, all elements of C are equally probable candidates for T .
A protocol (which we will call PA1 ) for reducing Eves information about T
is given below. The security parameter s is a value between 0 and (n k).
(1) Alice chooses at random a function
g : f0; 1gn ! f0; 1gn

k s

(2) Alice sends a description of g to Bob over the classical/public channel.

(3) Alice and Bob apply g to their (common) strings, so that the nal secret
key is S = g(T ).
This protocol produces a nal key S of length (n k s) such that the average
information Eve has about S is less than log2 (1 + 2 s ) bits (from [15]).
Protocol PA1 is too ine cient to be used in practice, since the description of
g will require the transmission of up to (n k s)2n bits. In order to improve
the e ciency of the procedure, g can be selected at random from a restricted
class of functions. According to [15,16], a good choice is to use the class of
equitable functions, dened as follows.
Denition 5 If i < j, a function f : f0; 1gj ! f0; 1gi is equitable if jY j =
2j i , where Y = fxjf (x) = ag, for every binary string a of length i.
Protocol PA2 is identical to PA1 , except for the fact that the function g is
selected at random from the class of equitable functions. The average information Eve has about the nal key S in this case is the same as for PA1 ,
i.e. log2 (1 + 2 s ) bits. Examples of equitable functions that can be used in
PA2 include g1 (x) = x div 2k+s and g2 (x) = x mod 2n k s , which are both
computable in linear time.
A further variation on PA1 arises when we restrict the choice of g to the class of
universal2 hash functions. An example of such a protocol [15], which we will call
PA3 , is shown below. This protocol assumes that reconciliation has been done
using KERNEL1 , with the decoding function fa;b (x) = (ax+b) mod p mod 2k .
The class of functions ffa;b ja; b 2 Zp and a 6= 0g is universal2 [13,15].
(1) Alice xes the function
ga;b (x) = (ax + b) mod p div 2k
12

where a; b are the same values that were used in the decoding function
for reconciliation.
(2) Alice sends a description of ga;b to Bob over the classical/public channel.
(3) Alice and Bob apply g to their (common) strings, so that the nal secret
key is S = ga;b (T ).
The average information gained by Eve, if PA3 is used, is bounded above by
the value of 2 bits (for a proof, see [15, p.40]).
3.2 Reducing the Information of a Private Channel Eavesdropper
If Eve eavesdrops on the private/quantum channel, and no reconciliation is
performed at all, then Eve gains a certain amount of information on the key T
established by Alice and Bob, but is deprived of highly valuable information
regarding T that would have been disclosed over the public channel. In this
case, the information about T available to Eve consists of the set
E = fZ 2 f0; 1gn j e(Z) = e(T )g
where e : f0; 1gn ! f0; 1gk is a function chosen randomly by Eve (and unknown to Alice and Bob). This function e represents the kbit information
Eve has about T . Alice and Bob only have a previously agreed upper bound
on k. Since Alice and Bob do not have complete knowledge of E, it is not
possible for them to eliminate Eves information with certainty.
Alice and Bob need to agree on some function g : f0; 1gn ! f0; 1gr , for some
r 6 n k, so that knowledge of e; e(x); and g leaves Eve with an arbitrarily
small fraction of 1 bit of information about g(x). Diering in the manner
in which the function g is chosen, two privacy amplication protocols are
available in this case lets call them PA4 and PA5 . In PA4 , g is chosen
uniformly at random from the set of all functions f0; 1gn ! f0; 1gr . For this
protocol, the expected amount of information on g(x) gained by knowledge of
e; g; e(x) where e : f0; 1gn ! f0; 1gk , s < n k, r = (n k s) is at most
2 s
bits.
ln 2
In protocol PA5 , the function g(x) is selected from the class of strongly
universal2 hash functions [13,15]. The expected amount of information gained
s
by Eve on g(x) is the same as before, i.e. at most 2ln 2 bits.

13

Protocols for Unconditionally Secure Authentication

The protocols for secret-key reconciliation and privacy amplication discussed

in the previous sections assume the existence of an authenticated public channel linking Alice and Bob. The purpose of this section is to briey describe
an unconditionally secure technique for providing that authentication capability. An authentication procedure must be applied before a QKD protocol
is performed, and hence well before reconciliation and privacy amplication
protocols.
Alice and Bob authenticate by sending each other a xed message M 2 f0; 1gq
with an authentication tag t = v(M ), where v is a function that they have
agreed on. In order to agree on the function v, they need to share a short,
common bit string w. We assume that w is established once, when Alice and
Bob meet in person prior to the key exchange procedure. Wegman and Carter
[13] have proposed that the function used to compute the authentication tag
should be chosen at random from the class of strongly universal2 hash functions.
However, if v is chosen at random from this class of functions, the length of the
message M becomes unnecessarily large. Unconditionally secure authentication can equally well be provided using a function v which is "almost strongly
universal2 . This class of functions is dened as follows.
Denition 6 Let M and J be nite sets, and call the functions from M to J
hash functions. Let " be a positive real number. A set H of hash functions
is "almost strongly universal2 if the following two conditions are satised:
(1) The number of hash functions in H that takes an arbitrary m1 2 M to
.
an arbitrary j1 2 J is exactly jHj
jJj
(2) The fraction of those hash functions that also takes an arbitrary m2 6= m1
in M to an arbitrary j2 2 J (possibly equal to j1 ) is no more than ".
Example 7 An example of a 1almost strongly universal2 family of functions
is the jJj hash functions dened by hi (m) = (m + i) mod jJj.
Let H be an "almost strongly universal2 family of hash functions. Assume
that Alice and Bob share a common bit string w just large enough to be able
to agree on a hash function hk 2 H, 0 6 k < jHj: In order for Alice to
authenticate herself to Bob:
(1) Alice sends Bob a message m1 and the tag t = hk (m1 ).
(2) Bob receives m1 and a (potentially tampered) tag t0 .
(3) Bob then computes hk (m1 ) and compares it with t0 . If they match, Bob
accepts the message as authentic, i.e. as originating from Alice.
This protocol, and variations thereof, can be used to provide an authentication

14

capability in a QKD system [4].

Techniques for Analysing Security Protocols for QKD

5.1 Automated Verication by Model Checking

The amount of intelligence a computing machine can demonstrate has always
been hotly debated; however, computers nowadays do have limited ability in
assisting human reasoning and constructing mathematical proofs automatically. This is the result of many years development of formal, mechanical
techniques for analysing system behaviour. Indeed, the study of automated
verication, as it is known, is an important part of any computer scientists
training [21]. Automated verication techniques include theorem proving and
model checking.
On the one hand, theorem proving tools provide mechanical assistance in
developing logical proofs. To show the validity of a given statement, a theorem
prover aids the user in applying the inference rules of a particular logic, and
maintains a history of the steps taken.
Model checking, on the other hand, is a procedure involving three main steps:
constructing an abstract model of a given system (system specication); dening the properties desired of the system in a form that can be checked automatically (property specication); and feeding the model into an appropriate
software tool (verication). A model checker then employs its builtin algorithms to prove, with little or no user intervention, whether the system model
satises the properties given.
The latter of these two approaches to verication has been used in our work
to investigate the properties of certain quantum protocols. In particular, we
have used logical model checking [22] and probabilistic model checking [23] to
assess the BB84 protocol [12] for quantum key distribution. For details, see
[32,34].
Firstly, we will discuss, in turn, the three phases of model checking. This
includes an inquiry into the syntax of description languages and temporal
logic.
5.1.1 System Specication, and Description Languages
System specication is arguably the most crucial step when performing model
checking for a particular problem. The system to be analysed has to be de15

scribed accurately in some generalpurpose specication language; the description, or model, must incorporate all the salient features of the systems
behaviour, and particularly those aspects of the system relevant to verication.
For a general communications protocol, there are several levels of abstraction
at which a description can be made; frequently in protocol verication the
emphasis is put on concurrency aspects and timing. It is of utmost importance
that all users of a protocol interact in the correct order, and that data is
not lost due to synchronisation errors. At this level of abstraction, however,
it is immaterial what data representation is used, or whether a particular
compression algorithm is involved. A suitable protocol model for analysing
timing and other concurrencyrelated issues will abstract away from lowlevel
considerations such as those just mentioned.
The situation is similar, but certainly more complex, in the analysis of security
protocols. A suitable model in this case must take into account the details of
encrypting and decrypting procedures, the availability and secrecy of keys,
and the nature of the communication channels used. A specication language
for security protocols will necessarily be more expressive than one intended
for the protocols of the previous paragraph.
The use of process calculi as specication languages for protocols is quite common. Robin Milners ccs, which was developed on similar lines as csp, evolved
into the calculus [25] and is also wellsuited for this task. Interestingly, [26]
extended the calculus with cryptographic primitives and other features relevant to security protocols; the result is the so-called spicalculus . In more
recent work, Gay and Nagarajan used ccs to model the BB84 quantum cryptographic protocol [27] and demonstrated the inability of an eavesdropper to
succeed for a certain kind of attack. They subsequently developed a quantum
process algebra, cqp, especially for the denition of quantum protocols [28].
5.1.2 Property Specication
Thus far, we have only considered means for describing system behaviour.
However, this is insu cient for model checking, whose purpose is to demonstrate conclusively that a system operates in a desirable manner, and that it
is free from design faults. Expressing precisely what features of a system are
desirableand exactly what constitutes a fault are the objectives of property
specication. A property is any pattern of observable behaviour that a system
should or should not exhibit; the function of a model checker is, thus, to show
whether a system satises a given set of properties.
A property can be expressed as a formula in a given logic. Typically a system
model is represented by a nite or innite automaton, and the model checker

16

must determine the truth or falsity of the statement

j=
which means [22], the run
satises formula .

(1)

of the automaton representing the system model

Properties of a system model are usually expressed as formulae in temporal

logic; in some model checking systems however, the behaviour dened by a
property is described explicitly instead. For example, the spin model checker
converts properties written in ltl (Linear Temporal Logic) to patterns of
behaviour (never claims) expressed in promela. The prism model checker
requires that properties are expressed in pctl.

5.1.2.1 Temporal Logic Temporal logic was rst recommended by [30]

as a tool for reasoning about program computations. While propositional logic
allows one to make statements about Boolean variables using various connectives, temporal logic includes modal operators that quantify such statements
over time.
If a program computation is regarded as a sequence of states
s0 ! s1 !

! sn

or, put otherwise, s0 ! sn

then one such state si may be regarded as the presentmoment in time, and
all subsequent states are then moments in the future. The modal operators of
temporal logic are used to quantify over present and future states.
Modal operators are applied to logical propositions; logical propositions consist
of atomic propositions (which are regarded as uninterpreted symbols) and
connectives such as : (not), ^ (and), _ (or) and ) (implies).
The most commonly used operators in temporal logic are
(henceforth),
3 (eventually), and (next). The formula P (henceforth, P ) means
that P is true for all states in a computation. For a computation whose present
state is si and whose futureare all states sj (j > i), the formula P states
that the proposition P is true in state si and will remain true for all sj .
The formula 3P (eventually, P ) states that there is some point in the
computation at which P is true. If si is the present state of a computation,
then 3P means that, either P is true in si or it will be true at some time in
the future.

17

Finally, P means that P is true in the second state of a computation (i.e. in

state si+1 if si is the present state). The three modal operators can be combined together to express more complex properties. Any unbroken sequence of
operators is termed a modality, and the number of operators in the sequence
is the degree of that modality.

5.1.2.2 Linear Temporal Logic (LTL) versus Computation Tree

Logic (CTL) There are two possible views regarding the nature of time,
and each of these gives rise to a dierent class of temporal logic. In mainstream model checkers, two kinds of temporal logic are actually used: linear
and branching temporal logic [31].
Linear temporal logic (ltl) treats time in such a way that, each moment
has a unique possible future. Thus any ltl formula is interpreted over linear
sequence, and essentially describes the behaviour of a single program computation. ltl is used, for instance, in the model checker spin.
On the other hand, in a branching temporal logic (or computation tree logic,
ctl), each moment in time may have several possible futures. Therefore,
formulae in such a logic are represented by innite computation trees; each
tree describes a possible computation of a nondeterministic program. The
prism tool uses a branching temporal logic, known as pctl (probabilistic
computation tree logic). pctl caters for probabilistic computations, and the
trees representing a given formula are labelled with probabilities.
5.1.3 Verication
The nal phase of a model checking solution to a given problem involves applying an automated tool to the system description and the specication of its
properties. In the literature, properties that express desired system behaviour
are termed liveness properties, while safety properties express the absence of
undesirable system behaviour [22]. Clearly, the model checker is expected to
prove that liveness and safety properties do hold for a given system.
5.1.4 Probabilistic ModelChecking
prism is an acronym for probabilistic symbolic model checker, and is designed
for modelling and validating systems which exhibit probabilistic behaviour.
Whereas a logical modelchecker, such as spin [22], only states whether a
system model satises a temporal formula , a tool such as prism computes the probability with which such a formula is satised, i.e. the value of
P ; = Prf j= g for given and . The models catered for by prism
may incorporate specic probabilities for various behaviors and so may the
18

formulas used for verication. Probabilistic models and prismlike tools nd

applications in numerous areas of computer science where random behaviour is
involved. Oftcited applications are randomized algorithms, realtime systems
and Monte Carlo simulation. The application of probabilistic modelchecking
to quantum systems is entirely appropriate, since quantum phenomena are
inherently described by random processes; to reason about such phenomena
one must account for this.
prism uses a builtin specication language based on Alur and Henzingers
reactive modules formalism (see [23,37] for details). Using this language
the user can describe probabilistic behaviour. Internally, a prism model is
represented by a probabilistic transition system. In such a system, each step in
a computation is represented by a move, or transition, from a particular state
s to a distribution of successor states. For technical details, refer to [37].
The probabilistic temporal logic pctl [36] is used as the principal means for
dening properties of systems modelled in prism. It su ces for our purposes
to remind the reader of the meaning of the operator U, known as unbounded
until. The formula 1 U 2 expresses the fact that 1 holds continuously
from the current state onward, until eventually 2 becomes true. The prism
property P > 1[ 1 U 2 ] states that the formula 1 U 2 is true with certainty,
i.e. with a probability of unity; we use prism to check whether such a property
holds in a given model.

Summary and Conclusion

This report has detailed various protocols of signicance in practical QKD

systems, in particular, reconciliation protocols (used for correcting errors after
a QKD protocol has been performed), privacy amplication protocols (which
are used for minimizing and if possible, eliminating, information gained by
an attacker through eavesdropping on the public and private channel), and
authentication protocols (which are used to verify the originator of a message
on the two channels). All protocols described here are classical, in that they
do not involve any quantum mechanical phenomena, as does QKD.
The second part of the report gives an account of the modelchecking technique, which we believe to be adequate for modelling and analysing protocols such as the above. We discuss system specication (including the use of
process calculus), temporal logic for property specication, and the features of
the PRISM model checker. We expect that PRISM should be a powerful tool
for investigating the behaviour of these protocols, bearing in mind that our
research thus far has mainly involved the application of PRISM to a selection
of purely quantum protocols [35,34].

19

References
[1] C. Boyd and A. Mathuria. Protocols for Authentication and Key Establishment,
SpringerVerlag, 2003.
[2] L. Paulson. The Inductive Approach to Verifying Cryptographic Protocols. In
Journal of Computer Security 6, pp. 85128, 1998.
[3] G. Lowe. Breaking and Fixing the NeedhamSchroeder Public Key Protocol using
FDR. In Tools and Algorithms for the Construction and Analysis of Systems,
pp. 147166. SpringerVerlag, 1996.
[4] Jrgen Cederlf. Authentication in quantum key growing. Masters thesis, Dept.
of Applied Mathematics, Linkpings Universitet, 1995.
[5] P. Ryan and S. Schneider. Modelling and Analysis of Security Protocols,
AddisonWesley, 2001.
[6] J. Mitchell, M. Mitchell and U. Stern. Automated Analysis of Cryptographic
Protocols using Mur . In Proceedings of the 1997 IEEE Symposium on Security
and Privacy, pp. 141151. IEEE Computer Society Press, 1997.
[7] E.M. Clarke, S. Jha and W. Marrero. Verifying Security Protocols with Brutus.
In ACM Transactions on Software Engineering and Methodology 9(4), pp. 443
487, 2000.
[8] C. Meadows. The NRL Protocol Analyzer: An Overview. In Journal of Logic
Programming 26(2), pp. 113131, 1996.
[9] M. Burrows, M. Abadi and R. Needham. A Logic of Authentication. In ACM
Transactions on Computer Systems 8(1), pp. 1836, 1990.
[10] F.J.T. Fabrega, J. Herzog, and J. Guttman. Strand Spaces: Why is a security
protocol correct? In Proceedings of the 1998 IEEE Symposium on Security and
Privacy, pp. 160171. IEEE Computer Society Press, 1998.
[11] D. Mayers. Unconditional Security in Quantum Cryptography. In Journal of the
ACM 48(3), pp. 351406, 2001.
[12] C. Bennett and G. Brassard. Quantum cryptography: Public Key Distribution
and Coin Tossing. In Proceedings of the IEEE International Conference on
Computers, Systems and Signal Processing, Bangalore, India, pp. 175179,
1984.
[13] M.N. Wegman and J.L. Carter. New Hash Functions and their Use in
Authentication and Set Equality. In Journal of Computer and System Sciences
22, pp. 265279, 1981.
[14] C. Bennett. Quantum Cryptography Using Any Two Nonorthogonal States. In
Physical Review Letters 68(21), pp. 31213124, 1992.

20

[15] J.M. Robert. Dtection et Correction d Erreurs en Cryptographie. Masters

thesis, Dpartement dinformatique et de recherche oprationnelle, Universit
de Montral, 1985.
[16] C. Bennett, G. Brassard, and J.-M. Robert. Privacy Amplication by Public
Discussion. In SIAM Journal on Computing 17(2), pp. 210229, 1988.
[17] C. Bennett, G. Brassard, and J.-M. Robert. How to Reduce your Enemys
Information (Extended Abstract), In Proceedings of CRYPTO 85, Lecture
Notes in Computer Science 218, pp. 468476, Springer-Verlag, 1986.
[18] G. Brassard and L. Salvail. Secret-key reconciliation by public discussion. In
Advances in Cryptology EUROCRYPT 93 , Lecture Notes in Computer
Science 765, pp. 410423, Springer-Verlag, 1994.
[19] A. Ekert. Quantum Cryptography based on Bells Theorem. In Physical Review
Letters 67(6), pp. 661663, 1991.
[20] L. Salvail. Le Problme de Rconciliation en Cryptographie. Masters thesis,
Dpartement dinformatique et de recherche oprationnelle, Universit de
Montral, 1991.
[21] M. Huth and M. Ryan. Logic in Computer Science: Modelling and reasoning
about systems. Cambridge University Press, 1st edition, 2000.
[22] G. Holzmann. The SPIN Model Checker: Primer and Reference Manual.
Pearson Education, 2003.
[23] M. Kwiatkowska, G. Norman, and D. Parker. Modelling and verication
of probabilistic systems. In P. Panangaden and F. Van Breugel, editors,
Mathematical Techniques for Analyzing Concurrent and Probabilistic Systems.
American Mathematical Society, 2004. Volume 23 of crm Monograph Series.
[24] C. A. R. Hoare. Communicating Sequential Processes. PrenticeHall, 1985.
[25] R. Milner. Communicating and Mobile Systems: The
University Press, 1999.

Calculus. Cambridge

[26] M. Abadi and A. Gordon. A calculus for cryptographic protocols: The spi
calculus. Information and Computation, 148:170, 1999.
[27] R. Nagarajan and S. Gay. Formal verication of quantum protocols. Available
at arXiv.org. Record: quant-ph/0203086, 2002.
[28] S. Gay and R. Nagarajan. Communicating quantum processes. In POPL
05: Proceedings of the 32nd ACM Symposium on Principles of Programming
Languages, Long Beach, California, January 2005.
[29] G. Holzmann. The Design and Validation of Computer Protocols. PrenticeHall,
1991.
[30] A. Pnueli. The temporal logic of programs. In Proceedings of the 18th ieee
Symposium on Foundations of Computer Science. ieee Press, 1977.

21

[31] M. Vardi. Branching vs. linear time: Final showdown. In Proceedings of the
7th International Conference on Tools and Algorithms for the Construction and
Analysis of Systems, pp. 122. SpringerVerlag, 2001.
[32] N. Papanikolaou. Techniques for design and validation of quantum protocols.
Masters thesis, Department of Computer Science, University of Warwick, 2005.
[33] N. Papanikolaou. Introduction to quantum cryptography. ACM Crossroads
Magazine, 11.3, Spring 2005 Issue.
[34] R. Nagarajan, N. Papanikolaou, G. Bowen and S. Gay. An automated analysis
of the security of quantum key distribution. CoRR Preprint cs.CR/0502048,
available at www.arxiv.org.
[35] S. Gay, R. Nagarajan, and N. Papanikolaou. Probabilistic modelchecking of
quantum protocols. Quantum Physics Repository Preprint quant-ph/0504007,
available at www.arxiv.org.
[36] F. Ciesinski and M. Gr
er. On probabilistic computation tree logic.
Validation of Stochastic Systems (2004), pp. 147188.

In

[37] D. Parker, G. Norman and M. Kwiatkowska. prism 2.0 usersguide, February

2004.

22