Cryptography and Network Security - Åbo Akademiusers.abo.fi/ipetre/crypto/lecture9.pdf · February...

February 7, 2012 1

Cryptography and Network Security

Lecture 9: Authentication protocols, digital signatures

Ion Petre Department of IT, Åbo Akademi University

Spring 2012 http://users.abo.fi/ipetre/crypto/

http://users.abo.fi/ipetre/crypto/

http://www.abo.fi/~ipetre/crypto/�



February 7, 2012 2

Overview of the course

I. CRYPTOGRAPHY Secret-key cryptography

Classical encryption techniques DES, AES, RC5, RC4

Public-key cryptography RSA

Key management II. AUTHENTICATION

MAC Hashes and message digests Digital signatures Kerberos

III. NETWORK SECURITY Email security IP security Web security (SSL, secure

electronic transactions) Firewalls Wireless security

IV. OTHER ISSUES Viruses Digital cash Secret sharing schemes Zero-knowledge techniques


February 7, 2012 3

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


February 7, 2012 4

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)


February 7, 2012 5

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


February 7, 2012 6

A1. Direct 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 A knows that the 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 B knows that the message is fresh: A sends a transformation on N2


February 7, 2012 7

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 (through a protocol such as those in Lecture 8)

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


February 7, 2012 8

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


February 7, 2012 9

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


February 7, 2012 10

Second approach to authentication

B. Mediated authentication 1. Based on key distribution centers 2. Otway-Rees 3. Kerberos


February 7, 2012 11

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


February 7, 2012 12

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


February 7, 2012 13

B2. A stronger version of the KDC-based protocol (Otway-Rees protocol)

In the figure below, 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


February 7, 2012 14

B3. Authentication using Kerberos

Kerberos is an authentication protocol used in many systems, including Windows 2000 and later versions, using the KDC-based approach Kerberos was the name of a multi-headed 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 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


February 7, 2012 15

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


February 7, 2012 16


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


February 7, 2012 17


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


February 7, 2012 18

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


February 7, 2012 19

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


February 7, 2012 20

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


February 7, 2012 21

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


February 7, 2012 22

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


February 7, 2012 23

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


February 7, 2012 24

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) Latest update as a standard in 2009 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)


February 7, 2012 25

DSS approach


February 7, 2012 26

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


February 7, 2012 27

Digital Signature Algorithm (not required in the exam)


Cryptography and Network Security - Åbo Akademiusers.abo.fi/ipetre/crypto/lecture9.pdf · February...

Documents

Transcript of Cryptography and Network Security - Åbo Akademiusers.abo.fi/ipetre/crypto/lecture9.pdf · February...