authentication: keys, mac, hashes, message digests, digital signatures

Authentication keys MAC hashes message digests

digital signatures

Topics

bull In a confidential communication the authenticity needs to be carefully established for

bull 1048713The two partnersndash 1048713Before sending any confidential information one needs to be

sure to whom it sends that information authentication protocols

bull 1048713The messages received by each partnerndash 1048713One needs to be sure that the message received has not been

modified ndashit coincides with the sent message message authentication

ndash 1048713If 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

I Authentication protocolsbull Such protocols enable communicating parties to satisfy themselves mutually

about each otherrsquos identity and possibly to exchange session keysbull 1048713Two central problems here confidentiality and timeliness

ndash 1048713Essential identification information and the session keys must be communicated in encrypted form

ndash 1048713Because of the threat of replay timeliness is essential herebull 1048713Replays could allow the attacker to get a session key or to impersonate another partybull 1048713At minimum the attacker could disrupt operations by presenting parties with

messages that appear genuine but are not ndashaims at a denial of service attack

bull 1048713Two approaches are generally used to defend replay attacksndash 1048713Timestamps A accepts a message as fresh only if it contains a timestamp that

in Arsquos judgment is close enough to Arsquos knowledge of current time ndashclocks need to be synchronized

ndash 1048713Challengeresponse 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

Authentication protocols and setting up secret keys

A Direct authentication1Based on a shared secret master

key2Based on a public-key system3Diffie-Hellman

B Mediated authentication1Based on key distribution centers2Kerberos

A1 Authentication based on a shared secret key

bull Assume here that A and B already share a secret key ndashthis 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 keyndash 1048713Master keys will only be used to establish session keysndash 1048713Concentrate here on how to establish session keys

bull 1048713Protocolndash 1048713A issues a requests to B for a session key and includes a nonce N1ndash 1048713B responds with a message encrypted using the shared master key ndash

include there the session key he selects Arsquos id a value f(N1) and another nonce N2

bull 1048713At this point A is sure of Brsquos identity only he knows the master key B is not sure of anything yet

bull 1048713Using the new session key A return f(N2) to Bbull 1048713B is sure of Arsquos identity only A can read the message he sent including

the session key

A2 A general scheme of public-key authentication (and distribution of secret keys)

bull 1048713Assume here that A and B know each otherrsquos public key

bull 1048713N1 and N2 in the scheme are random numbers ndashthey ensure the authenticity of A and B (because only they can decrypt the messages and read N1 and N2)

bull 1048713After Step 2 A is sure of Brsquos identity right response to its challenge

bull 1048713After Step 3 B is sure of Arsquos identity right response to its challenge

A3 A concrete scheme Diffie-Hellman key exchange

bull This is the first ever published public-key algorithm ndashused in a number of commercial products

bull Elegant idea establish a secret key based on each otherrsquos public keysbull Protocol

ndash Alice and Bob need to agree on two large numbers ng where n is prime (n-1)2 is also prime and some extra conditions are satisfied by g (to defeat math attacks) ndashthese numbers may be public so Alice could generate this on her own1048713

ndash Alice picks a large (say 512-bit) number x and B picks another one say y1048713ndash Alice initiates the key exchange protocol by sending Bob a message containing

(ngg^xmod n)1048713ndash Bob sends Alice a message containing g^ymod n1048713ndash Alice raises the number Bob sent her to the x-th power mod n to get the secret

key (g^ymod n)^ x mod n=g^xy mod n1048713ndash Bob raises the number Alice sent to the y-thpower modulo n to get the secret

key (g^x mod n)^y mod n= g^xy mod n

B1 Authentication using key distribution centers (KDC)

Authentication using key distribution centers (KDC)

bull 1048713Setting up a shared key was fairly involved with the previous approaches and perhaps not quite worth doing

bull 1048713Each user has to maintain a secret key (perhaps on some plastic card) for each of his friends ndashthis may be a problem for popular people

bull 1048713Different approach have a trusted key distribution center (KDC)

ndash 1048713Each user maintains one single secret key ndashthe one to communicate with KDC

ndash 1048713Authentication and all communications go through KDC

ndash 1048713Alice picks Ks and tells KDC that she wants to talk to Bob using KsndashA uses secret key KA used only to communicate with KDC

ndash 1048713KDC decrypts the message and sends Ks to Bob together with Alicersquos id ndashKDC uses key KB used only to communicate with B

ndash 1048713Authentication here is for free ndashkey KA is only known to A and KDC

Replay attack to the KDC-based protocol

bull Say Eve manages to get a job with Alice and after doing the job she asks Alice to pay her by bank transfer

bull 1048713Alice establishes a secret key with the banker Bob and then sends Bob a message requesting money to be transferred to Eversquos account

bull Eve however is back to her old business snooping on the networkndashshe copies message 2 in the protocol and the request for money that follows1048713

bull Later Eve replays both messages to Bob ndashBob will think that Alice has hired again Eve and pays Eve the money1048713

bull Eve is able to do many iterations of the procedure ndashreplay attackbull Solution 1 include a timestamp with the message ndashany old

message will be discarded1048713bull Problem clocks are not always exactly synchronized so there will be a

period when the message is still valid1048713

Authentication using Kerberosbull Kerberos is an authentication protocol used in many systems including

Windows 2000 using the KDC-based approachndash 1048713Kerberos was the name of a multi head dog in Greek mythology that used to

guard the entrance to Hadesbull 1048713Designed at MIT to allow workstation users to access network resources

securelyndash 1048713As such it relies on the assumption that all clocks are fairly well synchronized

bull 1048713Kerberos v4 is the most widely used version ndashthe one we discuss herebull 1048713Includes three servers that communicate with Alice (at the workstation)

ndash 1048713Authentication server (AS) ndashverifies the user during loginbull 1048713It shares a secret password with each user (plays the role of the KDC)

ndash 1048713Ticket-granting server (TGS) ndashissues ldquoproof of identity ticketsrdquobull 1048713Tickets will be used by the user to perform various jobs

ndash 1048713Bob the server ndashactually does the work Alice needs to do based on the identity ticket

bull 1048713Based on the identity ticket will grant Alice the right she is entitled to

Authentication using Kerberos

1 A sits down at an arbitrary public workstation and types her namendash 1048713Workstation sends her name to the AS in plaintext

2 AS sends back a session key KS and a ticket KTGS(AKS) for TGS ndashboth encrypted with Arsquos secret keyndash 1048713At this point the workstation asks for Arsquos password

bull 1048713Password is used to generate the secret key and decrypt the message obtaining the ticket for TGS



bull A tells the workstation she needs to contact the file server Bob3 Workstation sends a message to TGS asking for a ticket to use Bob

ndash 1048713Key element here is the ticket for TGS received from AS ndashthis 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 ndash 1048713TGS sends a message encrypted with KS so that A can read and get KABndash 1048713TGS also includes a message intended only for Bob sending Arsquos identity and

the key KABbull 1048713If Eve replays message 3 she will be foiled by the timestamp t

ndash 1048713Even if she replays the message quickly she will only get a copy of message 4 that she cannot read

5 Alice can now communicate with Bob using KAB6 Bob confirms he has received the request and is ready to do the work

II Digital signatures

bull Having a sort of digital signature replacing hand written signatures is essential in the cyber-world

bull 1048713This is crucial between two parties who do not trust each other and need protection from each otherrsquos later false claims

bull Requirements for a digital signaturendash 1048713Must authenticate the content of the message at the time of the signaturendash 1048713Must authenticate the author date and time of the signature ndash 1048713Receiver can verify the claimed identity of the senderndash 1048713Sender cannot later repudiate the content of the messagendash 1048713Receiver cannot possibly have concocted the message himselfndash 1048713Can be verified by third-parties to resolve disputes

bull 1048713Examplesndash 1048713The bank needs to verify the identity of the client placing a transfer orderndash 1048713The client cannot deny later having sent that orderndash 1048713It is impossible for the bank to create transfer orders and claim they actually

came from the client

Digital signatures

bull Computational requirementsndash 1048713Must be a bit pattern depending on the message being signedndash 1048713Signature must use some information unique to the sender to

prevent forgery and denialndash 1048713Computationally easy to produce a signaturendash 1048713Computationally easy to recognize and verify the signaturendash 1048713Computationally infeasible to forge a digital signature

bull 10487131048713Practical to retain a copy of the digital signature in storage

Two general schemes for digital signatures

bull Arbitrated digital signaturesbull 1048713Every signed message from A to B goes to an

arbiter BB (Big Brother) that everybody trustsbull 1048713BB checks the signature and the timestamp

origin content etcbull 1048713BB dates the message and sends it to B with an

indication that it has been verified and it is legitimate

Arbitrated digital signaturesbull Eg every user shares a secret key

with the arbiterndash 1048713A sends to BB in an encrypted form the plaintext

P together with Brsquos id a timestamp and a random number RA

ndash 1048713BB decrypts the message and thus makes sure it comes from A it also checks the timestamp to protect against replays

ndash 1048713BB then sends B the message P Arsquos id the timestamp and the random number RA he also sends a message encrypted with his own private key (that nobody knows) containing Arsquos id timestamp t and the plaintext P (or a hash)

ndash 1048713B cannot check the signature but trusts it because it comes from BB ndashhe knows that because the entire communication was encrypted with KB

ndash 1048713B will not accept old messages or messages containing the same RA to protect against replay

ndash 1048713In case of dispute B will show the signature he got from BB (only BB may have produced it) and BB will decrypt it

Direct digital signatures

bull This involves only the communicating parties and it is based on public keys

bull 1048713The sender knows the public key of the receiver

bull 1048713Digital signature encrypt the entire message (or just a hash code of the message) with the senderrsquos private key

bull 1048713If confidentiality is required apply the receiverrsquos public key or encrypt using a shared secret key

DS

bull Weaknessesndash 1048713The 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

bull 1048713Attack to deny the signature right after signing simply claim that the private key has been lostndashsimilar to claims of credit card misuse

bull 1048713If A changes her public-private keys (she can do that often) the judge will apply the wrong public key to check the signature ndash 1048713Attack to deny the signature change your public-private key

pairndashthis should not work if a PKI is used because they may keep trace of old public keys

bull 1048713A should protect her private key even after she changes the key

Authentication keys MAC hashes message digests digital signatures

Topics

I Authentication protocols



Slide 6


Slide 8


Slide 10




Slide 14


Slide 16


Digital signatures


Arbitrated digital signatures


DS

Topics

bull In a confidential communication the authenticity needs to be carefully established for

bull 1048713The two partnersndash 1048713Before sending any confidential information one needs to be

sure to whom it sends that information authentication protocols

bull 1048713The messages received by each partnerndash 1048713One needs to be sure that the message received has not been

modified ndashit coincides with the sent message message authentication

ndash 1048713If 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



















the session key



























































Digital signatures






















DS








Topics




Slide 6


Slide 8


Slide 10




Slide 14


Slide 16


Digital signatures




DS



















the session key



























































Digital signatures






















DS








Topics




Slide 6


Slide 8


Slide 10




Slide 14


Slide 16


Digital signatures




DS



























































Digital signatures






















DS








Topics




Slide 6


Slide 8


Slide 10




Slide 14


Slide 16


Digital signatures




DS



















DS








Topics




Slide 6


Slide 8


Slide 10




Slide 14


Slide 16


Digital signatures




DS

authentication: keys, mac, hashes, message digests, digital signatures

Documents

key authentication

master key b

new session key

session key a2

sent message

fresh message

shared master key

message digests