Cryptography and Network Security
Spring 2006
http://www.abo.fi/~ipetre/crypto/
Lecture 9: Authentication: keys, MAC, hashes, message digests,
digital signatures, passwords
Ion Petre
Academy of Finland and
Department of IT, Åbo Akademi University
April 13, 2006 1
Overview of the course
I. CRYPTOGRAPHY III. NETWORK SECURITY
Secret-key cryptography Email security
Classical encryption techniques IP security
DES, AES, RC5, RC4 Web security (SSL, secure
Public-key cryptography electronic transactions)
RSA Firewalls
Key management Wireless security
II. AUTHENTICATION IV. OTHER ISSUES
MAC Viruses
Hashes and message digests Digital cash
Digital signatures Secret sharing schemes
Kerberos Zero-knowledge techniques
April 13, 2006 2
Topics today
In a confidential communication the authenticity needs to be
carefully established for:
The two partners
Before sending any confidential information one needs to be sure to whom it
sends that information: authentication protocols
The messages received by each partner
One needs to be sure that the message received has not been modified – it
coincides with the sent message: message authentication
If the two partners do not quite trust each other, they need to make sure that
the sender cannot later deny having sent the message and the receiver
cannot have devised the message himself: digital signatures
April 13, 2006 3
I. Authentication protocols
Such protocols enable communicating parties to satisfy themselves
mutually about each other’s identity and possibly, to exchange session keys
Two central problems here: confidentiality and timeliness
Essential identification information and the session keys must be communicated
in encrypted form
Because of the threat of replay, timeliness is essential here
Replays could allow the attacker to get a session key or to impersonate another party
At minimum, the attacker could disrupt operations by presenting parties with messages
that appear genuine but are not – aims at a denial of service attack
Two approaches are generally used to defend replay attacks
Timestamps: A accepts a message as fresh only if it contains a timestamp that,
in A’s judgment, is close enough to A’s knowledge of current time – clocks need
to be synchronized
Challenge/response: A, expecting a fresh message from B, first sends B a
random number (challenge) and requires that the subsequent message
(response) received from B contains that random number or some agree-upon
transformation on it (this is also called hand-shaking sometimes)
April 13, 2006 4
Authentication protocols and setting up secret keys
A. Direct authentication
1. Based on a shared secret master key
2. Based on a public-key system
3. Diffie-Hellman
B. Mediated authentication
1. Based on key distribution centers
2. Otway-Rees
3. Kerberos
April 13, 2006 5
A1. Authentication based on a shared secret key
Assume here that A and B already share a secret key – this is called sometimes the
master key MK because the two will only use this rarely, whenever they need to
authenticate each other and establish a session key
Master keys will only be used to establish session keys
Concentrate here on how to establish session keys
Protocol
A issues a requests to B for a session key and includes a nonce N1
B responds with a message encrypted using the shared master key – include there the session
key he selects, A’s id, a value f(N1) (say the successor of N1) and another nonce N2
At this point, A is sure of B’s identity: only he knows the master key; B is not sure of anything yet
Message is fresh: B sends a transformation on N1
Using the new session key, A return f(N2) to B
B is sure of A’s identity: only A can read the message he sent, including the session key
Message is fresh: A sends a transformation on N2
April 13, 2006 6
A2. A general scheme of public-key authentication
(and distribution of secret keys)
Assume here that A and B know each other’s public key
N1 and N2 in the scheme are random numbers – they ensure the authenticity of A
and B (because only they can decrypt the messages and read N1 and N2)
After Step 2, A is sure of B’s identity: right response to its challenge
After Step 3, B is sure of A’s identity: right response to its challenge
April 13, 2006 7
A3. A concrete scheme: Diffie-Hellman key exchange
This is the first ever published public-key algorithm – used in a number of commercial
products
Elegant idea: establish a secret key based on each other’s public keys
Protocol
Alice and Bob need to agree on two large numbers n,g, where n is prime, (n-1)/2 is also prime
and some extra conditions are satisfied by g (to defeat math attacks) – these numbers may be
public so Alice could generate this on her own
Alice picks a large (say, 512-bit) number x and B picks another one, say y
Alice initiates the key exchange protocol by sending Bob a message containing (n,g,gx mod n)
Bob sends Alice a message containing gy mod n
Alice raises the number Bob sent her to the x-th power mod n to get the secret key:
(gy mod n)x mod n=gxy mod n
Bob raises the number Alice sent to the y-th power modulo n to get the secret key:
(gx mod n)y mod n=gxy mod n
April 13, 2006 8
Diffie-Hellman key exchange: an attack
Security of the protocol: Eve has seen both messages A and B have
changed – given g,n, and gx mod n, she must find x
In math terms, she needs to compute a discrete logarithm
Computing discrete logarithms is thought to be infeasible
Is this enough to secure the protocol?
Man-in-the-middle attack
Eve intercepts all communications between A and B – she will impersonate A in
communications with B and will impersonate B in communications with A; E may
forward a modified message to A and B
A and B will never know that they are both actually talking to E
Attack can be defeated using signatures – both A and B will sign their messages
with their private keys
April 13, 2006 9
Second approach to authentication
B. Mediated authentication
1. Based on key distribution centers
2. Otway-Rees
3. Kerberos
April 13, 2006 10
B1. Authentication using key distribution centers (KDC)
Setting up a shared key was fairly involved with the previous approaches and
perhaps not quite worth doing (“sour grape attack”)
Each user has to maintain a secret key (perhaps on some plastic card) for each of his
friends – this may be a problem for popular people
Different approach: have a trusted key distribution center (KDC)
Each user maintains one single secret key – the one to communicate with KDC
Authentication and all communications go through KDC
Alice picks Ks and tells KDC that she wants to talk to Bob using Ks – A uses secret key
KA used only to communicate with KDC
KDC decrypts the message and sends Ks to Bob together with Alice’s id – KDC uses
key KB used only to communicate with B
Authentication here is for free – key KA is only known to A and KDC
April 13, 2006 11
Replay attack to the KDC-based protocol
Say Eve manages to get a job with Alice and after doing the job, she asks Alice to pay her
by bank transfer
Alice establishes a secret key with the banker Bob and then sends Bob a message
requesting money to be transferred to Eve’s account
Eve however is back to her old business, snooping on the network – she copies message 2
in the protocol and the request for money that follows
Later Eve replays both messages to Bob – Bob will think that Alice has hired again Eve and pays
Eve the money
Eve is able to do many iterations of the procedure – replay attack
Solution 1: include a timestamp with the message – any old message will be discarded
Problem: clocks are not always exactly synchronized so there will be a period when the message is
still valid
Solution 2: include a nonce (random number) with the message
Problem: the nonces have to be remembered forever and any old one is discarded
April 13, 2006 12
B2. A stronger version of the KDC-based protocol
(Otway-Rees protocol)
In the figure bellow, R, RA are random numbers generated by A, RB is a random
number generated by B, KA and KB are as before the keys of A and B to
communicate with KDC
R is for KDC to check the integrity – KDC has to see R in both messages encrypted
with KA and KB; if so, KDC generates the secret key and sends it to both A and B
RA and RB are for A and B to make sure the secret key comes from KDC
Resistant to replay attack: in such a case A and B will get keys they did not ask for or
messages that do not match the random numbers they sent
April 13, 2006 13
B3. Authentication using Kerberos
Kerberos is an authentication protocol used in many systems, including
Windows 2000, using the KDC-based approach
Kerberos was the name of a multihead dog in Greek mythology that used to
guard the entrance to Hades
Designed at MIT to allow workstation users to access network resources
securely
As such, it relies on the assumption that all locks are fairly well synchronized
Kerberos v4 is the most widely used version – the one we discuss here
Includes three servers that communicate with Alice (at the workstation)
Authentication server (AS) – verifies the user during login
It shares a secret password with each user (plays the role of the KDC)
Ticket-granting server (TGS) – issues “proof of identity tickets”
Tickets will be used by the user to perform various jobs
Bob the server – actually does the work Alice needs to do, based on the
identity ticket
Based on the identity ticket will grant Alice the right she is entitled to
April 13, 2006 14
Authentication using Kerberos
1. A sits down at an arbitrary public workstation and types her
name
Workstation sends her name to the AS in plaintext
2. AS sends back a session key KS and a ticket KTGS(A,KS) for
TGS – both encrypted with A’s secret key
At this point the workstation asks for A’s password
Password is used to generate the secret key and decrypt the
message, obtaining the ticket for TGS
Password is overwritten immediately to make sure it stays inside just
for a few milliseconds, it never leaves the workstation; without the
password Eve cannot get the ticket for TGS
April 13, 2006 15
Authentication using Kerberos
A tells the workstation she needs to contact the file server Bob
3. Workstation sends a message to TGS asking for a ticket to use Bob
Key element here is the ticket for TGS received from AS – this proves to TGS that
the sender is really A
4. TGS creates and sends back a session key KAB for A to use with B
TGS sends a message encrypted with KS so that A can read and get KAB
TGS also includes a message intended only for Bob, sending A’s identity and the
key KAB
If Eve replays message 3 she will be foiled by the timestamp t
Even if she replays the message quickly she will only get a copy of message 4 that
she cannot read
April 13, 2006 16
Authentication using Kerberos
5. Alice can now communicate with Bob using KAB
6. Bob confirms he has received the request and is ready to do the work
Multiple realms can be accommodated in Kerberos, each with its own
AS and TGS
To get a ticket for a distant server B, Alice asks her own TGS for a ticket
accepted by the distant TGS
She will go through the same protocol with the distant servers
The users of the two realms must trust each other’s TGS
April 13, 2006 17
II. Digital signatures
Having a sort of digital signature replacing handwritten signatures is
essential in the cyber-world
This is crucial between two parties who do not trust each other and need
protection from each other’s later false claims
Requirements for a digital signature
Must authenticate the content of the message at the time of the signature
Must authenticate the author, date, and time of the signature
Receiver can verify the claimed identity of the sender
Sender cannot later repudiate the content of the message
Receiver cannot possibly have concocted the message himself
Can be verified by third-parties to resolve disputes
Examples:
The bank needs to verify the identity of the client placing a transfer order
The client cannot deny later having sent that order
It is impossible for the bank to create transfer orders and claim they actually
came from the client
April 13, 2006 18
Digital signatures
Computational requirements
Must be a bit pattern depending on the message being signed
Signature must use some information unique to the sender to prevent
forgery and denial
Computationally easy to produce a signature
Computationally easy to recognize and verify the signature
Computationally infeasible to forge a digital signature
either by constructing a new message for an existing digital signature
or by constructing a fraudulent digital signature for a given message
Practical to retain a copy of the digital signature in storage
Two general schemes for digital signatures
Direct
Arbitrated
April 13, 2006 19
Arbitrated digital signatures
Every signed message from A to B goes to an arbiter BB (Big Brother) that
everybody trusts
BB checks the signature and the timestamp, origin, content, etc.
BB dates the message and sends it to B with an indication that it has been
verified and it is legitimate
April 13, 2006 20
Arbitrated digital signatures
E.g., every user shares a secret key with the arbiter
A sends to BB in an encrypted form the plaintext P together with B’s id, a
timestamp and a random number RA
BB decrypts the message and thus makes sure it comes from A; it also checks the
timestamp to protect against replays
BB then sends B the message P, A’s id, the timestamp and the random number
RA; he also sends a message encrypted with his own private key (that nobody
knows) containing A’s id, timestamp t and the plaintext P (or a hash)
B cannot check the signature but trusts it because it comes from BB – he knows
that because the entire communication was encrypted with KB
B will not accept old messages or messages containing the same RA to protect
against replay
In case of dispute, B will show the signature he got from BB (only BB may have
produced it) and BB will decrypt it
April 13, 2006 21
Direct digital signatures
This involves only the communicating parties and it is based on public
keys
The sender knows the public key of the receiver
Digital signature: encrypt the entire message (or just a hash code of
the message) with the sender’s private key
If confidentiality is required: apply the receiver’s public key or encrypt
using a shared secret key
In case of a dispute, the receiver B will produce the plaintext P and the
signature E(KRA, P) – the judge will apply KUA and decrypt P and
check the match: B does not know KRA and cannot have produced the
signature himself
April 13, 2006 22
Direct digital signatures
Weaknesses:
The scheme only works as long as KRA remains secret: if it is disclosed (or
A discloses it herself), then the argument of the judge does not hold:
anybody can produce the signature
Attack: to deny the signature right after signing, simply claim that the private
key has been lost – similar to claims of credit card misuse
If A changes her public-private keys (she can do that often) the judge will
apply the wrong public key to check the signature
Attack: to deny the signature change your public-private key pair – this should
not work if a PKI is used because they may keep trace of old public keys
A should protect her private key even after she changes the key
Attack: Eve could get hold of an old private key and sign a document with an
old timestamp
April 13, 2006 23
Digital signature standard
Any public-key systems may be used – the industry de facto choice
is RSA
The proposed standard (1991) is the Digital Signature Standard
(DSS) based on ElGamal (a public-key system)
ElGamal is based on discrete logarithms
Immediate complains:
Too secret – NSA was involved in developing the protocol for using
ElGamal in DSS
Too slow – 10 to 40 times slower than RSA-based signatures
Too new – ElGamal had not yet been thoroughly analyzed
Too insecure – only 512-bit key (subsequently 1024-bit keys adopted)
April 13, 2006 24
DSS approach
April 13, 2006 25
DSS
The message M is first subjected to a hash function (to compress it)
The hash code and a random number k are provided as input to the
signature function
Signature function depends on the sender’s private key KRa and a
public key KUG known to several users
The result is a signature with 2 components r,s
April 13, 2006 26
Digital Signature Algorithm (not required in the exam)
April 13, 2006 27
III. Message authentication
Goal here: having received a message one would like to make sure that the
message has not been altered on the way
A digital signature includes message authentication
Sometimes one needs to dissociate the authentication from secrecy
This is the case if one tries to obtain a software export license
Also more flexible to separate the cryptographic module from the authentication
module – they could even be implemented at different levels in the system
architecture
Possible attacks on message authentication:
Masquerade – insertion of messages into the network from fraudulent sources,
including fraudulent acknowledgements of receipt or non-receipt
Content modification
Sequence modification – modifications to a sequence of messages, including
insertion, deletion, reordering
Timing modification – delay or replay messages
April 13, 2006 28
Authentication functions
Three types of authentication exist
Message encryption – the ciphertext serves as authenticator
Message authentication code (MAC) – a public function of the message
and a secret key producing a fixed-length value to serve as
authenticator
This does not provide a digital signature because A and B share the same
key
Hash function – a public function mapping an arbitrary length message
into a fixed-length hash value to serve as authenticator
Same comment
April 13, 2006 29
Message encryption as authentication
Main idea here: the message must have come from A because the ciphertext can be
decrypted using her (secret or public) key
Also, none of the bits in the message have been altered because an opponent does not
know how to manipulate the bits of the ciphertext to induce meaningful changes to the
plaintext
Conclusion: encryption (either symmetric or public-key) provides authentication as well
as confidentiality
Some careful considerations are needed here:
How does B recognize a meaningful message from an arbitrary sequence of bits?
He can apply the decryption key to any sequence of bits he receives
This is not necessarily easy task if the message is some sort of binary file
Immediate idea of attack: send arbitrary bit sequences to disrupt the receiver – he will try to
figure out the meaning of that bit sequence
Defense against this type of attack: add to the message a certain structure such as an
error-correcting code and then encrypt the whole file
B will detect illegitimate messages because they will not have the required structure
Careful not to weaken the cryptographic system
April 13, 2006 30
More to authentication than simple encryption?
Often one needs alternative authentication schemes than just
encrypting the message
Sometimes one needs to avoid encryption due to legal requirements
Encryption and authentication may be separated in the system
architecture
If a message is broadcast to several destinations in a network (such as
a military control center), then it is cheaper and more reliable to have
just one node responsible to evaluate the authenticity – message will be
sent in plain with an attached authenticator
If one side has a heavy load, it cannot afford to decrypt all messages –
it will just check the authenticity of some randomly selected messages
If the message is sent encrypted, it is of course protected over the
network. However, once the receiver decrypts the message, it is no
longer secure. Using a different type of authentication protects the
message also on the local computer
April 13, 2006 31
