Digital signatures, DSS and authentication protocols

1. Digital signatures, DSS and authentication protocols

2. Digital Signatures • Message authentication protects two parties from a third party, but not against each other! • The receiver B can forge a message and claim that it came from A. • If previous is possible, then A can always deny having sent a message received by B, claiming it as forged by B. • Thus in situation when there is no complete trust between the parties a digital signature is needed. • A digital signature must have the following properties • It must be able to verify the author and the date and the time of the signature • It must be able to verify the contents at the time of the signature. • The signature must be verifiable by a third party to resolve disputes

3. Digital Signatures • Based on the previous properties, we can state the reauirements for a digital signature • The signature must be a function of the whole message being signed • The signature must use some information unique to the sender to prevent both forgery and denial • It must be easy to produce a signature • It must be easy to recognize and verify a signature • It must be computationally infeasible to forge a digital signature • by constructing a new message for existing signature • by constructing a fraudulent signature for a given message • It must be practical to retain a copy of a digital signature. • A secure hash-function used in a way shoown in fig. 8.5c or 8.5d satisfies these requirements. • The approaches for the digital signature function fall into two categories, direct and arbitrated.

4. Digital Signatures - direct • Only the two communicating parties are involved. • It is assumed that the destinaton knows the public key of the source. • A digital signature can be formed either by encryptin the whole message (fig. 8.1c) or a hash code (fig 8.5c) with the senders private key. • Confidentiality is provided by further encrypting the entire message and the signature with either receivers public key (fig 8.1d) or a common secret key (fig 8.5d). • Direct digital signature schemes all have a weakness: The validity of the scheme depends on the secrecy of the senders private key. • if a sender later wants to deny a message, he can claim that the secrecy of the private key was compromized (stolen, lost...) and that somebody else used it to forge the signature. • also the key might actually be stolen from X at time T. The opponent can then send a message signed with X’s signature and with a time stamp earlier than T. • Administrative controls can weaken these threats but not eliminate them. • for instance every signed message can be required to have a time stamp, immediate reporting of compromized keys to central authotity can be required.

5. Digital Signatures - arbitrated • A trusted system, an arbiter, is used to address the problem of direct digital signatures • There are many arbitrated digital signature schemes. The general operation is as follows: • every signed message from sender X to receiver Y goes first to arbiter A • A checks the origin and contents of the message • A adds a timestamp and sends it to Y with an indication that the message has been verified by the arbiter. • In order for this scheme to work, all parties must have a great deal of trust on the arbitration mechanism. • 10.1a conventional encryption is used • A is able to read the messages, and so are eavesdroppers • In case of dispute, Y, claiming to have received M from X send the following message to A: EKay[IDX||M|| EKax[IDX ||H(M)]] • It is assumed that X and A share a secret key Kax and Y and A share Kay.

7. Digital Signatures - arbitrated • 10.1b arbitration is provided as before, but also confidentiality • It is assumed that X and Y share a secret key Kxy.. • A operates only on encrypted message, but can still prevent fraud from either party. • There still remains a threat: A can form an alliance with the sender to deny a message or with a receiver to construct a fraud message. Thus schemes a and b both sides must have a high degree of trust in A. • In 10.1c these problems are solved by a public key scheme • No information is shared among the parties before the communication, preventing alliances to defraud. • No incorrectly dated messages can be sent, even if KRx is compromised ( as long as KRx is not). • The content of the message is secret to A and anyone else.

8. Digital Signature Standard (DSS) • DSS is a NIST FIPS PUB 186 standard. • DSS uses SHA-1 to construct a digital signature technique, the Digital Signature Algorithm (DSA) • Proposed in 1991, revisions in 1993 and 1996. • DSA is besed on discrete logarithms according to ElGamal cryptographic scheme. • DSS is provides only the digital signature function. • DSS can not be used for encryption • In DSS the hash code is provided as input to a signature function, along with a secret random number k. • The global public key components are two large primes p and q and the a chosen value g. The global public key is (p,q,g). • The user has also a private key x and a related public key y. • In addition to these, the message hash code H(M) and a secret randomly generated integer k unique to each message are needed to create a signature.

10. Digital Signature Standard (DSS) • The signature consists of two values, s that is a function of the message, and r that does not depend on the message. • The test of the signature is on the value r, which is a function of the random nubmer k and the global key. Using the message, users public key and the global public key the receiver can recover r. • The reason for this complicated scheme is that all computationally demanding calculations are independent of the message contents, and thus can be calculated once beforehand for a larege set of messages.

12. Authentication protocols The basic techiques for authenticaton discussed with hash-functions and MACs, and the digital signature, are used as such in many apllications. However, more complex protocols are increasinly required in many applications. We examine such authentication protocols, based on either conventional or public key cryptography, on the general areas of mutual authentication and one-way authentication.

13. Authentication protocols – mutual authentication • Mutual authentication protocols enable the communicating parties to satisfy themselves mutually about each other’s identity, and subsequently exchange session keys. ( we examined mutual key exchange earlier, but without the emphasis on authentication). • Two central requirements of authenticated key echange are • Confidentiality • Timeliness • Confidentiality is needed to countermeasure masquerade and to prevent compromise of the session keys. • essential identification information and the session keys must be encrypted • this requires the prior existence of secret or public keys for this purpose • Timeliness is required to countermeasure any form of replay attack, in the form of message replays. The replays could allow the opponent to impersonate another party or to compromise a session key. At minimum replay attacks can disrupt the authentication protocol.

14. Authentication protocols – mutual authentication • Replay attacks can take the following forms • Simple replay: the opponent simply copies a message and resends it later. • Repetition that can be logged: An opponent replays a timestamped message within the valid time-window. • Repetition that can not be detected: The original message is supressed and only the replay message arrives. • Backward replay without modification: a replay back to the message sender, possible if convetional encryption is used. • A straightforward way of coping with replay attacks is to attache a sequence number into the messages used in authentication exchange. A message is accepted only if the sequence number is in proper order. • There is an overhead for each party to keep track of the last sequence number used with each claimant. Because of this, the following two general appraches are used instead: • Timestamps • Challenge/response

15. Authentication protocols – mutual authentication • Timeliness • A party accepts a message as fresh only if the message contains a timestamp that is close enough of the current time, according to A’s judgement. This requires some form of clock syncronization. • Any timestamp based protocol must use a time window sufficiently large to accommodate network delays and clock desyncronization, yet sufficiently small to minimize replay attacks. • Use with connection-oriented applications should be done with precaution. • Challenge/response • Party A, expaecting a fresh message from B, first sends a nonce (challence) to B and requires that the subsequent message(response) from B contains the correct nonce. • Not suitable for connetionless applications. The required handshake before the connectionless transmission negates the chief characteristic of connectionless transmission and is thus unbearable overhead. These applications should rely on a secure time server and timestamp approach.

16. Authentication protocols – mutual authenticationconventional encryption approaches • A similar two level hierarchy using a trusted KDC (Key Distribution Centre) as discussed earlier forms the basis for all protocols. • Each party shares a master key with the KDC. • KDC is responsible for generating the session keys used for a short period of time in communication between the parties. • KDC distributes the session keys encrypted with master keys. • An example of a such scheme is Kerberos. • We start with the key distribution scheme presented in fig. 5.9., find the possible threats and improve gradually the scheme. • This scheme can be stated as follows • A  KDC: IDA|| IDB ||N1 • KDC A: EKa[Ks || IDB ||N1|| EKb[Ks || IDA]] • AB: EKb[Ks || IDA] • BA: EKs[N2] • AB: EKs[f(N2)]

18. Authentication protocols – mutual authenticationconventional encryption approaches • Steps 4. and 5. counter a simple replay attack where the opponent replays the message 3 to disrupt operations at B. • There is another vuolnerability: suppose that the opponent X has been able to compromise an old session key. Now X is able to impersonate A and fool B to use the old key by simply replaying old step 3. If B does not ”check against” used keys there is no way B can detect the attack and X will be authenticated an A in steps 4. and 5. • This weakness is contered by adding a timestamp to messages in steps 2. and 3. to assure A and B that the session key has just been created. • A  KDC: IDA|| IDB • KDC A: EKa[Ks || IDB || T||N1 || EKb[Ks || IDA || T]] • AB: EKb[Ks || IDA || T] • BA: EKs[N2] • AB: EKs[f(N2)] • The nonces in 1. and 2. are not needed any more. • This fixes the problem, but there is still a concenr about suppress replay attack applicable if the clocks get unsyncronized. In this attack the senders clock is ahead of the receivers, and an opponent replays a message when its timestamp becomes valid.

19. Authentication protocols – mutual authenticationconventional encryption approaches • Now the protocol is further revised to contermeasure these problems. The idea is that the receiver will only check the validity of self-generated timestamps, thus eliminating the clock syncronization problem. • The new protocol is as follows: • A  B: IDA|| NA • B KDC: IDB || Nb || EKb[IDA|| Na || Tb] • KDCA: EKa[Ks || IDB|| Na || Tb] || EKb[IDA|| Ks || Tb] || Nb • AB: EKb[IDA|| Ks || Tb] || EKs[ Nb ] • The nonce Na will be returned to A in an encrypted message containing the session key thus assuring A of its currency. • B alerts KDC for a session key. The message includes a nonce Nb that will be returned to B in an ancrypted message containing the session key thus assuring B of its currency. The message also includes a block encrypted with secret key shared by B and KDC. based on this block KDC can issue credentials to A: the block specifiea the inteded recepient and expiration time of the credentials. • The KDC returns Na (which it learned from B) to A in an encrypted block containing also the session key, its expiration time, verification of B’s identity. Also included is a ”ticket” for B to be used in subsequent authenticaitons.

20. Authentication protocols – mutual authenticationconventional encryption approaches • A transmits the ticket to B together with B’s nonce Nb encrypted with session key. The ticket provides B with the session key, and the fact that the nonce was encrypted with the session key autenthicates that the message came from A and is not a replay. • This protocol leaves A in the posession of a key that can be used for subsequent authentication to B avoiding the need to contact KDC frequently. Suppose that A and B used the protocol and then ended the session. Now within the time limit of the ticket, A desires a new session. The following protocol is used: • A  B: EKb[IDA|| Ks || Tb] || Na’ • B A: Nb’ || EKs[Na’] • AB: EKs[Nb’] • B checks the currency of the session key from a self-generated expiration timestamp, so no syncronization is needed. • The nonces constitute a normal handshaking against replays.

21. Authentication protocols – mutual authenticationpublic-key encryption approaches • In public-key protocols an authetication server (AS) is used to provide public-key cerificates (discussed previously in the context of key distribution). The other possibility, that both parties are aware of each others public keys is not always practical (Fig. 6.15.) • A compact protocol using timestamps agaisn replays is • A  AS: IDA|| IDB • AS A: EKRas[IDA|| KUa|| T] || EKRas[IDB|| KUb|| T] • AB: EKRas[IDA|| KUa|| T] || EKRas[IDB|| KUb|| T] || EKUb[EKRa[KS || T]] • A generates the session key, so it is not exposed to AS. The role of AS is merely to provide the public-key cerificates. The timestamps protect against replays of older compromized keys. • The problem of this protocol is that it requires clock-syncronization.

22. Authentication protocols – mutual authenticationpublic-key encryption approaches • Another protocol using nonces instead of timestamps is as follows (note that now the session key is generated by the authority, thus the use of KDC): • A  KDC: IDA|| IDB • KDC A: EKRauth[IDB|| KUb] • AB: EKUb[Na || IDA] • B KDC: IDA|| IDB|| EKUauth[Na] • KDC B: EKRauth[IDA|| KUa] || EKUb[EKRauth[IDB|| Ks || Na]] • BA: EKUa[EKRauth[IDB|| Ks || Na] || Nb] • AB: EKs[ Nb] • This appears as a secure protocol taking into account various attacks. Still the developers of teh protocol were later able to spot a flawn: the nonce Na was considered to be unique to verivy the timeliness of the message in step 6. However, it is not necessarily unique among all nonces generated by all parties. Thus the connection request of A in step 5. must be identified by a pair {Na || IDA}.

23. Authentication protocols – mutual authenticationpublic-key encryption approaches • To fix the problem vwe have the final protocol: • A  KDC: IDA|| IDB • KDC A: EKRauth[IDB|| KUb] • AB: EKUb[Na || IDA] • B KDC: IDA|| IDB|| EKUauth[Na] • KDC B: EKRauth[IDA|| KUa] || EKUb[EKRauth[IDA|| IDB|| Ks || Na]] • BA: EKUa[EKRauth[IDA|| IDB|| Ks || Na] || Nb] • AB: EKs[ Nb] • The fact that published protocols have often been revised by the authors highlights the difficulty of getting things right at the first time in the area of authentication. • Authetication protocols in use are no simpler than these presented.

24. Authentication protocols – one-way authenticationconventional encryption approaches • One-way authentication is needed in all applications where the sender and receiver are not online at the same time. The most important application is of course e-mail. • One possible conventional protocol can be achieved by refining the KDC strategy in fig. 5.9. • A  KDC: IDA|| IDB ||N1 • KDC A: EKa[Ks || IDB ||N1|| EKb[Ks || IDA]] • AB: EKb[Ks || IDA] || EKs[M] • This guarantees confidentiality. It also gives a level of authentication that the sender is A. However, this protocol does not protect against replays. In principle timestamps could be added, but potential delays in one-way communication would require very large time windows, thus leaving plenty of time for replay attacks. • The solutions for a one-way authentication are found on the public-key side.

25. Authentication protocols – one-way authenticationpublic-key encryption approaches • Public key approaches suitable for the encryption of e-mail have already been presented: confidentiality as in fig. 8.1b, authentication as in fig. 8.1c or both in fig. 8.1d. • in these approaches however the recepient knows the senders public key and that the sender knowe recepients public key • also these involve encrypting a potentionally long message with inefficient public key algorithms. • If confidentiality is the primary concern, then the following is more efficient (the message is encrypted with conventional one time session key) • AB: EKUb[Ks] || EKs[M] • If authentication is the primary concern, then a digital signature may suffice, illustrated in fig. 8.5c. • AB: EKRa[H(M)] || M • This quarantees that A can not deny having sent the message. This is however opent to another kind of fraud: an opponent can change the signature for his own, and then claim having sent the message (i.e. in case where the sender gets some credit)

26. Authentication protocols – one-way authenticationpublic-key encryption approaches • To counter such a scheme, both the message and the signature can be further encrypted with the recipients public key • AB: EKUb[ EKRa[H(M)] || M ] • The two last schemes require that the receiver knows the senders public key and is convinced that it is timely. A way to provide this assurance is the digital certificate (introduced earlier in lectures). • AB: M || EKRa[H(M)] || EKRas[T||IDA||KUa] • The certificate is encrypted with the authoritys private key (granted by the authority). The recipient of the message uses the certificate to obtain the senders public key and verify its authenticity, and the uses the public key to verify the message itself. • If confidentiaity is required the entire message can be encrypted with a one time secret session key transmitted as encrypted with receivers public key. This approach is widely used in e-mail security (PGP, S/MIME) and will be explored later in the lectures.