Kerberos Realms and Multiple Kerberi
Kerberos may be represented as follows:
A full-service Kerberos environment consisting of a Kerberos server, a number of clients, and a
number of application servers requires the following:
1. The Kerberos server must have the user ID (UID) and hashed password of all participating
users in its database. All users are registered with the Kerberos server.
2. The Kerberos server must share a secret key with each server. All servers are registered with
the Kerberos server.
Such an environment is referred to as a realm. Networks of clients and servers under different
administrative organizations typically constitute different realms. That is, it generally is not
practical, or does not conform to administrative policy, to have users and servers in one
administrative domain registered with a Kerberos server elsewhere. However, user in one real may
need access to servers in other realms, and some servers may be willing to provide service to users
from other realms, provided that those users are authenticated.
Kerberos provides a mechanism for supporting such inter-realm authentication. For two realms to
support inter-realm authentication, a third requirement is added:
3. The Kerberos server in each interoperating realm shares a secret key with the server in the
other realm. The two Kerberos servers are registered with each other.
The scheme requires that the Kerberos server in one realm trust the Kerberos server in the other
realm to authenticate its users. Furthermore, the participating servers in the second realm must also
be willing to trust the Kerberos server in the first realm.
We can describe the mechanism as follows:
1
Kerberos Realms and Multiple Kerberi (Cont 1)
A user wishing service on a server in another realm needs a ticket for that server. The details of the
exchange illustrated in Figure 14.2 are as follows:
1. C -> AS: IDc||IDtgs||TS1
2. AS -> C: EKc[Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs]
3. C -> TGS: IDtgsrem||Tickettgs||Authenticatorc
4. TGS -> C: EKc,tgs[Kc,tgsrem||IDtgsrem||TS4||Lifetime2||Tickettgsrem]
5. C -> TGSrem: IDvrem|| Tickettgsrem|| Authenticatorc
6. TGSrem -> C: EKc,tgsrem[Kc,vrem||IDvrem||TS6|| Ticketvrem]
7. C -> Vrem: Ticketvrem|| Authenticatorc
The ticket presented to the remote server (Vrem) indicates the realm in which the user was
originally authenticated. The server chooses whether to honor the remote request.
One problem presented by the foregoing approach is that it does not scale well to many realms. If
there are N realms, then there must be N(N-1)/2 secure key exchanges so that each Kerberos realm
can interoperate with all other Kerberos realms.
2
X.509 Authentication Service
ITU-T (International Telecommunication Union – Telecommunication Standardization Sector)
recommendation X.509 is part of the X.500 series of recommendations that define a directory
service. The directory is a server or distributed set of servers that maintains a database of
information about users. The information includes a mapping from user name to network address, as
well as other attributes and information about the users.
X.509 defines a framework for the provision of authentication services by the X.500 directory to its
users. The directory may serve as a repository of public-key certificates. Each certificate contains
the public key of a user and is signed with the private key of a trusted certification authority. X.509
defines alternative authentication protocols based on the use of public-key certificates.
X.509 is an important standard because the certificate structure and authentication protocols defined
in X.509 are used in variety of contexts (SSL, SET, etc.).
A third version of X.509 was issued in 1995 and revised in 2000.
Certificates
The heart of X.509 scheme is the public-key certificate associated with each user. These user
certificates are assumed to be created by some trusted certificate authority (CA) and placed in the
directory by the CA or by the user. The directory itself is not responsible for the creation of public
keys or for the certification function; it merely provides an easily accessible location for users to
obtain certificates.
Figure 14.3a shows the general format of a certificate, which includes the following elements
(www.dante.net/np/ds/osi/9594-8-X.509.A4.ps ):
3
Certificates (Cont 1)
1
Version: Differentiates among successive versions of the certificate format: the default
version is 1. If the Issuer Unique Identifier or Subject Unique Identifier are present, the value
must be version 2. If one or more extensions are present, the version must be version 3.
2 Serial number: An integer value, unique within the issuing CA, that is unambiguously
associated with this certificate
3 Signature algorithm identifier: The algorithm used to sign the certificate, together with any
associated parameters. Because this information is repeated in the Signature field at the end
of the certificate, this field has little, if any, utility
4 Issuer name: X.500 name of the CA that created and signed this certificate (about X.500
names see, for example, http://java.sun.com/products/jndi/tutorial/ldap/models/x500.html )
5 Period of validity: Consists of two dates: the first and the last on which certificate is valid
6 Subject name: The name of the user to whom this certificate refers. That is, this certificate
certifies the public key of the subject who holds the corresponding private key
7 Subject’s public key information: The public key of the subject, plus an identifier of the
algorithm for which this key is to be used, together with any associated parameters
8 Issuer unique identifier: An optional bit string field used to identify uniquely the issuing CA
in the event the X.500 name has been reused for different entities
9 Subject unique identifier: An optional bit string used to identify uniquely the subject in the
event the X.500 name has been reused for different entities
10 Extensions: A set of one or more extension fields. Extensions were added in version 3 and
are discussed later
11 Signature: Covers all of the other fields of the certificate; it contains the hash code of the
other fields, encrypted with the CA’s private key. This field include the signature algorithm
identifier
The unique identifier fields were added in version 2 to handle the possible reuse of subject and/or
issuer names over time. These fields are rarely used.
The standard uses the following notation to define a certificate:
CA<<A>> = CA{V,SN,AI,CA,TA,A,Ap}
Where
Y<<X>> = certificate of user X issued by certification authority Y
Y{I} = the signing of I by Y. It consists of I with an encrypted hash code appended
The CA signs the certificate with its private key. If the corresponding public key is known to a user,
then that user can verify that a certificate signed by the CA is valid.
4
Obtaining a User’s Certificate
User certificates generated by a CA have the following characteristics:
1 Any user with access to the public of the CA can verify the user public key that was
encrypted
2 No party other than the CA can modify the certificate without this being detected
Because certificates are unforgeable, they can be placed in a directory without the need for the
directory to make special efforts to protect them.
If all users subscribe to the same CA, then there is a common trust of that CA. All user certificates
can be placed in the directory for access by all users. In addition, a user can transmit his certificate
directly to other users. In either case, once B is in possession of A’s certificate, B has confidence
that message it encrypts with A’s public key will be secure from eavesdropping and that messages
signed with A’s private key are unforgeable.
If there is a large community of users, it may not be practical for all users to subscribe to the same
CA. Because it is the CA that signs certificates, each participating user must have a copy of the
CA’s own public key to verify signatures. This public key must be provided to each user in an
absolutely secure (with respect to integrity and authenticity) way so that the user has confidence in
the associated certificates. Thus, with many users, it may be more practical to for there to a number
of CAs, each of which securely provides its public key to some fraction of the users.
Now suppose that A has obtained a certificate from certification authority X1 and B has obtained a
certificate from CA X2. If A does not securely the public key of X2, then B’s certificate, issued by
X2, is useless to A. A can read B’s certificate, but A cannot verify the signature. However, if the
two CAs have securely exchanged their own public keys, the following procedure will enable A to
obtain B’s public key:
1. A obtains from directory, the certificate of X2 signed by X1. Because A securely knows
X1’s public key, A can obtain X2’s public key from its certificate and verify it by means of
X1’s signature on the certificate
2. A then goes back to the directory and obtains the certificate of B signed by X2. Because A
now has a trusted copy of X2’s public key, A can verify the signature and securely obtain
B’s public key
A has used a chain of certificates to obtain B’s public key. In the notation of X.509, this chain is
expressed as
X1<<X2>>X2<<B>>
In the same fashion, B can obtain A’s public key with the chain:
X2<<X1>>X1<<A>>
This scheme need not be limited to a chain of two certificates. An arbitrarily long path of CAs can
be followed to produce a chain. A chain with N elements would be expressed as
X1<<X2>>X2<<X3>>…XN<<B>>
In this case, each pair of CAs in the chain (Xi, Xi+1) must have created certificates for each other.
All these certificates of CAs by CAs need to appear in the directory, and the user needs to know
how they are linked to follow a path to another user’s public-key certificate. X.509 suggests that
CAs are arranged in a hierarchy so that navigation is straightforward.
Figure 14.4, taken from X.509, is an example of such a hierarchy. The connected circles indicate the
hierarchical relationship among the CAs; the associated boxes indicate certificates maintained in the
directory for each CA entry. The directory entry for each CA includes two types of certificates:
 Forward certificates: Certificates of X generated by other CAs
 Reverse certificates: Certificates generated by X that are the certificates of other CAs
5
Obtaining a User’s Certificate (Cont 1)
In this example, user A can acquire the following certificates from the directory to establish a
certification path to B:
X<<W>> W<<V>> V<<Y>> Y<<Z>> Z<<B>>
When A has obtained these certificates, it can unwrap the certification path in sequence to recover a
trusted copy of B’s public key. Using this public key, A can send encrypted messages to B. If A
wishes to receive encrypted messages from B, or to sign messages sent to B, then B will require A’s
public key, which can be obtained from the following certification path:
Z<<Y>> Y<<V>> V<<W>> W<<X>> X<<A>>
B can obtain this set of certificates from the directory, or A can provide them as part of its initial
message to B.
6
Revocation of Certificates
Recall from Figure 14.3 that each certificate includes a period of validity. Typically, a new
certificate is issued before the expiration of the old one. In addition, it may be desirable on occasion
to revoke a certificate before it expires, for one of the following reasons:
1. The user’s private key is assumed to be compromised
2. The user is no longer certified by this CA
3. The CA’s certificate is assumed to be compromised
Each CA must maintain a list consisting of all revoked but not expired certificates issued by that
CA, including both those issued to users and to other CAs. These lists should be posted on the
directory.
Each certificate revocation list (CRL) posted to the directory is signed by the issuer and includes
(Figure 14.3b) the issuer’s name, the date the list was created, the date the next CRL is scheduled to
be issued, and an entry for each revoked certificate. Each entry consists of the serial number of a
certificate and revocation date for that certificate. Because serial numbers are unique within a CA,
the serial number is sufficient to identify the certificate.
When a user receives a certificate in a message, the user must determine whether the certificate has
been revoked. The user could check the directory each time a certificate is received. To avoid the
delays (and possible costs) associated with directory searches, it is likely that the user would
maintain a local cache of certificates and lists of revoked certificates.
Authentication Procedures
X.509 also includes three alternative authentication procedures that are intended for use across a
variety of applications. All these procedures make use of public-key signatures. It is assumed that
the two parties know each other’s public key, either by obtaining each other’s certificates from the
directory or because the certificate is included in the initial message from each side. These
procedures are treated as strong contrary to simple authentication procedures in which a client is
authenticated to a server by sending him its identifier and password in clear or hashed together with
a timestamp and nonce (www.dante.net/np/ds/osi/9594-8-X.509.A4.ps ):
7
Authentication Procedures (Cont 1)
8
Authentication Procedures (Cont 2)
One-Way Authentication
One way authentication involves a single transfer of information from one user (A) to another (B),
and establishes the following:
1. The identity of A and that the message was generated by A
2. That the message was intended for B
3. The integrity and originality (it has not been sent multiple times) of the message
Note that only the identity of the initiating entity is verified in this process, not that of the
responding entity.
At minimum, the message includes a timestamp, t A , a nonce rA , and the identity of B and is signed
with A’s private key. The timestamp consists of an optional generation time and an expiration time.
This prevents delayed delivery of messages. The nonce can be used to detect replay attacks. The
nonce value must be unique within the expiration time of the message. Thus, B can store the nonce
9
One-Way Authentication (Cont 1)
until it expires and reject any new messages with the same nonce.
For pure authentication, the message is used simply to present credentials to B. The message may
also include information to be conveyed. This information, sgnData, is included within the scope of
the signature, guaranteeing its authenticity and integrity. The message may also be used to convey a
session key to B, encrypted with B’s public key.
Two-Way Authentication
In addition to the three elements just listed, two-way authentication establishes the following
elements:
4. The identity of B and that the reply message was generated by B
5. That the message was intended for A
6. The integrity and originality of the reply
The reply message includes the nonce from A, to validate the reply. It also includes a timestamp and
nonce generated by B. As before, the message may include signed additional information and a
session key encrypted with A’s public key.
10
Three-Way Authentication
Here, a final message from A to B is included, which contains a signed copy of the nonce rB . The
intent of this design is that timestamps need not be checked: Because both nonces are echoed back
by the other side, each side can check the returned nonce to detect replay attack. This approach is
needed when synchronized clocks are not available. It is not shown in Figure 14.5, but the response
from A also includes B to counter meet-in-the middle attack when opponent C intercepts messages
between A and B
( http://nob.cs.ucdavis.edu/classes/ecs153-1997-01/Postscript/kerbiso.ps ).
Timestamps in the protocol above are zeros because in the three-way authentication clocks are not
used.
11
X.509 Version 3
The X.509 version 2 format does not convey all of the information that recent design and
implementation experience has shown to be needed, such as:
1. The Subject field is inadequate to convey the identity of a key owner to a public-key user.
X.500 names may be relatively short and lacking in obvious identification details that may
be needed by the user. (The X.500 namespace is hierarchical. An entry is unambiguously
identified by a distinguished name (DN). A distinguished name is the concatenation of
selected attributes from each entry, called the relative distinguished name (RDN), in the tree
along a path leading from the root down to the named entry. Systems that are based on the
X.500, such as the LDAP (The Lightweight Directory Access Protocol (LDAP)
http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol ), and Microsoft's
Active Directory (http://en.wikipedia.org/wiki/Active_Directory ), each define its own string
representation. For example, in the LDAP, a DN's RDNs are arranged right to left, separated
by the comma character (","). Here's an example of a name that starts with "c=us" at the top
and leads to "cn=Rosanna Lee" at the leaf.
cn=Rosanna Lee, ou=People, o=Sun, c=us
Here's an example of the same name using the string representation of the Microsoft's Active
Directory:
/c=us/o=Sun/ou=People/cn=Rosanna Lee
The convention for that system is that RDNs are ordered left to right and separated by the
forward slash character ("/").
2. The Subject is also inadequate for many applications, which typically recognize entities by
an Internet e-mail address, a URL, or some other Internet-related identification
3. There is a need to indicate security policy information. This enables a security application or
function to relate an X.509 certificate to a given policy
4. There is a need to limit the damage that can result from a faulty or malicious CA by setting
constraints on the applicability of a particular certificate
5. It is important to be able to identify separately different keys used by the same owner at
different times. This feature supports key life cycle management, in particular, the ability to
updater key pairs for users and CAs on a regular basis or under exceptional circumstances
Rather than continue to add fields to a fixed format, standard developers felt that a more flexible
approach was needed. Thus, version 3 (http://www.ietf.org/rfc/rfc3280.txt )includes a number of
optional extensions that may be added to the version 2 format. Each extension consists of an
extension identifier, a criticality indicator, and an extension value. The criticality indicator indicates
whether an extension can be safely ignored. If the indicator has a value of TRUE and an
implementation does not recognize the extension, it must treat the certificate as invalid.
The certificate extensions fall into three main categories: key and policy information, subject and
issuer attributes, and certification path constraints.
12
Key and Policy Information
These extensions convey additional information about the subject and issuer keys, plus indicators of
certificate policy. A certificate policy is a named set of rules that indicates the applicability of a
certificate to a particular community and/or class of applications with common security
requirements. For example, a policy might be applicable to the authentication of electronic data
interchange (EDI) transactions for the trading of goods within a given price range.
The area includes the following:
 Authority key identifier: Identifies the public key to be used to verify the signature on this
certificate or CRL. Enables distinct keys of the same CA to be differentiated. One use of this
field is to handle CA key pair updating
 Subject key identifier: Identifies the public key being certified. Useful for subject key pair
updating. Also, a subject may have multiple key pairs and correspondingly, different
certificates for different purposes (e.g., digital signature and encryption key agreement)
 Key usage: Indicates a restriction imposed as to the purposes for which, and the policies
under which, the certified public key may be used. May indicate one ore more of the
following: digital signature, non-repudiation, key encryption, data encryption, key agreement
(e.g., when using Diffie-Hellman protocol, in which a key is not transmitted over the
network but its parts only: q - prime,   q - primitive root of q .
X A  q, YA   X A mod q, X B  q, YB   X B mod q, K  (YB ) X A  (YA ) X B , A -> B: Y A , B -> A:
YB ), CA signature verification on certificates, CA signature verification on CRLs.
 Private-key usage period: Indicates the period of use of the private key corresponding to
the public key. Typically, the private key is used over a different period from the validity of
the public key. For example, with digital signature keys, the usage period for the signing
private key is typically shorter than that for the verifying public key.
 Certificate policies: Certificates may be used in environments where multiple policies
apply. This extension lists policies that the certificate is recognized as supporting, together
with optional qualifier information
 Policy mappings: Used only in certificates for CAs issued by other CAs. Policy mappings
allow an issuing CA to indicate that one or more of that issuer’s policies can be considered
equivalent to another policy used in the subject CA’s domain.
Certificate Subject and Issuer Attributes
These extensions support alternative names, in alternative formats, for a certificate subject or
certificate issuer and can convey additional information about the certificate subject, to increase a
certificate user’s confidence that the certificate subject is a particular person or entity. For example,
information such as postal address, position within a corporation, or picture image may be required.
The extension fields in this area include the following:
 Subject alternative name: Contains one or more alternative names, using any of a variety of
forms. This field is important for supporting certain applications such as electronic mail, EDI
(http://en.wikipedia.org/wiki/Electronic_Data_Interchange
),
and
IPSec
(http://en.wikipedia.org/wiki/IPSec ) which may employ their own name forms.
 Issuer alternative name: Contains one or more alternative names, using any of a variety of
forms.
 Subject directory attributes: Conveys any desired X.500 directory attribute values for the
subject of this certificate.
13
Certification Path Constraints
These extensions allow constraint specifications to be included in certificates issued for CAs by
other CAs. The constraints may restrict the types of certificates that can be issued by the subject CA
or that may occur subsequently in a certification chain.
The extension fields in this area include the following:
 Basic constraints: Indicates if the subject may act as a CA. If so, a certification path length
constraint may be specified
 Name constraints: Indicates a name space within which all subject names in subsequent
certificates in a certification path must be located
 Policy constraints: Specifies constraints that may require explicit certificate policy
identification or inhibit policy mapping for the remainder of the certification path
One-Time Password (OTP)
We follow [L. Lamport, Password authentication with insecure communication. –
Communications of ACM, 1981, v. 24, No 11, 770-772].
Passwords can be compromised when they cross a network or from a server’s database. In previous
considerations, we assumed that there is a trusted third party and/or password database on the server
side is safe. But this may not be true, and OTP schemas give solution for such cases.
Solution is strongly based on one-way hash functions.
Lamport’s schema allows having some finite number, N , of authentications of a user to a server
before the initialization procedure will be required. In initialization procedure, the user and server
exchange securely secret information (by means of some special channel, personally, by ordered
mail, courier, or in some other secure way). Schema assumes that a password never crosses insecure
network, and the server’s password database might be compromised, but can’t be changed by an
intruder. The server and user use one and the same hash function, h , in the authentication
procedure. The server authenticates the user applying the hash function to a current “password”
value in it database. Actually, this value is derived from the passport, and is used as a current
password, which changes from one authentication to another. That’s why the schema is called “onetime password”. Current password depends on the authentication number and can’t exceed N . OTP
schemas represent “challenge-response” schemas.
Initialization Procedure
The client selects a password, p 0 , a number, N , calculates
p N  h N ( p0 ) ,
where
h i 1 ( x)  h(h i ( x)), h 0 ( x)  x .
The client securely delivers to the server ( N , p N ) , and the servers saves it into
( Counter, password , Client _ ID ) tuple.
14
Authentication Procedure
When the client, C, requests authentication by the server, S, the following proceeds:
1. C -> S: C_ID //client sends his ID
2. S -> C: Counter(C_ID) //server responds by respective Counter value
3. C -> S: C_ID, pwd Counter  h Counter1 ( p0 )
4. S: If h( pwd Counter )  password (C _ ID) then {
S authenticates C, and sets ( Counter, password , _ ID )=( Counter  1, pwd Counter , C _ ID )
}
Else C is not authenticated
After N  1 authentications, Counter will become equal to one, and on the next authentication, C
should pass his password in clear. Hence, maximal number of authentications without sending of the
secret client’s password is N  1 . The trick with the schema is that due to one-wayness of the hash
function, it is not feasible to find a value such that its hash will be equal to the stored by S value. As
far as this value changes from one authentication to another, knowledge of the current password
does not allow using it because rate of cracking may be less than that of password update. The
schema has a problem that if N is large (to avoid often initialization) then C should perform on
average large amount of computations (Step 3 of authentication procedure)
Yen-Sheh-Hwang’s One-Time Password Authentication Scheme and
its Cryptanalysis
In that scheme, mutual authentication of a user and server is used. We follow [Yum D.H., Lee P.J.
Cryptanalysis of Yen-Sheh-Hwang’s One-Time Password Authentication Scheme, IEICE
Trans. Communic., v. E88-B, No. 4, April 2005, 1647-1648].
Considered scheme was suggested in [Yeh T.C., Shen H.Y., Hwang J.J., A Secure One-Time
Password Authentication Scheme Using Smart Cards, IEICE Trans. Commun., v. E85-B, No.
11, Nov. 2002, 2515-2518].
First, we describe the scheme, and then consider its cryptanalysis.
The Scheme
1. Registration stage
1.1. User <- Server: SEED // Performed in a safe mode. Server selects secret SEED value and
//conveys it to User (e.g., saves on User’s smart card when issuing it)
1.2. User <- Server: N, SEED  D0, H(D0) //N is number of logins before resetting, Di - nonce,
//H – one-way hash function, User discloses D0 and
//checks its validity by comparing against provided digest
//value
1.3. User -> Server: p0  D0 // p 0  H N ( K  SEED) , K is a secret User’s
// password phrase. Server discloses and keeps p0 as a current
// password
2. Login stage
2.1. User <- Server: ( S t ,1 , S t , 2 , S t ,3 )=( N  t , SEED  Dt , H ( Dt )  pt 1 ) // for t-th login, Server
//generates a random number Dt, computes SEED  Dt,, and H ( Dt )  pt 1 ,
15
The Scheme (Cont 1)
// where pt 1 is stored by Server value of the current password. On first login,
// t  1 , and it should not exceed N
2.2. User -> Server: U t  pt  Dt // User discloses Dt (knowing SEED), and discloses its digest
// H ( Dt ) by use of the current password pt 1 , which he calculates by
// knowing N  t : pt 1  H N t 1 ( K  SEED) . If Dt is valid, he trusts
// Server as a party knowing current password (Server is authenticated
// to User), and responds him a new
// generated password pt  H N t ( K  SEED) closed with Server’s
// current nonce Dt .
3. Authentication stage //Server authenticates User
3.1. Server discloses p t and checks that pt 1  H ( pt ) . If yes, he authenticates User, and keeps
now p t as a current password, t  t  1
The Cryptanalysis
The cryptanalysis consists of three steps: eavesdropping, impersonation of Server, impersonation of
User. In the eavesdropping step, the attacker records messages between Server and User in the t-th
and t+1-th login stages. By using the recorded messages, the attacker impersonates Server. After
receiving a response from User, the attacker can successfully impersonate User in the t+2-th login
stage.
Step 1. Eavesdropping
The attacker records communication tokens in the t-th and t+1-th login stages.
User <-Server: ( S t ,1 , S t , 2 , S t ,3 )=( N  t , SEED  Dt , H ( Dt )  pt 1 )
User -> Server: U t  pt  Dt
User <-Server: ( S t 1,1 , S t 1, 2 , S t 1,3 )=( N  t  1, SEED  Dt 1 , H ( Dt 1 )  pt )
User -> Server: U t 1  pt 1  Dt 1
Step 2. Impersonation of Server
By using the tokens recorded in Step 1, the attacker computes the following fake tokens for the t+2th login stage.
S t 2,1  N  t  2
S t 2, 2  S t 1, 2  SEED  Dt 1
S t 2,3  S t 1,3  (( S t , 2  U t )  ( S t 1, 2  U t 1 )) 
S t 1,3  ((( SEED  Dt )  ( pt  Dt ))  (( SEED  Dt 1 )  ( pt 1  Dt 1 ))) 
S t 1,3  (( SEED  pt )  ( SEED  pt 1 ))  S t 1,3  ( pt  pt 1 ) 
( H ( Dt 1 )  pt )  ( pt  pt 1 )  H ( Dt 1 )  pt 1
16
The Cryptanalysis (Cont 1)
With these tokens the attacker plays the server’s role for the t+2-th login stage. The tokens are valid
for the t+2-th stage except that Dt 1 is the previously used random number in the t+1-th stage. Since
the user does not store the previous random numbers, he is unable to find out that the tokens are
forged and thinks the attacker is a valid server.
User <- Attacker: ( S t 2,1 , S t 2, 2 , S t 2,3 )=( N  t  2, SEED  Dt 1 , H ( Dt 1 )  pt 1 )
User -> Attacker: U t  2  Dt 1  pt  2
Step 3. Impersonation of User
At this point, the attacker tries to login to the server in the t+2-th stage. After receiving the server’s
challenge, the attacker computes response as follows:
Attacker <- Server: ( S t  2,1 , S t  2, 2 , S t  2,3 )=( N  t  2, SEED  Dt  2 , H ( Dt  2 )  pt 1 )
Attacker -> Server: U t 2  pt  2  Dt  2 , where
U t 2  ( S t 1, 2  U t  2 )  S t  2, 2  (( SEED  Dt 1 )  ( pt  2  Dt 1 ))  S t  2, 2 
(( SEED  Dt 1 )  ( pt  2  Dt 1 ))  ( SEED  Dt  2 )  pt  2  Dt  2
Since the attacker’s response U t 2 is exactly the same as the expected response to the server’s
challenge, the attacker is accepted as a valid user. Hence, the attacker succeeds in this so called
preplay attack (An adversary makes a preplay attack when she performs an action before the valid
application does so.)
To counter this scenario of attack, the user could store all the previous random numbers received
from the server.
MD5 Message Digest Algorithm
MD5 (http://www.faqs.org/rfcs/rfc1321.html ) was developed by Ron Rivest at MIT in 1991. Until
1996, when a flaw was found in it, MD5 was the most widely used secure hash algorithm. In
description, we follow Stallings, Cryptography and Network Security textbook.
MD5 Logic
The algorithm takes as input a message of arbitrary length and produces as output a 128-bit message
digest. The input is processed in 512-bit blocks.
Figure 12.1 depicts the overall processing of a message to produce a digest. The processing consists
of the following steps:
1. Append padding bits: The message is padded so that its length in bits is congruent to 448
modulo 512 ( length  448 mod 512 . That is, the length of the padded message is 64 bits less
than an integer multiple of 512 bits. Padding is always added, even if the message is already
of the desired length. For example, if the message is 448 bits long, it is padded with 512 bits
to a length of 960 bits. Thus, the number of padding bits is in the range of 1 to 512. The
padding consists of a single 1-bit followed by the necessary number of 0-bits.
2. Append length: A 64-bit representation of the length in bits of the original message (before
the padding) is appended to the result of Step 1 (least significant byte first). If the original
17
MD5 Logic (Cont 1)
length is greater than 2 64 , then only the lower-order 64 bits of the length are used. Thus, the
field contains the length of the original message, modulo 2 64 .
The outcome of the first two steps yields a message that is an integer multiple of 512 bits in
length. In Figure 12.1,
the expanded message is represented as the sequence of 512-bit blocks Y0 , Y1 ,.., YL 1 , so that the
total length of the expanded message is L  512 bits. Equivalently, the result is a multiple of 16
32-bit words. Let M[0..N-1] denote the words of the resulting message with N an integer
multiple of 16. Thus, N  L 16 .
3. Initialize MD buffer: A 128-bit buffer is used to hold intermediate and final results of the
hash function. The buffer can be represented as four 32-bit registers (A,B,C,D). These
registers are initialized to the following 32-bit integers (hexadecimal values):
A=67452301
B=EFCDAB89
C=98BADCFE
D=10325476
18
MD5 Logic (Cont 2)
These values are stored in little-endian format, which is the least-significant byte of a word in
the low-address byte position. As 32-bit strings, the initialization values (in hexadecimal format)
appear as follows:
Word A: 01 23 45 67
Word B: 89 AB CD EF
Word C: FE DC BA 98
Word D: 76 54 32 10
4. Process message in 512-bit (16-word) blocks: The heart of the algorithm is a compression
function that consists of four “rounds” of processing; this module is labeled H MD5 in Figure
12.1, and its logic is illustrated in Figure 12.2. The four rounds have a similar structure, but
each uses a different primitive logical function, referred to as F, G, H, and I in the
specification.
Each round takes as input the current 512-bit block being processed ( Yq ) and the 128-bit buffer
value ABCD and updates the contents of the buffer. Each round also makes use of one-fourth of
a 64-element table T[1..64], constructed from the sine function. The i-th element of T, denoted
19
MD5 Logic (Cont 3)
T[i], has the value equal to the integer part of 2 32  abs(sin( i)) , where i is in radians. Because
abs (sin( i ))  [0,1] , each element of T is an integer that can be represented in 32 bits. The table
provides a “randomized “ set of 32-bit patterns, which should eliminate any regularities in the
input data. Table 12.1b lists values of T.
The output of the fourth round is added to the input to the first round ( CV q ) to produce CVq 1 .
The addition is done independently for each of the four words in the buffer with each of the
corresponding words in CV q , using addition modulo 2 32 .
5. Output: After all L 512-bit blocks have been processed, the output from the L-th stage is the
128-bit message digest.
We can summarize the behavior of MD5 as follows:
CV0  IV
CVq 1  SUM 32 (CVq , RFI (Yq , RFH (Yq , RFG (Yq , RFF (Yq , CVq )))))
MD  CVL 1
Where
IV - initial value of the ABCD buffer, defined in Step 3
Yq - the q-th 512-bit block of the message
L – the number of blocks in the message (including padding and length fields)
CV q - chaining variable processed with the q-th block of the message
RFx - round function using primitive logic function x
MD - final message digest value
SUM 32 - addition modulo 2 32 performed separately on each word of the pair of inputs
20
MD5 Logic (Cont 4)
21
MD5 Compression Function
Let’s look in more detail at the logic of the four rounds of the processing of one 512-bit block.
Each round consists of a sequence of 16 steps operating on the buffer ABCD. Each step is of the
form
a  b  (( a  g (b, c, d )  X [k ]  T [i ])  s)
Where
a,b,c,d – the four words of the buffer, in a specified order that varies across steps
g – one of the primitive functions F,G,H,I
<<<s – circular left shift (rotation) of the 32-bit argument by s bits
X[k] – M[q  16+k] – k-th 32-bit word in the q-th 512-bit of the message
T[i] – the i-th 32-bit word in matrix T
+ - addition modulo 2 32
Figure 12.3 illustrates the step operation
The order in which the four words (a,b,c,d) are used produces a word-level circular right shift
for each step.
One of the four primitive logical functions is used for each of the four rounds of the algorithm.
Each primitive function takes three 32-bit words as input and produces a 32-bit output. Each
22
MD5 Compression Function (Cont 1)
function performs a set of logical operations; that is, the n-th bit of the output is a function of the
three inputs. The functions can be summarized as follows:
Round
Primitive function g g(b,c,d)
1
F(b,c,d)
(b  c)  (b  d )
2
G(b,c,d)
(b  d )  (c  d )
bcd
c  (b  d )
Figure 12.4 adapted from RFC 1321, defines the processing algorithm of step 4. The array of 32-bit
words X[0..15] holds the value of the current 512-bit input block being processed. Within a round,
each of the 16 words of X[i] is used exactly once, during one step; the order in which these words
are used varies from round to round. In the first round, they are used in the original order. The
following permutations are defined for rounds 2 through 4:
 2 (i )  (1  5i ) mod 16
 3 (i )  (5  3i ) mod 16
3
4
H(b,c,d)
I(b,c,d)
 4 (i )  7i mod 16
0
1
Consider permutation  2 :
1
2
3
4
5
6
11 0
5
10
6
15
7
4
8
9
9
14
10
3
11
8
12
13
13
2
14
7
15
12
Each of the 64 32-bit word elements of T is used exactly once, during one step of one round. Also,
note that for each step, only one of the 4 bytes of the ABCD buffer is updated. Hence, each byte of
the buffer is updated four times during the round and then a final time at the end to produce the final
output of this block. Finally, note that four different circular left shift amounts are used each round
and are different from round to round. The point of all this complexity is to make it very difficult to
generate collisions (two 512-bit blocks that produce the same output).
23
MD5 Compression Function (Cont 2)
We see that in Figure 12.4, order of k values in Round 2 follows specified above permutation  2 .
24