security analysis and implementation of password · pdf filesecurity analysis and...
TRANSCRIPT
Security Analysis and Implementation of
Password-based Cryptosystem
Diplomarbeit (Master Thesis)
supervised by: Prof. Dr. Tsuyoshi Takagi
Department of Computer Science
Darmstadt University of Technology
Harini Bakuri
January 2005
ECE, School of Engineering and Design
Brunel University
Acknowledgments
First of all I would like thank my supervisor, Prof. Dr. Tsuyoshi Takagi, for propos-
ing the topic, for his advice and support and the investment of time for discussion
that provided ideas and impetus especially at the important initial phase of my
thesis research.
I would like to thank my friend Tariq Ali Rehman for all his encouragement and
support. Without him this thesis would not have been possible.
I would also like to thank Mr. Ram Swaminathan for his instant response to my
e-mails and for suggesting the right document to read.
Finally, I would like to thank my family and friends for their great support in all
endeavors throughout my life.
1
Abstract
Much work has been done in recent years on mechanisms for authenticated key ex-
change. Many solutions rely on cryptographically secure keys and therefore have
to deal with issues like key management, public-key infrastructure, or secure hard-
ware. Recently password authenticated key exchange protocols have been proposed
which enable mutual authentication and key exchange based solely on passwords,
requiring no other public or private participant-specific information to be stored.
The password could be a short string of characters or just a 4-digit PIN number. In
this dissertation we would analyze these protocols and explain how to bootstrap a
short secret into a secure strong secret. Further topics of the dissertation include a
detailed evaluation and implementation of one such protocol called SNAPI (Secure
Network Authentication with Password Identification) proposed by Philip MacKen-
zie, Sarvar Patel and Ram Swaminathan [MPS00] which is based on RSA. In their
technical paper they use the concept of provable security to show that SNAPI is
a secure password authenticated key exchange protocol. This dissertation would
provide a detailed analysis of the proof of security for the SNAPI protocol. Apart
from this, the known solutions to remote authentication like Secure Shell and SSL
are also discussed.
2
Contents
1 Background 8
1.1 Mathematical Background . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.1 Number Theory . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.2 Group Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.3 Asymptotic Notation . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.4 Number-theoretic problems used in cryptography . . . . . . . 13
1.2 Cryptographic Building Blocks . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1 Public key cryptography . . . . . . . . . . . . . . . . . . . . . 18
1.2.2 RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.3 Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . . 21
1.2.4 Hash Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.5 Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . 23
2 Known solutions to user authentication 26
2.1 Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2 Secure Shell (SSH) [BS01] . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3 SSL [Tho00] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 Password Authenticated Protocols 33
3.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4 Security Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5 Comparison with the known solutions . . . . . . . . . . . . . . . . . . 48
3
4 Implementation of the SNAPI protocol 50
4.1 Java Socket Programming . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2 Java Cryptography Extension . . . . . . . . . . . . . . . . . . . . . . 51
4.3 SNAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5 Conclusion and Futurework 60
4
List of Figures
1.1 Public-key cryptosystem . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2 Digital Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1 Remote Authentication Using Telnet . . . . . . . . . . . . . . . . . . 27
2.2 SSH2 Layered Architecture . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3 SSH Message Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4 SSL added to the TCP/IP protocol stack . . . . . . . . . . . . . . . . 30
2.5 SSL Handshake protocol . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Login form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2 Program output for Bob . . . . . . . . . . . . . . . . . . . . . . . . . 57
5
Introduction
Authenticated key exchange protocols allow for mutual authentication of commu-
nicating parties and for generating a cryptographically-strong shared key between
them. The Web has long become a commonly used medium for communication and
with the advent of mobile devices like laptops and PDAs and wireless technology,
it has become quite handy. Apart from the basic services which the Web provides,
nowadays it could also be used for some highly critical operations like bank trans-
actions, e-commerce etc. These operations require authentication and key exchange
in order to establish a secure channel to protect the user data from being read or
manipulated by unauthorised sources and this is where authenticated key exchange
protocols play an important role. Although user authentication is not new in the
field of cryptography, this still seems to be a challenging problem due to the many
possible points of attack, including eavesdropping, replay, spoofing and dictionary
attacks against weak passwords. Many of the existing solutions like telnet, are either
totally insecure or deal with many security assumptions.
It is a common knowledge that a user cannot remember anything larger than a
small secret. As we see later, current solutions to authenticated key exchange use a
combination of symmetric as well as public key techniques which use keys as large as
1024 bits. Obviously, such keys must be stored on the user’s system, which makes it
quite inflexible and requires extra security assumptions. Even if the user is required
to know some public data like the server’s public key, this also needs to be stored
and protected on the user’s system so that it cannot be modified. Furthermore,
each time the user wishes to communicate with the server, he has to use the same
machine on which the keys are stored. Also the memory required for the storage
of public keys can be scarce on certain devices. We need a better scheme which is
portable, simple and does not involve the management of keys. This requirement led
to the evolution of password authenticated key exchange protocols. Password-only
protocols seem inviting because they are based on direct trust between a user and a
server, and do not require the user to store long secrets or data on the user’s system.
6
The main goal of this dissertation is to show that password authenticated key ex-
change protocols provide a simple and secure means to establish a secure channel on
the basis of just a simple and memorable password. This goal is achieved through
the accomplishment of the following specific goals.
1. Efficiency: The SNAPI (Secure Network Authentication with Password Identi-
fication) [MPS00] protocol is a password authenticated key exchange protocol
which is simple and efficient. We try to achieve a better understanding of this
protocol and analyze its proof of security. For the proof of security we use the
random oracle model proposed by Bellare and Rogaway [BR93].
2. Implementation: We implement a simple system based on the SNAPI proto-
col. This implementation leads to future work and shows that the protocol is
practicable.
The dissertation is divided into 4 chapters. Chapter 1 covers mathematical back-
ground and cryptographic preliminaries relevant to the understanding of the SNAPI
protocol. In chapter 2 we take a look at some of the known solutions to user authen-
tication and establishment of secure channels like, SSH and SSL. Chapter 3 starts
with a formal definition of password based protocols and then analyzes the SNAPI
protocol and its proof of security. Chapter 4 is dedicated to the implementation
details of the SNAPI protocol.
7
Chapter 1
Background
1.1 Mathematical Background
This section deals with mathematical background which is necessary for the under-
standing of algorithms presented later. Here we take a look at number theory and
group theory.
1.1.1 Number Theory
The fundamental theorem of arithmetic states that any natural number can be
uniquely factored into the product of primes, i.e.,any n ∈ N can be written as
n =∏
p∈P
pep (1.1)
where ep is the exponent of the prime p (p 6= 1). The representation of n on the right-hand side of (1.1) is called its factorization and the primes p its factors [PHS03].
Definition 1.1.1 The greatest common divisor of two integers a and b is the largest
integer which divides with no remainder both a and b [PHS03].
The following is a very efficient and widely used algorithm to compute the gcd of
two numbers. [PHS03]
8
Algorithm 1 Euclidean Algorithm: Finds the gcd of two integers a, b ∈ N1. Initialize r0 = a and r1 = b.
2. Compute the following sequence of equations:
r0 = q1r1 + r2,
r1 = q2r2 + r3,
...
rn−3 = qn−2rn−2 + rn−1,
rn−2 = qn−1rn−1 + rn,
until there is a step for which rn = 0 while rn−1 6= 0.
3. Return rn−1.
Definition 1.1.2 For two integers a and b, a is said to be congruent to b modulo
n, written a ≡ b mod n, if n divides (a− b) [MvOV97].
Properties of Congruences: For all a, b ∈ Z, the following are true.
• a ≡ a mod n (reflexivity).
• If a ≡ b mod n then b ≡ a mod n (symmetry).
• If a ≡ b mod n and b ≡ c mod n, then a ≡ c mod n (transitivity).
Definition 1.1.3 The set Zn = 0, 1, ...n−1 denotes the set of integers modulo n.Addition, subtraction and multiplication in Zn are performed modulo n [MvOV97].
Definition 1.1.4 The multiplicative group of Zn is Z∗n = a ∈ Zn|gcd(a, n) = 1.
In particular, if n is a prime, then Z∗n = a|1 ≤ a ≤ n − 1. If a ∈ Z∗
n and b ∈ Z∗n
then a · b ∈ Z∗n, and so Z
∗n is closed under multiplication. The multiplicative inverse
of an integer a, where a ∈ Z∗n is an integer x such that ax ≡ 1 mod n [MvOV97].
The following algorithm is an extension to the Euclidean algorithm shown above
and is used to compute the multiplicative inverse of an integer in Zn [PHS03].
9
Algorithm 2 Extended Euclidean Algorithm
INPUT: two non-negative integers a and N where N is the modulus and a is the
number for which multiplicative inverse is to be calculated.
OUTPUT: Inverse of a.
1. Initialize r0 = N and r1 = a.
2. Modify the equations in step 2 as follows: r2 = r0 − q1r1 ≡ −q1r1 mod N , set
x1 = −q1 then r2 = x1r1
r3 = r1 − q2r2 = r1 − q2x1r1 = (1− q2x1)r1 = x2r1, where x2 = (1− q2x1)
r4 = r2 − q3r3 = x1r1 − q3x2r1 = (x1 − q3x2)r1 = x3r1, where x3 = (x1 − q3x2)
· · ·ri+1 = ri−1 − qiri = xiri, where xi = (xi−2 − qixi−1).
The computations end when there is a step n−1 for which rn = 0 and rn−1 = 1.
The equation for the previous step is,
rn−1 = rn−3 − qn−2rn−2 = xn−2r1 = 1.
3. Return xn−2.
Definition 1.1.5 The order of Z∗n is defined to be the number of elements in Z∗
n,
namely |Z∗n| [MvOV97].
Definition 1.1.6 Let g ∈ Z∗n. If there is a positive integer t such that a
t ≡ 1 mod n,then the smallest such integer is called the order of g in Z∗
n. If the order of g is φ(n),
then g is said to be the generator or a primitive element of Z∗n. If Z
∗n has a generator,
then Z∗n is said to be cyclic [MvOV97].
Definition 1.1.7 Let n be a positive integer. The Euler phi function or Euler
totient function φ(n) is defined to be the number of nonnegative integers b less than
n which are prime to n:
φ(n) = |0 ≤ b < n|gcd(b, n) = 1|. (1.2)
It is easy to see that φ(1) = 1 and that φ(p) = p− 1 for any prime p [Kob94].
10
Theorem 1.1.8 (Fermat’s Little Theorem) [PHS03] Let p be a prime and suppose
the
gcd(a, p)= 1 then
ap−1 ≡ 1 mod p. (1.3)
Theorem 1.1.9 (Euler’s Theorem) [PHS03] Let gcd(a,N) = 1, then
aφ(N) mod N = 1. (1.4)
Probabilistic Primality Tests
Primality test is an algorithm for determining whether a given integer is prime. A
probabilistic primality test does not determine with mathematical certainty whether
a given number is prime. These algorithms play an important role in public-key
cryptography where large prime numbers are used. The most efficient and com-
monly used probabilistic algorithm is the Miller-Rabin algorithm [PHS03] which is
explained below.
Algorithm 3 Miller-Rabin probabilistic primality test
INPUT: an odd integer n ≥ 3 and security parameter t.OUTPUT: ”n is prime” or ”n is composite”.
1. Write n− 1 = 2sr such that r is odd.
2. For i from 1 to t do the following:
(a) Select at random a nonzero integer a with 1 ≤ a ≤ p− 1.
(b) Compute b = ar mod n. If b = ±1, return ”n is prime”.
(c) For j = 1, . . . , s − 1, calculate c ≡ b2imod n. If c = −1, return ”n is
prime”.
3. Otherwise return ”n is composite”.
Although this algorithm is fast, it is to be noted that it has a controllably small
probability of error. Not every number that passes the Miller-Rabin test is prime.
The probability that a composite number is declared to be prime is less than ( 14)t.
11
1.1.2 Group Theory
Definition 1.1.10 A group G = 〈S, ∗〉 is an algebraic structure that satisfies thefollowing [PHS03]:
G1. For any two elements a, b ∈ S, c = a ∗ b ∈ S. This property is called closure.
G2. For any three elements a, b, c ∈ S, the group operation is associative, i.e.,a ∗ (b ∗ c) = (a ∗ b) ∗ c.
G3. There is a neutral (identity) element e ∈ S such that ∀a∈Sa ∗ e = e ∗ a = a.
G4. Each element a ∈ S has its inverse, i.e., ∀a∈S∃a−1 ∈ Sa ∗ a−1 = a−1 ∗ a = e.
An Abelian group is a group whose group operation is commutative:
G5. For any two a, b ∈ S,a ∗ b = b ∗ a.
The set of integers with addition as the group operation (Z,+) is a group. The
identity element is zero and the inverse element of a ∈ Z is −a ∈ Z. The group is
Abelian as ∀a,b∈Za+ b = b+ a. The group is infinite.
Let 〈G, ∗〉 and 〈H, ∗〉 be two groups, then the mapping f : G → H is a group
homomorphism if,
• The group operation is preserved: ∀a,b∈Gf(a ∗ b) = f(a) ∗ f(b) and
• The identity is mapped to the identity: f(eG) = eH .
A ring [PHS03] is an algebraic structure with the set S and two operations,addition, +, and multiplication, ·; i.e., R = 〈S,+, ·〉 such that
• R1. For each pair a, b ∈ S, a+ b and a · b belong to S.
• R2. 〈S,+〉 is an additive Abelian group.
• R3. The multiplicative operation is associative, i.e., for any a, b, c ∈ S (a·b)·c =a · (b · c).
12
• R4. The multiplicative operation is distributive with respect to addition, i.e.,for any three elements a, b, c ∈ S, a(b+ c) = ab+ ac and (a+ b)c = ac+ ab.
1.1.3 Asymptotic Notation
The efficiency of algorithms can be measured using the so-called time complexity
function [PHS03]. It describes how many steps (time intervals) must be performed
before the algorithm generates the result for an instance of length n. Time com-
plexity functions are usually compared using their asymptotic behavior. Let f(n)
and g(n) be two functions whose rates of growth are to be compared.
Definition 1.1.11 We say function is O(g(n)) if there is a positive constant c and
a positive integer n0 such that 0 ≤ f(n) ≤ cg(n) for all n ≥ n0.
A polynomial-time algorithm is an algorithm whose worst case running time function
is of the form O(nk), where n is the input size and k is a constant [MvOV97].
1.1.4 Number-theoretic problems used in cryptography
There are many number theoretic problems that have been used in cryptography
and below we discuss the integer factorization problem, the discrete logarithm prob-
lem and the birthday paradox.
The integer factorization problem
Given a positive integer n, find its prime factorization: that is write n as,
n =∏
p∈P
pep (1.5)
where ep is the exponent of the prime p (p 6= 1).
The security of many cryptographic techniques like the RSA public-key encryption
scheme, RSA signature scheme etc., depends on the intractability of the integer
factorization problem. Over the years several algorithms for factorization have been
13
proposed, but the most fastest of these is the general number field sieve proposed
by Pollard. It uses
O
exp
[(
64
9log n
) 1
3
(log log n)2
3
]
steps to factor n.
The number field sieve algorithm is based on the idea of finding two integers x and
y such that x2 ≡ y2 mod n which gives a 50% chance that gcd(x− y, n) is a factor
of n. The algorithm works as follows [Sma03]:
1. Choose two monic, irreducible polynomials with integer coefficients f1 and f2,
of degree d1 and d2 respectively and m ∈ Z such that,
f1(m) ≡ f2(m) ≡ 0 mod N.
2. The NFS makes use of arithmetic in the number fields K1 and K2 given by
K1 = Q(θ1)andK2 = Q(θ2),
where θ1 and θ2 are the roots of f1 and f2 respectively. We then have two
homomorphisms φ1 and φ2 given by
φi :
Z[θi] → Zn
θi → m.
We aim to find two value β and γ such that,
(φ1(γ1))2 = φ1
∏
(a,b)∈S
(a− bθ1)
= φ2
∏
(a,b)∈S
(a− bθ1)
= (φ2(γ2))2,
where β ∈ K1 and γ ∈ K2.
3. Once we have found these values, we would have
φ1(β)2 = φ2(γ)
2 mod n
14
4. With a 50% chance, gcd(n, φ1(β)− φ2(γ)) would be a factor of n.
For more details of this algorithm please refer to [Sma03].
The RSA problem
The RSA problem is related to the factoring problem discussed above and forms the
basis for the security of RSA cryptosystem and the RSA signature scheme.
Definition 1.1.12 Given e such that gcd(e, (p− 1)(q − 1)) = 1 and c, find m suchthat me = c mod N .
The RSA problem is no harder than the integer factorization problem. [Sma03]
The discrete logarithm problem
The security of many cryptographic techniques like Diffie-Hellman key agreement,
ElGamal encryption etc., depends on the intractability of the discrete logarithm
problem. Below we give the definition of generalized DLP (GDLP) and show how
to solve it using the baby-step giant-step algorithm.
Definition 1.1.13 The discrete logarithm problem is the following: given a prime
p, a generator α of Z∗p , and an element β ∈ Z∗
p , find the integer x, 0 ≤ x ≤ p − 2,such that αx ≡ β mod p [MvOV97].
Definition 1.1.14 The generalized discrete logarithm problem is the following:
given a finite cyclic group G of order n, a generator α of G, and an element β ∈ G,find the integer x, 0 ≤ x ≤ n− 1, such that αx = β [MvOV97].
Algorithms to solve discrete logarithm problem can be classified into exhaustive
search methods and index calculus methods. The exhaustive search methods include
algorithms like the baby-step giant-step algorithm and the Pollard’s rho algorithm.
The index calculus methods on the other hand, are not applicable to all groups,
rather to those that possess certain arithmetic properties like Z∗p . If field GF (p),
the number field sieve algorithm can be applicable and logarithm over GF (p) is
15
solved in the subexponential time [MvOV97].
Baby-step giant-step algorithm [MvOV97]: This algorithm is used for solving gen-
eral discrete logarithm problem. This generic method applies to any finite cyclic
abelian group.
Let m = d√ne, where n is the order of α. The baby-step giant-step algorithm isbased on the following observation. If β = αx, then one can write x = qm+r, where
0 ≤ r < m. Hence, αx = αqmαr, which implies β(α−r) = αqm. This suggests the
following algorithm for computing x.
Algorithm 4 Baby-step giant-step algorithm for computing discrete logarithms.
INPUT: a generator α of a cyclic group G of order n, and an element β ∈ G.OUTPUT: the discrete logarithm x = logα β.
1. Set m← d√ne.
2. Construct a baby-step table with entries (r, βα−r) for 0 ≤ r < m. Sort this
table by second component.
3. Set γ ← αm.
4. Construct the giant-step table as follows. For q from 0 to m − 1 compute γqand check if it matches the second component of some entry in the table. If a
matching entry has been found, then return x = qm+ r.
The time complexity of the above algorithm isO(√n) group multiplications [MvOV97].
The Diffie-Hellman problem
The Diffie-Hellman problem is closely related to the discrete logarithm problem and
is also quite significant to public-key cryptography because its intractability forms
the basis of many cryptographic schemes like the Diffie-Hellman key exchange and
the ElGamal public-key encryption.
Definition 1.1.15 Let α be the generator of a finite cyclic group Z∗p and let p
16
be a prime number. The Diffie-Hellman problem states that it is computationally
infeasible to compute αab knowing only αa and αb [MvOV97].
The DH problem is at least as strong as the DL problem. That is, if discrete loga-
rithms can be computed, then obviously the Diffie-Hellman assumption fails.
Birthday paradox [PHS03]
The birthday paradox states that if there are 23 people in a room then the probability
that at least two people have the same birthday is greater that 0.5. To calculate the
probability we disregard leap years and twins. The probability that the birthday of
the first person falls on a specific day of the year is equal to 1365. The probability
that the birthday of the second person is not the same as the first person is equal to
1 − 1365. If the birthdays of the first two persons are different, the probability that
the birthday of the third person is different from the first two is equal to 1 − 2365.
Consequently, The probability that t persons have different birthdays is equal to
(1− 1365)(1− 2
365) . . . (1− t−1
365). So the probability that at least two of them have the
same birthday is:
1−(
1− 1
365
)(
1− 2
365
)
. . .
(
1− t− 1365
)
It can easily be computed that for t ≥ 23, this probability is bigger than 0.5. Ingeneral, the probability of finding at least two persons having the same birthday is
at least 0.5 if the number of persons is roughly√n and the year has n days. The
birthday paradox can be used to attack hash functions which we shall see in the
next section.
17
1.2 Cryptographic Building Blocks
Here we look at some of the basic cryptographic preliminaries which help us to
gain a better understanding of the SNAPI protocol. To start with, the public key
infrastructure and then RSA, which is the most popular public key algorithm, are
discussed. This is followed by a brief introduction to hash functions and digital
signatures.
1.2.1 Public key cryptography
Public key cryptography also called asymmetric encryption uses one key for encryp-
tion and a different key for decryption. The encryption key (e) can be made public
whereas, the decryption key (d) needs to be kept secret. When Bob wants Alice to
send him some confidential information (m), he first generates two keys. He then
publishes one of the keys and keeps the other to himself. If the encryption key
is made public, then Alice can encrypt the information and only Bob can decrypt
it using his private key. On the other hand, if the decryption key is made pub-
lic, then Alice can read messages encrypted by Bob. The latter variant is used for
authentication only. [PHS03]
18
Figure 1.1: Public-key cryptosystem
1.2.2 RSA
We now look at one of the most popular public key algorithm, the Rivest Shamir
Adleman algorithm or the RSA [RSA78]. The RSA cryptosystem, named after its
inventors R. Rivest, A. Shamir, and L. Adleman, is the most popular and widely
used public key algorithm. It has withstood years of cryptanalysis and its security
is based on the difficulty of integer factorization problem. The algorithm goes as
follows:
19
Algorithm 5 Key generation for RSA public-key encryption
1. Bob randomly generates two large prime numbers p and q roughly the same
size.
2. He then computes the product n = pq and using Euler’s phi function 1.1.7 we
can compute φ(n) as φ = (p− 1)(q − 1).
3. Bob also chooses an encryption key e, such that gcd (e, φ) = 1.
4. Using the extended Euclidean algorithm he computes the decryption key d,
such that 1 < d < φ and ed ≡ (1 mod φ).
5. The pair (e, n) is the public key and the pair (d, n) is the private key.
To encrypt a message m, divide it into numerical blocks smaller than n and
compute cipher text c as:
c = me mod n.
The message m can be recovered from the ciphertext c as follows:
m = cd mod n.
Proof that decryption works :
Since ed ≡ (1 mod (p− 1)(q − 1)), there is an integer k with
ed = 1 + k(p− 1)(q − 1)
Therefore
(me)d = med = m1+k(p−1)(q−1) = m(m(p−1)(q−1))k
It follows from (1.4) that
(me)d ≡ m(m(p−1)(q−1))k ≡ m · 1 ≡ m.
The security of RSA relies on the difficulty of finding the private decryption expo-
nent d given only the public modulus n and the encryption exponent e. Since the
20
decryption exponent is kept secret, the only way to deduce m from c is to factor n
into p and q, in order to compute (p− 1)(q − 1) which allows the determination ofd from e. For medium security the size of the public moduli should be around 1024
bits. [Sma03]
1.2.3 Diffie-Hellman Key Exchange
In this section, we describe the Diffie-Hellman key exchange protocol [DH76] which
can be used for exchanging keys over an insecure network. This protocol allows
for two parties which never met before to establish a shared secret by exchanging
messages over an insecure channel. An adversary listening to the key exchange
cannot construct the secret from the messages exchanged. The security of the Diffie-
Hellman key exchange is based on the discrete logarithm problem. The protocol
works as follows:
1. Alice and Bob first agree on a large prime number p and a generator g of
Z∗p(2 ≤ α ≤ p−2). The prime p and the generator α could be publicly known.
2. Alice randomly chooses an integer x ∈ 0, 1, . . . , p−2, which is her secret keyand computes
A = αx mod p
and sends it to Bob.
3. Similar to Alice, Bob also chooses an integer y ∈ 0, 1, . . . , p − 2 randomly,which is his secret key and computes
B = αy mod p
and sends it to Alice.
4. Alice computes the shared key as
K = Bx mod p = (αy)x mod p
5. Bob computes the shared key as
K = Ay mod p = (αx)y mod p
21
Even if adversary can see the messages, αx and αy, he cannot recover the shared
key αxy due to the Diffie-Hellman problem. Hence the security of the above protocol
rests on solving the DHP.
1.2.4 Hash Functions
A hash function or a one-way hash function takes an arbitrary length binary string
called a preimage as input and produces a fixed-length binary string called the hash
value as output. This hash value serves as a compact representation of the input
string. In cryptography, a hash function h is chosen such that it is hard to find two
distinct preimages that hash to a common value. Such a hash function is said to be
collision-free. Also given a specific hash-value y, it is equally hard to find a preimage
x such that h(x) = y. Hash functions are typically publicly known and involve no
secrecy.
Hash functions are commonly used with digital signatures which is discussed in the
following section. Another use of hash functions is to verify data integrity. This is
done by computing the hash-value of the message at some point in time. In order
to verify that the message has not been altered, the hash-value is recomputed and
compared with the original hash-value. If both are equal, it means that the message
has not been altered.
Below we summarize the properties which a cryptographic hash function needs to
satisfy [Sma03]:
1. Preimage Resistant: It should be hard to find a message with a given hash
value.
2. Collision Resistant: It should be hard to find two messages that hash to a
common value.
3. Second Preimage Resistant: Given one message it should be hard to find
another message with the same hash value.
Due to the birthday paradox explained above it is hard to construct a collision
resistant hash function. To find a collision of a hash function h, we keep computing
22
h(x1), h(x2), h(x3), . . . until we get a collision. If the function has an output size of
n bits then we expect to find a collision after O(2n/2) iterations. Therefore in order
to achieve a security level of 80 bits for a collision resistant hash function we need
roughly 160 bits of output. According to [Sma03], the design of a collision resistant
hash function requires the digest to be at least 128 bits long.
1.2.5 Digital Signatures
The digital signature of a document is a piece of information based on both the
document and the signer’s private key. It is typically created through the use of a
hash function and a private signing function.
Suppose Alice wants to send a signed document or message to Bob. She applies
a hash function to the message, creating what is called a message digest. To create
a digital signature, one usually signs (encrypts) the message digest as opposed to
the message itself. This saves a considerable amount of time, though it does create
a slight insecurity. Alice sends Bob the encrypted message digest and the message,
which she may or may not encrypt.
Figure 1.2: Digital Signature
In order for Bob to authenticate the signature he must apply the same hash
function as Alice to the message she sent him, decrypt the encrypted message di-
gest using Alice’s public key and compare the two. If the two are the same he has
successfully authenticated the signature. If the two do not match there are a few
23
possible explanations. Either someone is trying to impersonate Alice, the message
itself has been altered since Alice signed it or an error occurred during transmission.
As mentioned above a hash function must be collision-free. If two messages hash
to the same message digest, then Alice not only signed the message she intended,
but also the other message which happens to hash to the same value. So collision-
free property of hash functions is a necessary security requirement for most digital
signature schemes. However, there is an attack called the birthday attack that relies
on the fact that it is easier to find two messages that hash to the same value than
to find a message that hashes to a particular value. In addition, someone could pre-
tend to be Alice and sign documents with a key pair he claims is Alice’s. To avoid
scenarios such as this, there are digital documents called certificates that associate
a person with a specific public key.
A public key certificate validates someone’s public key and is issued by a trusted
organization. It consists of a data part and a signature part. The data part in case
of Bob’s certificate, for example, would contain Bob’s public key, period of validity,
his name, address and so on. The signature part comprises of the digital signature
of the data part which is signed by the issuer. By signing the key and the informa-
tion about Bob, the issuer certifies that the key belongs to Bob and the information
about Bob is correct.
Below we present the digital signature algorithm. It is based on the intractability
of computing logarithms in Z∗p .
According to [Sma03], p > 21024 to avoid attacks via the Number field sieve
algorithm and q > 2160 to avoid the attacks via the Baby-step giant-step algorithm.
24
Algorithm 6 Digital Signature Algorithm
1. Generation of keys:
(a) Choose two prime numbers p and q, such that the length of p is between
512 and 2048 bits and q is 160-bit and divides p− 1.
(b) Choose a random integer h less than p and compute g = h(p−1)/q. If g = 1
then choose another new value for h until you obtain g 6= 1. This ensuresthan g is an element of order q in the group Z∗
p , i.e., gq = 1 mod p.
(c) Choose an integer x < q and compute y = gx mod p.
(d) The private key is x and the public key is (y, g, p, q).
2. Signing a message m:
(a) Compute the hash value h = H(m).
(b) Choose a random integer k < q and compute r = (gk mod p) mod q.
(c) Compute s = (h+ xr)/k mod q.
(d) The signature is the pair (r, s).
3. Verification of the signature (r, s) on message m:
(a) Compute the hash value h = H(m).
(b) Compute a = h/s mod q and b = r/s mod q.
(c) Compute v = (gayb mod p) mod q, where y is the public key of the sender.
(d) If and only if v = r, then accept the signature.
25
Chapter 2
Known solutions to user
authentication
To gain an overview on the history of user authentication protocols, this section ex-
plains how they evolved. First we start with the most basic authentication protocol,
telnet.
2.1 Telnet
Telnet is a client-server protocol based on TCP and facilitates remote login via the
Internet. IETF document RFC 855 defines telnet as:
”The purpose of the TELNET Protocol is to provide a fairly general, bi-directional,
eight-bit byte oriented communications facility.”
Once the remote host has been accessed, user is allowed to use all resources in it
if he has appropriate permissions and can run programs remotely. The client then
simply acts as a dumb terminal and all operations are performed on the remote
machine.
When telnet was being developed, security was not of much concern and so was not
incorporated into this protocol specification. But now, with an exponential increase
in the number of people accessing the Internet, and by extension, the number of
people attempting to crack into other people’s servers, the use of telnet should be
26
Client
Internet
Server
pwd
Figure 2.1: Remote Authentication Using Telnet
avoided on networks with Internet connectivity.
Main drawbacks of telnet with respect to security are:
1. Telnet transmits your username and password in plaintext over the Internet,
where a malicious third party can intercept them. Additionally, entire telnet
session is readable by a network snooper. Telnet does not encrypt any data
sent over the connection (including passwords).
2. Telnet lacks an authentication scheme which ensures that communication is
carried out between the two intended hosts, and not intercepted in the middle.
2.2 Secure Shell (SSH) [BS01]
SSH, the Secure Shell, is a popular and more secure scheme for user authentication
compared to telnet. But user authentication is not the only feature of SSH, its
other major features include, secure remote logins, secure file copying, and secure
invocation of remote commands. Unlike telnet, SSH uses encryption and decryption
techniques to secure data sent over network. For this purpose, it uses modern and
strong security algorithms like RSA, 3DES, IDEA etc. SSH2 is made up of three
different protocols namely:
• SSH Transport Layer Protocol (SSH-TRANS)
• SSH Authentication Protocol (SSH-AUTH)
• SSH Connection Protocol (SSH-CONN)
27
The figure 2.2 shows the layered architecture of the SSH2 protocol.
Client Server
SSH Connection SSH Authentification
SSH Transport
SSH Connection SSH Authentification
SSH Transport
TCP/IP, IPX/SPX, etc TCP/IP, IPX/SPX, etc
Ethernet, etc.
Figure 2.2: SSH2 Layered Architecture
SSH-TRANS is a secure transport protocol which provides host authentication,
strong encryption and integrity services. This protocol runs on top of the TCP/IP
protocol. Key exchange method, public key algorithm, symmetric encryption algo-
rithm, message authentication algorithm, and hash algorithm are all negotiated.
SSH-AUTH is used to authenticate the client to the server. It runs on top of the
transport layer protocol, SSH-TRANS. User authentication can be either public key
based or password based. SSH-CONN multiplexes the encrypted tunnel into several
logical channels. It runs over the user authentication protocol. It provides interac-
tive login sessions, remote execution of commands, forwarded TCP/IP connections,
and forwarded X11 connections.
The following steps are carried out in order to establish a secured channel between
a client and a server.
28
Client
Server
TCP / IP Request
Host key: 1024 bit RSA or 1024 bit DSA
Encrypted Session Key
Confirmation
Authentication request
Internet
Figure 2.3: SSH Message Exchange
The key exchange method is based on diffie-hellman-group1-sha1. The details of
the key exchange method are listed below. The prime number p and generator g of
Z∗p are published. Let q denote the order of g, then x and y are chosen randomly
such that, 1 < x < q and 0 < y < q. Ks is the public key of the server and S is the
signature function.
Client Server
e = gx mod p −−−−−−−−−−−−−−−−−−−→f = gy mod p
K = ey mod p
H = hash(A||Ks||e||f ||K)S(H)
←−−−−−−−−−−−−−−−−−−− a = Ks||f ||SVerify Signature
K = fx mod p
H = hash(A||Ks||e||f ||K)If S(H) = S then proceed.
29
The client needs to wait for the confirmation message from the server, which
must be encrypted with the session key. Its only after this step, the client sends its
password for authentication.
2.3 SSL [Tho00]
Secure socket layer is the de facto standard for securing end-to-end communications
over the Internet. It is also used for authentication and establishment of encrypted
communications between any two parties. Unlike SSH which was designed to replace
telnet and FTP, SSL was designed to secure web sessions. SSL is just another layer
added to the TCP/IP protocol stack for security. The figure 2.4 [Tho00] shows the
classical TCP/IP protocol with SSL inserted between application layer and TCP
layer.
Figure 2.4: SSL added to the TCP/IP protocol stack
Like SSH, SSL also designates one side of the communicating party as a client and
the other side as a server. The client initiates the secure communications and the
server responds to the client’s request. The basic functionality of establishing an
encrypted communications channel can be combined with several options that SSL
offers, namely authentication of the communicating parties, separation of encryption
from authentication, and resumption of a previously established session. The figure
2.5 [Tho00] shows the exchange of messages called SSL handshake. The handshake
allows the server to authenticate itself to the client using public-key techniques, then
allows the client and the server to cooperate in the creation of symmetric keys used
30
for encryption and decryption of the session that follows. Optionally, the handshake
also allows the client to authenticate itself to the server. The individual messages
are summarized below.
ClientHello: With ClientHello message the client starts the communication between
the two parties. This message contains the various SSL options like version, cryp-
tographic services and compression methods the client can support.
ServerHello: This message is a response to the request made by the client and con-
tains the final decision made by the server regarding the options proposed by the
client.
Certificate: Server sends its public key certificate in this message. It is the responsi-
bility of the client to make sure that the certificate is issued by a trusted certificate
authority and also to ensure that the certificate indeed belongs to the party with
whom it wants to communicate.
ServerKeyExchange: In this message the server sends the public key that the client
should use to encrypt its session key. Moreover the server signs this public key with
public key in its certificate.
Client
Internet
Server
ServerHello Certificate ServerKeyExchange ServerHelloDone
ClientHello
ClientKeyExchange ChangeCipherSpec Finished
ChangeCipherSpec Finished
Figure 2.5: SSL Handshake protocol
31
ServerHelloDone: This message indicates the client that the server is done with its
initial negotiation messages.
ClientKeyExchange: This message contains the session key information for the sym-
metric key algorithm which the two parties have negotiated. This information is
encrypted using the public key from the ServerKeyExchange message.
ChangeCipherSpec: This message is to indicate the other party that the negotiated
security services can be invoked for all future communications belonging to this ses-
sion. Finished: This message allows the other party to verify that the negotiation
has been successful and that security has not been compromised.
Both parties can now use the session key to encrypt and decrypt the data they send
to each other.
32
Chapter 3
Password Authenticated Protocols
3.1 Background
User authentication could be defined as a process in which one party is assured of
the identity of a second party involved in the protocol. It is generally accomplished
by one or more of the following:
1. something known. Examples include standard passwords, Personal Identifica-
tion Numbers (PINs), and the secret or private keys whose knowledge is used
in challenge-response protocols.
2. something possessed. This is normally a physical accessory like, magnetic-
striped cards, chipcards and hand-held customized calculators (password gen-
erators) which provide time-variant passwords.
3. something inherent (to a human individual). This category includes meth-
ods which make use of physical characteristics and actions of human be-
ings(biometrics), such as handwritten signatures, fingerprints, voice, retinal
patterns, hand geometries, and dynamic keyboarding characteristics.
The least expensive and the most convenient solutions for user authentication have
been based on the first category. But authentication without key exchange would
not help much. These two topics need to be considered jointly rather than sepa-
rately. As pointed out in [DvOW92], a protocol providing authentication without
33
key exchange is susceptible to an enemy who would wait until the authentication is
complete and then takes over one end of the communications line. Same is the case
with key exchange that is independent of authentication. So it is quite important
to make sure that the key exchanged is in fact shared with the intented party and
not an adversary.
In [MPS00], the authors of SNAPI classify user authentication schemes into those
that require persistent data to be stored on the user’s system and those that do
not. The former category includes schemes similar to ssh, where persistent partici-
pant specific information is stored on the client’s system. As mentioned above these
schemes require extra security assumptions. The second category includes password
based protocols like the popular (Encrypted key exchange)EKE family protocols.
These were later followed by Augmented-EKE (A-EKE), Modified-EKE (M-EKE),
Simple Password EKE (SPEKE), Diffie-Hellman EKE (DH-EKE), Secure Remote
Password protocol (SRP) and so on.
In recent years several password-only protocols have been proposed and the reason
for growing importance is they are based on direct trust between a user and a server,
and do not require the user to store long secrets or data on the user’s system.
These protocols can be used not only for user authentication with the server but
also for mutual authentication between any two users. Below we summarize the
characteristics of password-based key establishment protocols:
1. The passwords selected by users usually belong to a small dictionary and have
a small entropy which makes it possible for the adversary to search through
all possible passwords in a reasonable time.
2. Off-line dictionary attacks should not be possible. This means that the ad-
versary should not be able to partition the dictionary into valid and invalid
passwords by just gathering information during a valid exchange.
3. On-line dictionary attacks should not be feasible. These attacks can be easily
detected, and thwarted, by counting access failures.
34
4. Should provide for mutual authentication.
To better understand password based protocols, let us consider a scenario where
Alice and Bob want to exchange some highly confidential information. Both share
nothing but a short secret which they wish to use to authenticate themselves over
an insecure network. Since the secret is short, it is susceptible to dictionary attacks.
Alice and Bob not only wish to authenticate themselves but also establish a secure
channel on the basis of this short secret. Although this may seem a little contradic-
tory, it is possible and this is exactly the topic of the dissertation.
The SNAPI protocol provides mutual authentication and key exchange between a
client and a server based solely on a password and does not require the client to
store any information specific to the server. It is based on Lucks Open Key Ex-
change (OKE) [Luc97] protocol. It achieves perfect forward secrecy, requires just 4
moves, one RSA operation each side and the standard operations for Diffie-Hellman
key exchange. The security of the protocol is proved in the communication model
of Bellare, Pointcheval and Rogaway [BPR00]. In this model, the adversary totally
controls the network. We prove that if the adversary is able to do non-negligibly
better than by simply guessing passwords, then the RSA security assumption is false.
Related Work
The concept of password-authenticated key exchange was first proposed by Bellovin
and Merritt [BM92]. In their paper, Encrypted Key Exchange (EKE) protocol
was proposed as a solution. EKE uses a combination of symmetric and public-key
cryptographic techniques and provides the adversary with insufficient information
to verify his guessed password and is thus resistant to offline-dictionary attacks.
Later on the authors of EKE extended their protocol to Augmented EKE (A-EKE)
[BM93] to detect the attack on the host where the password is stored by avoiding
storing the password in clear text format. EKE can also be implemented based
on Diffie-Hellman key exchange (DH-EKE) [Jab96] and the only difference is that
the messages exchanged between the parties are encrypted using the shared pass-
word. In 1996, David Jablon proposed SPEKE (Simple Password Encrypted Key
35
Exchange) [Jab96] as the extension of EKE. Besides preventing password from
dictionary attack, DH-EKE and SPEKE protocols achieve perfect forward secrecy,
that is the disclosure of the password does not compromise the remaining session
keys. Other notable protocols in this category are Secure Remote Password pro-
tocol (SRP) [Wu98], Modified EKE (M-EKE) [STW95] and Open Key Exchange
(OKE) [Luc97]. But none of these provide any formal security proofs and in fact,
many have been shown to be insecure.
The EKE protocols seem to work well with Diffie-Hellman key exchange, but not
with other public-key cryptosystems like the RSA. The OKE protocol which is
based on RSA was the first provable approach based on the work of Bellare and
Rogaway [BPR00] and was followed by SNAPI [MPS00]. In their paper the au-
thors of SNAPI first show that OKE protocols are insecure and then modify it to
a more secure SNAPI protocol. In 2004, Muxiang Zhang presents a new password
authenticated key exchange protocol called PEKEP [Zha04]. The SNAPI protocol
requires the public exponent e to be larger than the RSA modulus n. In contrast to
SNAPI, PEKEP allows the usage of both small and large prime numbers as RSA
public exponents. Our concentration would be mainly on SNAPI and its proof of
security.
The rest of this chapter is organized as follows. In section 3.1 we describe the
communication model which is used for our protocol and proofs. In section 3.2, the
protocol is presented and in section 3.3 we prove that SNAPI is a secure mutual
authentication and key exchange protocol.
3.2 Model
The communication model presented in this section is taken from Bellare and Ro-
gaway [BPR00]. In this model the adversary plays a central role. He can (1)read
the messages exchanged between entities; (2)provide messages of his own to them;
(3)modify messages before they reach their destination; (4)delay messages or replay
36
them. With regard to sessions, the adversary can initiate session between any two
entities, can engage in multiple sessions with the same entity at the same time and
also ask an entity to enter a session with itself. Each entity will be modeled by an
infinite collection of oracles which the adversary may run.
Protocol participants: Let ID be a non-empty set of principles where each member
is either a client or a server. In fact, ID = Clients ∪ Servers, where Clients andServers are finite disjoint non-empty sets. We label each principle U ∈ ID by a
string and we use U to denote this string. We assign to each client C ∈ Clients
a password πC ∈R D, where D is a small dictionary of passwords. Each server
S ∈ Servers maintains a vector of passwords πS = 〈πS[C]〉C∈Clients which contains
an entry per client. Clients and servers are modeled as probabilistic polynomial-time
algorithms.
Execution of the protocol: The protocol P is modeled as a probabilistic algorithm
that defines how instances of the principles behave to inputs from their environment.
The adversary A is also modeled as a probabilistic algorithm who has access to
unlimited number of instances of each principle. An instance i of principle U is
denoted ΠUi . It is the adversary who sends inputs to these instances. The adversary
A communicates with the instances via the following queries. These queries areformally defined by Bellare and Rogaway in [BPR00] and summarized below.
(1.) Send(U, i,M): This query causes a message M to be sent to instance ΠUi . The
instance computes what the protocol says to and sends the response back to
A. Should the instance accept or terminate, this fact, is also shown to theadversary. To initiate a session between a client C and server S, the adversary
should send message M = S to an unused instance of the client C.
(2.) Execute(C, i, S, j): This query causes honest execution of the protocol to be
carried out between ΠCi (C ∈ Clients) and ΠS
j (S ∈ Servers) and outputs
the transcript of the execution. This query models a passive adversary who
simply eavesdrops on the execution of the protocol.
37
(3.) Reveal(U, i): This query causes instance ΠUi to output its session key.
(4.) Test(U, i): This query is answered by tossing a fair coin b ∈ 0, 1 and return-ing the session key K i
U if b = 0, or else a random sample if b = 1. This query
can be asked anytime during the execution of the protocol, but may only be
asked once.
(5.) Corrupt(U): This query outputs πU and states of all instances of U .
Partnering: A client or a server instance that accepts holds a partner-id pid, session-
id sid and session key K. We say a client instance ΠCi (C ∈ Clients) and a
server instance ΠSj (S ∈ Servers) to be partnered if both instances accept hold-
ing (pid, sid,K) and (pid′, sid′, K ′) respectively and the following conditions hold.
• sid = sid′ and K = K ′ and pid = C and pid′ = S.
• no other instance accepts with session-id equal to sid.
Freshness: An instance ΠUi is said to be fresh unless either:
• a Reveal(U, i) query occurs,
• a Reveal(U ′, j) query occurs where ΠU ′,j is a partner of ΠUi , or
• a Corrupt(U ′) query occurs.
Advantage of the adversary: We define authenticated key exchange advantage of
the adversary against a protocol P as follows. Let SuccakeP (A) be the event thatthe adversary has made a single Test query directed to some instance ΠU
i which has
terminated, and outputs a bit b′, where b′ = b for the bit b selected by ΠUi in the
Test query. The ake advantage of the adversary is defined as,
AdvakeP (A) = 2Pr(SuccakeP (A))− 1.
RSA Security Assumption: Let k be the security parameter. Let key generator GE
define a family of RSA functions. For any probabilistic polynomial-time algorithm A,
SuccRSAk (A) = Pr[ue ≡ w mod N : ((N, e), (N, d))← GE(1k);w ∈R Z∗N ;u← A(1k, w, e,N)].
38
The RSA security assumption states that for any probabilistic polynomial-time al-
gorithm A, SuccRSAk (A) is negligible.
3.3 The Protocol
Preliminaries: The protocol uses two security parameters, k and l. The security
parameter k is used for hash functions and secret keys(128 to 160 bits) and the se-
curity parameter l > k is used for RSA and discrete-log-type public keys (say 1024
to 2048 bits). Let 0, 1∗ denote the set of finite binary strings and 0, 1n the setof binary strings of length n. Let ”|” denote the concatenation of bit of strings in0, 1∗. A real-valued function ε(n) is negligible if for every c > 0, there exists a
nc > 0 such that ε(n) < 1/nc for all n > nc.
Let A and B be the identities of the two players, where A refers to Alice(Server)and B refers to Bob(Client). Before the protocol begins both of them agree on acommon password π ∈ P . Now Alice generates an RSA key pair (e, d) using the
key generator GE, (e, d,N) ← GE(1l), where N = PQ,P,Q ∈ [2l/2−1, 2l/2]. P,Q
are randomly chosen prime numbers and e ∈ (2l, 2l+1] is also a prime.
Let h, h′ and H denote hash functions where h, h′ : 0, 1∗ → 0, 1k and H :
0, 1∗ → 0, 1η (where η ≥ l + k). Let g be the generator of a cyclic group Ω of
size ω superpolynomial in k in which the Diffie-Hellman problem is hard.
The protocol [MPS00] is shown below.
39
I Bob: 1. Send username to Alice
II Alice: 1. Generate DH parameter (p, g)
2. Choose α ∈R Zω
3. Calculate m = gα in group Ω
4. Generate RSA keys.
5. Send (m,N, e) to Bob.
III Bob: 1. If N /∈ [2l, 2l+1], or e is not prime, then reject,
2. Else,
(a) Choose β ∈R Zω and a ∈R Z∗
N
(b) Calculate µ = gβ in group Ω
(c) Compute p = H(N |e|m|µ|A|B|π).(d) If gcd(p,N) 6= 1 or p ≥ 2η − (2η mod N), then set q = a.
(e) Else, set q ≡ pae mod N .
(f) Send (µ, q) to Alice.
IV Alice: 1. If gcd(q,N) 6= 1, then reject,2. Else,
(a) Compute p′ = H(N |e|m|µ|A|B|π).(b) If gcd(p′, N) 6= 1 or p′ ≥ 2η − (2η mod N), then reject,(c) Else,
i. Set a′ ≡ (q/p′)d mod N .ii. Set r = h(a′).
(d) Send r to Bob.
V Bob: 1. If gcd(p,N) = 1, p < 2η − (2η mod N) and r = h(a), then
(a) Accept
(b) Compute session key mβ .
(c) Send t = h′(a) to Alice.
2. Else, reject.
VI Alice: 1. If t = h′(a′), then
(a) Accept.
(b) Compute session key µα.
2. Else, reject.
Table 3.1: The SNAPI Protocol
40
3.4 Security Proof
In this section we show that SNAPI is a secure authenticated key exchange protocol
with respect to an adversary that does not make any corrupt queries (we do not
consider forward secrecy).
Let tmult be the time taken to perform an l-bit modular multiplication, texp be
the time taken to perform an l-bit modular exponentiation and tgen denote the
time taken by the key the generation function GE(1l) to generate RSA keys. Let
SuccRSAk (t) = maxASuccRSAk (A), where the maximum is taken over all A withtime complexity at most t.
Theorem 3.4.1 Let k be the security parameter and let P be the SNAPI protocol.
Let A be an adversary that runs in time t, interacts with nsrvs distinct Alice in-
stances, makes nse Send queries, nex Execute queries, nrvl Reveal queries and nro
queries to the random oracle. Then we have,
AdvakeP (A) ≤ nse|D|+O
(
nsrvsSuccRSAk (t′) +
(nse + nro)
2η+(nro + nse + nex)(nse + nex)
2k
)
where t’=(t+ (nro)2tmult + (nse + nex + nro)texp + nsrvstgen) and D is the dictionary
of passwords.
The security of a password based protocol as defined in [MPS00] states, if d = |D|is the size of the dictionary D and v, the number of impersonation attempts made
by the adversary, then the adversary should have a probability of success at most
v/d + ε, where ε is negligible. In the proof below, we show that the second half of
the equation on the right-hand side of the theorem is negligible. But if the size of
the dictionary is small then the probability might not be negligible. The only way
to keep even the first half of the equation negligible, is by limiting the number of
impersonation attempts.
Proof: In this section we incrementally define a sequence of protocols P0, P1, . . . , P6
with P0 = P . The protocols are summarized below. As we move from protocol
41
Pi to Pi+1, we prove that the advantage of adversary A attacking protocol Pi+1 is
negligibly more than the advantage of A attacking Pi.
1. P0 The original protocol P .
2. P1 Here we define a simulator which takes a challenge encryption function
and ciphertext as input, chooses a password randomly from D and simulates
random oracles and all instances of Alice and Bob.
3. P2 If the choice of m or µ values have already been used in some previous
execution, the protocol halts and the adversary fails. Likewise, if a collision of
random oracle output occurs the protocol halts and the adversary fails.
4. P3 Here we abort all executions of the protocol when the adversary has been
lucky in guessing the output of any of the random oracles.
5. P4 In this protocol, we abort executions wherein the adversary makes a pass-
word guess against a Bob instance and an Alice instance that are paired.
6. P5 In this protocol, we abort executions wherein the adversary makes two
password guesses against a same Alice instance.
Protocol P1: Let M denote the simulator which takes the following parameters as
input.
(a). The encryption function (N ∗, e∗) where N ∗ ∈ [2l, 2l+1], e∗ is prime and e∗ ∈(2l, 2l+1].
(b). Ciphertext z∗ such that ze∗ mod N∗
= z∗.
M chooses a password π∗ ∈R D. The hash functions h, h′ and H are simulated as
random oracles. M maintains internal tables for each of these functions to store the
queries and responses which M has calculated. The h, h′, H oracles return random
values for new queries otherwise they would return the appropriate stored values.
Below we show how M responds to the various oracle queries.
42
1. Bob Step 1: Query: null, Currently stored session values: none.
Description: Here M would run the normal step 1 procedure for Bob by send-
ing his username to Alice.
2. Alice Step 2: Query(B), Currently stored session values: none.Description: Here M would run the normal step 2 procedure for Alice except
M uses (N ∗, e∗) as the encryption function instead of generating a new RSA
key pair.
(a) Choose α ∈R Zω
(b) Set m = gα
(c) Send (m,N ∗, e∗) to Bob.
3. Bob Step 3: Query(m,N, e), Currently stored session values: none.
Description: M runs the normal step 3 procedure for Bob.
(a) If N /∈ [2l, 2l+1], or e is not prime, then reject,
(b) Else,
i. Choose β ∈R Zω and α ∈R Z∗N
ii. Set µ = gβ
iii. Compute p = H(N |e|m|µ|A|B|π∗).
iv. If gcd(p,N) 6= 1 or p ≥ 2η − (2η mod N), then set q = a.
v. Else, set q ≡ pae mod N .
vi. Send (µ, q) to Alice.
4. Alice Step 4: Query(µ, q), Currently stored session values: (m,N ∗, e∗).
Description: SinceM does not have RSA private key corresponding to (N ∗, e∗),
it has to follow a slightly different procedure for the computation of r. We
have seen that h-table stores queries and responses i.e., (a, r). To check an
encrypted value a∗ against a record (a, r) M can test if ae∗
mod N∗ = a∗.
(a) If gcd(q,N ∗) 6= 1, then reject,
(b) Else,
43
(i.) Compute p′ = H(N ∗|e∗|m|µ|A|B|π∗).
(ii.) If gcd(p′, N∗) 6= 1 or p′ ≥ 2η − (2η mod N∗), then reject,
(iii.) Else, set r = h(q/p′ mod N∗).
(iv.) Send r to Bob.
5. Step 5 Bob: Query(r), Currently stored session values: (m,N, e, a, p, µ, q)
Description: SinceM does not have RSA private key corresponding to (N ∗, e∗),
it has to follow a slightly different procedure for the computation of t. We
have seen that h′-table stores queries and responses i.e., (a, t). To check an
encrypted value a∗ against a record (a, t) M can test if ae∗
mod N∗ = a∗.
(a) If gcd(p,N) = 1, p < 2η − (2η mod N) and either ((N, e) = (N ∗, e∗) and
r = h(q/p mod N ∗)) or ((N, e) 6= (N ∗, e∗) and r = h(a)), then
(i.) Accept
(ii.) Compute session key mβ.
(iii.) If ((N ∗, e∗)) = (N, e), send t = h′(q/p mod N ∗) to Alice.
(iv.) Else, send t = h′(a) to Alice.
(b) Else, reject.
6. Step 6 Alice: Query(t), Currently stored session values: (m,N ∗, e∗, p′, µ, q, r)
Description: M runs the normal step 6 procedure for Alice except that en-
crypted value of a is used in h′ oracle to compare it with the received t.
(a) If t = h′(q/p′ mod N∗), then
(i.) Accept.
(ii.) Compute session key µα.
(b) Else, reject.
We see that P1 is indistinguishable from P0. Hence
AdvakeP1(A) = AdvakeP0
(A). (3.1)
44
Protocol P2: Here we simulate all oracles as in P1, except when a collision has been
detected we abort all executions of the protocol. Below we calculate the probability
of occurrence of an m-collision, µ-collision, p-collision, r-collision and t-collision.
1. An m-collision is said to occur when the m value generated by Alice in Step 2
is equal to either,
• a previously generated m by Alice in Step 2,
• a previous m value sent as input to Bob in Step 3, or
• a previous m value used in H-oracle query made by the adversary.
The µ-collision is said to occur when the µ value generated by Bob in Step 3
is equal to either,
• a previously generated µ by Bob in Step 3,
• a previous µ value sent as input to Alice in Step 4, or
• a previous µ value used in H-oracle query made by the adversary.
But this may cause the protocol executions to abort with a probability of
((nse + nex)(nse + nex + nro)/2k).
2. A p-collision is said to occur when H-oracle query returns a value p = p′ for
some p′ returned from a previous H-oracle query. But this may cause the
protocol executions to abort with a probability of (nro)/2η.
3. A r-collision is said to occur when h-oracle query returns a value r which
matches either a previously returned value from the h-oracle or an r-value
sent to Bob in Step 5. But this may cause the protocol executions to abort
with a probability of (nro + nse)/2k.
4. A t-collision is said to occur when h′-oracle query returns a value t which
matches either a previously returned value from the h′-oracle or a t-value sent
to Alice in Step 6. But this may cause the protocol executions to abort with
a probability of (nro + nse)/2k.
45
We see that P2 is identical to P1 except that if any of the above mentioned collisions
occurs, the protocol halts and the adversary fails. From the above discussion we
have,
AdvakeP2(A) ≤ AdvakeP1
(A) +O
(
(nro)
2η+(nse + nex)(nro + nse + nex))
2k
)
(3.2)
Protocol P3: Now suppose the adversary has been lucky in guessing the value of
p, without asking the corresponding H-oracle. This can be detected when Alice
receives a (µ, q) query and no corresponding adversarial H-oracle query has been
made. The total probability of this event occurring is bounded by nse/2η. Now
suppose the adversary has been lucky in guessing the value of r, without asking the
corresponding h-oracle. This can be detected when Bob receives an (r) query and no
corresponding adversarial h-oracle query has been made. The total probability that
Bob accepts instead of aborting is bounded by nse/2k. Similar explanation could be
given for t being luckily guessed by the adversary. We see that P3 is identical to P2
except when any of the above events occurs, the protocol halts and the adversary
fails. From the above discussion we have,
AdvakeP2(A) ≤ AdvakeP3
+O(nse2η+nse2k
)
(3.3)
Protocol P4: Here we show that if the adversary has made a password guess against
an Alice instance and a Bob instance that are paired, then the adversary is capable
of breaking RSA. To prove this we construct an algorithm D which attempts to
break RSA by running adversary A against our simulator M . We use the simulatordefined in P1 with the following changes.
1. Choose an Alice instance ΠAτ and for this particular instance use (N
∗, e∗) as
the encryption function.
2. H-oracle: Query(N ∗|e∗|m|µ|A|B|π)
(a) Pick c ∈R Z∗N∗ .
(b) Find a p < 2η − 2η mod N∗ such that p ≡ ce∗ mod N∗.
(c) Return p.
46
3. In Bob Step 3 query, let aτ ∈R Z∗N∗ and set q ≡ z∗ae
∗
τ mod N∗. Recall that z∗
is the challenge ciphertext.
4. When A finishes, for every paired instances of Alice and Bob, check if therehas been an adversarial h-oracle query with q/p mod N ∗ as parameter, where
p = H(N ∗|e∗|m|µ|A|B|π) and p < 2η − 2η mod N∗. If so, we were able to
successfully decrypted z∗ to z = ca/aτ as shown below.
ae∗ ≡ (q/p) mod N ∗
≡ (z∗ae∗τ /ce∗
) mod N ∗
≡ (zaτ/c)e∗
mod N∗
We see that P4 is indistinguishable from P3 except when the adversary attempts a
password guess against paired instances of Alice and Bob, we output a z such that
ze∗ ≡ z∗ mod N∗ and halt. Thus, we have
AdvakeP3(A) ≤ AdvakeP4
(A) +O(nsrvsSuccRSAk (t′)) (3.4)
Protocol P5: In this protocol, we show that if the adversary has made two password
attempts against same Alice instance, then the adversary is capable of breaking
RSA. To prove this we follow the same approach as in P4. We use the simulator
defined in P1 with the following changes.
1. Choose an Alice instance ΠAτ and for this particular instance use (N
∗, e∗) as
the encryption function.
2. H-oracle: Query(N ∗|e∗|m|µ|A|B|π)
(a) Pick c ∈R Z∗N∗ .
(b) Find a p < 2η − 2η mod N∗ such that p ≡ (z∗)bce∗ mod N∗, where b ∈R0, 1.
(c) Return p.
When A finishes, we should be having two H-oracle queries with input values
N∗|e∗|m|µ|A|B|π1 and N∗|e∗|m|µ|A|B|π2 and output values p1 and p2 respectively,
47
where p1, p2 < 2η−2η mod N∗, ae
∗
1 ≡ q/p1 mod N∗, ae
∗
2 ≡ q/p2 mod N∗ and b1 6= b2.
If so, we have successfully decrypted the ciphertext z∗ as follows,
p1ae∗
1 mod N∗ ≡ p2a
e∗
2 mod N∗
(z∗)b1(a1c1)e∗ mod N∗ ≡ (z∗)b2(a2c2)
e∗ mod N∗
(z∗)b1
(z∗)b2mod N∗ ≡
(
a2c2a1c1
)e∗
mod N∗
z ≡(
a2c2a1c1
)b1−b2
mod N∗
We see that P5 is indistinguishable from P4 except when the adversary makes two
different password attempts against a same instance of Alice, the with a probability
1/2 we output a z such that ze∗ ≡ z∗ mod N∗ and halt. Thus, we have
AdvakeP4(A) ≤ AdvakeP5
(A) +O(nsrvsSuccRSAk (t′)) (3.5)
The theorem is hence proved from equations 3.1 through 3.5
3.5 Comparison with the known solutions
We have seen the different types of solutions to remote authentication in chapter 2.
After having thoroughly analysed the SNAPI protocol, its time to look at the disad-
vantages of current methods with respect to the SNAPI protocol. The disadvantages
are:
1. They rely on a public-key infrastructure (PKI) thereby dealing with issues like
user registration, key management and key revocation. As already mentioned,
this might not be suitable for environments where the memory is scarce or in
cases when user mobility is of concern.
2. In case of SSL, the user may easily oversee the existence of a secure channel
(lock sign on the browser) before sending his password.
3. The user normally also does not verify whether the certificate actually belongs
to the organization with which it wants to communicate. This is not a trivial
48
task as the user has to browse through the entire list of certificates loaded in
his browser.
4. In some cases the user might have to verify the fingerprint of the certificate
authority. This puts extra burden on the user. If the client fails to do so, it
can be easily susceptible to man-in-the-middle attack.
5. None of these technologies have been proven secure as is the case with SNAPI.
49
Chapter 4
Implementation of the SNAPI
protocol
In this chapter we show how to implement a small application based on the SNAPI
protocol in the Java programming language. Here we develop a simple client-server
application, where the client tries to authenticate to server using his password. The
communication between the client and the server is implemented using Java Sock-
ets and the SNAPI part of the application is developed using Java Cryptographic
Extension (JCE) and FlexiCore, a cryptographic service provider(explained later in
section JCE). We start this chapter with a brief introduction to Java Sockets, JCE
and the FlexiCore package. Then we look at the implementation of our application.
4.1 Java Socket Programming
A socket represents the end-point of a communication channel and is identified by a
an address and port number. A server running on a computer waits, listening to the
socket for the incoming client requests. In order to make use of the service provided
by the server, the client has to know the hostname of the machine on which the
server is running and the port number to which the server is connected. Then the
client can send a request to the server. Once the request has been accepted the
server is given a different port to communicate with the client, so that it can listen
50
to requests from other clients on its original port. On the client-side, once a request
has been accepted, the client is also assigned a local port to communicate with the
server. Please refer to Java API for more details.
4.2 Java Cryptography Extension
The security API of the Java programming language allows developers to incor-
porate cryptographic functionality into their applications. The Java Cryptography
Architecture (JCA) is a framework for the cryptographic functionality comprising
of this security API. The Java Cryptographic Extension (JCE) is a companion to
JCA, which provides implementations for several encryption, key generation and key
agreement and Message Authentication Codes algorithms. The design principles of
JCE include:
• implementation independence and interoperability
• algorithm independence and extensibility.
JCE achieves algorithm independence by defining certain ”engines”(services), and
classes which provide the functionality for these services. These classes are called
engine classes.
Implementation independence is achieved using a ”provider”-based architecture.
A cryptographic service provider is a package that implements one or more crypto-
graphic services. The program can request the implementation for a specific service
from one of the installed providers or a particular provider as desired. Providers can
be updated transparently to the application. FlexiCore is one such provider which
includes implementations of several cryptographic algorithms of which we make use
of RSA and Diffie-Hellman key-exchange for our SNAPI protocol.
Installation of the security provider is a two step process.
1. Include the zip or jar file containing the provider classes in classpath.
2. Then we need to register the provider. This can be done in two ways.
51
• Statically, by adding the following to java.security:security.provider.N=de.flexiprovider.core.FlexiCoreProvider
where N is the preference order that you define for each installed provider.
• Dynamically, by adding the following into each application:Security.addProvider(new de.flexiprovider.core.FlexiCoreProvider());
4.3 SNAPI
The interface to the SNAPI application is a simple login form, where the user can
enter his username and password. A snapshot is shown below.
Figure 4.1: Login form
Once the user has entered his username, password and pressed the ”Login” but-
ton, the protocol begins. Now we look at code snippets for significant points in each
step of the protocol. Please refer to the Appendix for more details.
Hash functions
In [MS99], Philip MacKenzie and Ram Swaminathan give a recommendation for
the implementation of hash functions. We use a slightly modified version for our
implementation. Let hash denote the underlying hash function which in our case
is RIPEMD-160. Then h, h′ and H are computed as follows. The hash functions h
and h′ are differentiated using the bit strings ”10” and ”11” as shown below.
h(x) = hash(10|x|x|10), h′(x) = hash(11|x|x|11) (4.1)
52
From the algorithm we know that H outputs η ≥ l + k bits. We compute H as,
H(x) = hash(0|x|x|0)|hash(1|x|x|1)|hash(2|x|x|2) · · ·hash(i|x|x|i), (4.2)
where i = η/k, η is a multiple of k and h denotes the known hash function. In our
implementation η is set to 1280(160 ∗ 8) bits.
Set up host machine
Before Bob can send in his request, Alice needs to activate the service and wait for
incoming requests. This is done by instantiating a server socket as shown below.
The accept method waits until a client starts up and requests a connection on
the host and port of this server. When a connection is requested and successfully
established, the accept method returns a new Socket object which is bound to a
new port. The server can communicate with the client over this new Socket and
continue to listen for client connection requests on the ServerSocket bound to the
original, predetermined port. In this application each client is run in a seperate
thread which allows the server to attend to several clients simultaneously. Please
refer to the program code in Appendix for more details.
serverSocket = new ServerSocket(CommonConstants.PORT);
...........
clientSocket = serverSocket.accept();
Bob Step 1
In this step Bob opens a client socket and sends his username to Alice. Obviously
Bob needs to know the hostname and the port number of the machine on which Alice
is running. Here InetAddress represents an Internet Protocol address. CommonCon-
stants.ADDRESS can contain either the fully qualified hostname or the IP-address
and CommonConstants.PORT contains the port number. Once the socket has been
opened, we could read from and write to it using the input stream and output stream
respectively. The following code snippet shows how this is done.
//Open a client socket with the hostname and port number
of the machine on which Alice is running.
clientSocket = new Socket(InetAddress.getByName(CommonConstants.ADDRESS),
CommonConstants.PORT);
............
//Send username of Bob to Alice
OutputStream os = clientSocket.getOutputStream();
53
oos = new ObjectOutputStream(os);
oos.writeObject(bobsUsername);
Alice Step 2
The important points to be noticed in this step are the generation of keys.
1. To generate Diffie-Hellman key pair, Alice first creates DH parameters and
then generates the key-pair using these parameters as shown below.
// Create the parameter generator for a 160-bit DH key pair
AlgorithmParameterGenerator paramGen =
AlgorithmParameterGenerator.getInstance("DH");
paramGen.init(L/2);
// Generate the parameters
AlgorithmParameters params = paramGen.generateParameters();
.............
// Generate key-pair
KeyPairGenerator keyGen = KeyPairGenerator.getInstance("DH");
DHParameterSpec dhSpec = new DHParameterSpec(p, g, l);
keyGen.initialize(dhSpec);
keypair = keyGen.generateKeyPair();
2. Then Alice generates the RSA key-pair as shown below.
RSAKeyPairGenerator generator = new RSAKeyPairGenerator();
KeyPair rsaKeyPair = generator.generateKeyPair();
Bob Step 3
In this step Bob receives m,N, e and computes µ, q as follows. The significant points
to be noticed in this step are the computation of p and encryption of a. The value of
p = H(N |e|m|µ|A|B|π) is computed using (4.2) and a is encrypted using the RSApublic key-pair sent by Alice.
MessageDigest mdc = MessageDigest.getInstance("RIPEMD160", "FlexiCore");
byte[] p = new byte[CommonConstants.ETA];
for(int i = 0; i < 8; i++)
mdc.update(BigInteger.valueOf(i).toString(2).getBytes());
mdc.update(rsaPublicKey.getModulus().toByteArray());
54
mdc.update(rsaPublicKey.getPublicExponent().toByteArray());
..............
append(p, mdc.digest());
BigInteger pBig = new BigInteger(p);
//Encrypt a
Cipher cipher = Cipher.getInstance("RSA_PKCS1_v1_5", "FlexiCore");
cipher.init(Cipher.ENCRYPT_MODE, rsaPublicKey, random);
byte[] encryptedMsg = cipher.doFinal(message.toByteArray());
Alice Step 4
The functions performed in this step are similar to those seen in previous steps
except with minor changes. Below we see the decryption of a and the computation
of r using (4.1).
//Decrypt a
Cipher cipher = Cipher.getInstance("RSA_PKCS1_v1_5", "FlexiCore");
cipher.init(Cipher.DECRYPT_MODE, rsaPrivateKey, random);
byte[] decryptedMsg = cipher.doFinal(message.toByteArray());
//Compute r
MessageDigest mdc = MessageDigest.getInstance("RIPEMD160", "FlexiCore");
mdc.update(Integer.toBinaryString(2).getBytes());
mdc.update(a.toByteArray());
mdc.update(a.toByteArray());
mdc.update(Integer.toBinaryString(2).getBytes());
retValue = new BigInteger(mdc.digest());
Bob Step 5
The value of t in this step is computed in exactly the same way as r in step 4 except
that the hash function h′ is used instead of h. If Alice has not rejected the connection
until this step, then Bob can now generate the shared session key as shown below.
//Decode the public key sent by Alice
KeyFactory bobKeyFac = KeyFactory.getInstance("DH");
X509EncodedKeySpec x509KeySpec =
new X509EncodedKeySpec(step1ObjRec.getEncodedM());
PublicKey m = bobKeyFac.generatePublic(x509KeySpec);
55
//Perform the next and the only phase in the key agreement
KeyAgreement bobKeyAgree = KeyAgreement.getInstance("DH");
bobKeyAgree.init(bobKpair.getPrivate());
bobKeyAgree.doPhase(m, true);
//Generate the shared session key
byte[] sharedSecret = bobKeyAgree.generateSecret();
Alice Step 6
Similar to Step 5.
Performance
Here we show how long the application takes to authenticate a specific client and
return the result back to it. Before we take a look at the results, here is a quick
overview of the sizes of various parameters used in the application.
1. Size of RSA encryption key (e) = 1025 bits
2. Size of RSA modulus (N) = 1024 bits
3. Size of DH prime modulus (p) = 512 bits
4. Size of DH base generator (g) = 511 bits
5. Size of DH random exponent = 511 bits
The results shown below were acquired on machines with Microsoft Windows 2000
operating system, Pentium 4 2.60GHz processor and 1024MB RAM. The client and
the server were connected to 100MBit/s LAN connection. The table 4.1 shows the
average time needed for each step of the SNAPI protocol (Table 3.1). Since Bob
step I involves no calculations, it is not included below. All time measurements are
in milliseconds.
56
Nr. Alice step II Bob step III Alice step IV Bob step V Alice step VI
1. 1438 2531 31 0 16
2. 4782 2422 47 15 0
3. 1422 2516 31 15 0
4. 4891 2328 31 15 16
5. 1547 2516 78 16 0
6. 8391 2421 31 16 16
7. 2515 2375 16 16 15
8. 2703 2359 32 15 0
9. 5046 2406 31 15 0
10. 3844 2469 31 15 0
Avg. 3657.9 2434.3 35.9 13.8 6.3
Table 4.1: Time(ms) taken for each step of the SNAPI algorithm
Figure 4.2: Program output for Bob
The average time taken for the client to get response back from the server is approx-
imately 6148.2 ms. This is definitely not practicable for commercial applications.
From table 4.1 it can be clearly seen that most of the time is spent in Alice step II
and Bob step III. Alice step II includes the generation of RSA and Diffie-Hellman
keys.
One way to improve performance in this step is to generate RSA keys once and
57
Nr. RSA Key generation DH Key generation
1. 750 672
2. 3891 891
3. 453 954
4. 1062 3813
5. 484 1063
6. 3234 5141
7. 1406 1109
8. 266 2421
9. 1390 3641
10. 454 3375
Avg. 1339 2308
Table 4.2: Time(ms) taken for RSA and DH key generation
use them for subsequent operations. This should reduce the total time by approx-
imately 1.5 secs. A better alternative to this would be the new password-based
protocol PEKEP proposed by Muxiang Zhang [Zha04]. This protocol allows the
usage of both small and large prime numbers as RSA public exponents and could
be used especially when RSA keys need to be generated fresh each time.
Now let us consider Bob step III in detail. This step also includes the Diffie-Hellman
key generation as well as the computation of µ and q. Note that here we generate
DH keys from the specification sent by Alice and therefore does not take that long
compared to DH key generation in Alice step II. As we see, there is little scope for
improving performance in this step.
58
Nr. Primality test DH Key Gen. Cal. of p Cal. Of q
1. 500 1421 47 516
2. 516 1297 62 516
3. 516 1406 63 515
4. 485 1250 46 500
5. 500 1375 63 547
6. 500 1328 62 516
7. 484 1297 62 516
8. 484 1265 47 515
9. 485 1296 63 547
10. 500 1375 47 500
Avg. 497 1331 56.2 518.8
Table 4.3: Time(ms) taken for each operation in Bob step III
One other improvement which could make the application scalable is to use a data-
base to store usernames and passwords on the server. To provide more security the
passwords should not be stored in plaintext, rather in some unreadable format such
as hash values. To match the increasing computing power, all one needs to do is
increase the size of the keys.
59
Chapter 5
Conclusion and Futurework
Password based authentication protocols gained a lot of importance during the past
few years which is seen by the vast number of papers published on this topic. As the
Internet tends to become a part of our daily life making life easier in many ways,
these protocols could help strengthen the trust between various parties involved.
Although there has been a lot of theoretical research in this direction, there has not
been a single commercial implementation of any of these protocols.
In this thesis we have seen a quick background of the known solutions to remote
authentication and establishment of a secure channel. Then we saw a quick introduc-
tion to password based protocols. In particular we saw the analysis and implemen-
tation of the SNAPI (Secure Network Authentication with Password Identification)
protocol. By the analysis and implementation of SNAPI, I tried to emphasize that
these protocols provide not only strong security but are also practicable. In the
SNAPI protocol, we have seen that authentication is as secure as RSA and key ex-
change is as secure as the Diffie-Hellman key exchange, a combination of two strong
public key technologies. The application developed in this thesis is just a starting
point to proving the feasibility of strong password based remote applications. It
could be modelled into a full fledged remote authentication application.
60
Bibliography
[BCK98] M. Bellare, R. Canetti, and H. Krawczky. A modular approach to the
design and analysis of authentication and key exchange protocols. Proc.
of the 30th STOC, pages 419–428, 1998.
[BCP03] E. Bresson, O. Chevassut, and D. Pointcheval. Security proofs for an
efficient password-based key exchange. Proceedings of the 10th ACM
Conference and Communications Security, 2003.
[BM92] S.M. Bellovin and M. Merritt. Encrypted key exchange: Password-based
protocols secure against dictionary attacks. Proceedings of the IEEE
Symposium on Research in Security and Privacy, pages 72–84, 1992.
[BM93] S. M. Bellovin and M. Merritt. Augumented encrypted key exchange:
A password-based protocol secure against dictionary attacks and pass-
word file compromise. Proceedings of the First Annual Conference on
Computer and Communications Security, pages 244–250, 1993.
[BM03] Colin Boyd and Anish Mathuria. Protocols for Authentication and Key
Establishment. Springer-Verlag, 2003.
[BPR00] M. Bellare, D. Pointcheval, and P. Rogaway. Authenticated key ex-
change secure against dictionary attacks. Advances in Cryptology - EU-
ROCRYPT 2000 Proceedings, 1807:139–155, 2000.
[BR93] M. Bellare and P. Rogaway. Random oracles are practical: A paradigm
for designing efficient protocols. In Proceedings of the First Annual Con-
ference on Computer and Communications Security, pages 62–73, 1993.
61
[BR94] M. Bellare and Phillip Rogaway. Entity authentication and key distribu-
tion. Advances in Cryptology - CRYPTO ’93 Proceedings, 773:232–249,
August, 1994.
[BS01] Daniel J. Barrett and Richard E. Silvermann. SSH, The Secure Shell:
The Definitive Guide. O’Reilly, 2001.
[DH76] W. Diffie and M. Hellman. New directions in crytography. IEEE Trans.
Info. Theory, 22(6):644–654, 1976.
[DvOW92] Whitfield Diffie, Paul C. van Oorschot, and Michael J. Wiener. Authen-
tication and authenticated key exchanges. Appeared in Designs, Codes
and Cryptography, 2:107–125, 1992.
[Jab96] D. Jablon. Strong password-only authenticated key exchange. ACM
Computer Review, ACM SIGCOMM, 26(5):5–26, 1996.
[Kob94] Neal Koblitz. A Course in Number Theory and Cryptography. Springer-
Verlag, 1994.
[KOY02] Jonathan Katz, Rafail Ostrovsky, and Moti Yung. Forward secrecy in
password-only key exchange protocols. Security in Communications Net-
works (SCN 2002), pages 29–44, 2002.
[Luc97] Stefan Lucks. Open key exchange: How to defeat dictionary attacks
without encrypting public keys. Proc. Workshop on Security Protocols,
1361:79–90, 1997.
[MPS00] P. MacKenzie, S. Patel, and R. Swaminathan. Password-authenticated
key exchange based on rsa. Advances in Cryptology-ASIACRYPT 2000
Proceedings, 1976:599–613, 2000.
[MS99] Philip MacKenzie and Ram Swaminathan. Secure network authentica-
tion with password identification. Presented at IEEE P1363a Working
Group Meeting, 1999.
62
[MvOV97] A. Menezes, P.C. van Oorschot, and S.A. Vanstone. Handbook of Applied
Cryptography. CRC Press, 1997.
[PHS03] Josef Pieprzyk, Thomas Hardjono, and Jennifer Seberry. Fundamentals
of Computer Security. Springer-Verlag, 2003.
[RSA78] R. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital
signature and public key cryptosystems. Comm. of the ACM, 21:120–
126, 1978.
[Sma03] Nigel Smart. Cryptography: An Introduction. McGraw-Hill, 2003.
[STW95] M. Steiner, G. Tsudik, and M. Waidner. Refinement and extension of
encrypted key exchange. ACM Operating Systems Review, 29:22–30,
1995.
[Tho00] Stephen A. Thomas. SSL and TLS Essentials:Securing the Web. Wiley,
2000.
[Wu98] T. Wu. The secure remote password protocol. Proceedings of the 1998
Internet Society Network and Distributed System Symposium, pages 97–
111, 1998.
[Zha04] Muxiang Zhang. New approaches to password authenticated key ex-
change based on rsa. Advances in Cryptology - ASIACRYPT 2004,
3329:230–244, 2004.
63