Chapter 10 : Private-Key Management and the Public-Key Revolution

Transcription

1 COMP547 Claude Crépeau INTRODUCTION TO MODERN CRYPTOGRAPHY _ Second Edition _ Jonathan Katz Yehuda Lindell Chapter 10 : Private-Key Management and the Public-Key Revolution 1

2 Chapter 10 Private-Key Management and the Public-Key Revolution 10.1 Key Distribution and Key Management 10.2 A Partial Solution Key Distribution Centers 10.3 Key Exchange and the Diffie-Hellman Protocol 10.4 The Public-Key revolution

3 10.1 Key Distribution and Key Management We have seen that private-key cryptography can be used to enable secure communication over an insecure channel. While it therefore appears to solve completely the primary problem of cryptography, we discuss here a number of reasons why that is not the case.

4 The Key-Distribution Problem The initial sharing of a secret key can be done using a secure channel that can be implemented, e.g., using a trusted messenger service. This option is likely to be unavailable to the average person, though governments, the military, intelligence organizations, and other such entities do have the means to share keys in this way.

5 The Key-Distribution Problem A more pragmatic method for two parties to share a key is for these parties to arrange a physical meeting at which time a random key can be generated, and a copy of the key given to each party. Although one can imagine two users arranging such a meeting on a dark street corner, a more commonplace setting where this might take place is a standard work environment.

6 The Key-Distribution Problem A partial solution in this setting is to use a designated controller (say, the IT manager of the company). Specifically, when a new employee joins the company the controller could generate random keys k1,..., give these keys (in person) to the new employee, and then send key ki to the i th existing employee by encrypting ki using the secret key shared between the controller and this employee.

7 The Key-Distribution Problem This is a very cumbersome approach. More importantly, it does not give a complete solution since keys are not completely secret. A dishonest controller could decrypt all interemployee communication.

8 Key Storage and Secrecy When there are U employees, the number of secret keys in the system is Θ(U 2 ). More importantly, this means that every employee holds U 1 secret keys. In fact, the situation may be far worse because employees may also need keys in order to communicate securely with remote resources such as databases, servers, and so on.

9 Key Storage and Secrecy When the organization in question is large this creates a huge problem, on a number of levels. When only a few keys need to be stored, however, there are good solutions available for dealing with this threat. A typical solution today is to store keys on a smartcard, a highly-protected hardware device.

10 Open Systems At least in theory, however, it can be used to solve the problem of secure communication in closed systems where it is possible to distribute secret keys via physical means. Unfortunately, in open settings where parties have no way of securely distributing keys, private-key cryptography by itself is simply insufficient.

11 Open Systems For example, when encryption is needed for making a purchase over the Internet, or for sending to a colleague in another country (whom the sender may never have met), private-key cryptography alone simply does not provide a solution.

12 10.2 A Partial Solution Key Distribution Centers An approach is to rely on the fact that all employees may trust some entity say, the IT manager of the organization at least with respect to the security of work-related information. It is therefore possible for the IT manager to set up a single server, called a key distribution center (KDC), that can act as an intermediary between employees that wish to communicate.

13 Key Distribution Centers Alice and Bob

14 Key Distribution Centers A KDC can work in the following way. First, all employees share a single key with the KDC; this key can be generated and shared, e.g., on the employee s first day at work. Then, when employee Alice wants to communicate securely with employee Bob, she sends a message to the KDC saying Alice wishes to communicate with Bob (where this message is authenticated using the key shared by Alice and the KDC).

15 Key Distribution Centers The KDC then chooses a new random secret key, called a session key, and sends this key to Alice encrypted using Alice s key, and also to Bob encrypted using Bob s key. Once Alice and Bob recover the session key, they can use it to communicate securely. When they are done with their conversation, they can (and should) erase this key because they can always contact the server again should they wish to communicate again at some later time.

16 Key Distribution Centers Consider the advantages of this approach: 1. Each employee needs to store only one secret key and so a smartcard-type solution can be deployed. It is true that the KDC needs to store many keys. However, the KDC can be secured in a safe place and given the highest possible protection against network attacks. 2. When an employee joins the organization all that must be done is to set up a secret key between this employee and the KDC. No other employees need to update the set of keys they hold. The same is true when an employee leaves the organization.

17 Key Distribution Centers There are also some disadvantages to this approach: 1. A successful attack on the KDC will result in a complete break of the system for all parties. Thus, the motivation to break into the KDC is very great, increasing the security risk. In addition, an adversary internal to the organization who has access to the KDC (for example, the IT manager) can decrypt all communication between all parties.

18 Key Distribution Centers There are also some disadvantages to this approach: 2. The KDC is a single point of failure: if the KDC crashes, secure communication is temporarily impossible. Since all employees are continually contacting the KDC, the load on the KDC can be very high thereby increasing the chances that it may fall or be slow to respond. A simple solution is to replicate the KDC. This works but the existence of more KDCs means that there are now more points of attack on the system. Furthermore, it becomes more difficult to add or remove employees, since updates must be securely propagated to all KDCs.

19 Key Distribution using a KDC

20 Protocols for key distribution using a KDC Roger Needham and Michael D. Schroeder

21 Protocols for key distribution using a KDC There are a number of protocols that can be found in the literature for secure key distribution using a KDC. One of these is the classic Needham-Schroeder protocol. We will not go into the details of this protocol. We do mention one engineering feature of the protocol.

22 Protocols for key distribution using a KDC When Alice contacts the KDC and asks to communicate with Bob, the KDC does not send the encrypted session key to both Alice and Bob. Rather, the KDC sends the session key encrypted under both Alice s and Bob s keys to Alice, and Alice herself forwards to Bob the session key encrypted under his key; see Figure 10.1.

23 Protocols for key distribution using a KDC

24 Protocols for key distribution using a KDC The protocol was designed in this way due to the fact that Bob may not be online; this could potentially cause a problem for the KDC who might hang indefinitely waiting for Bob to respond. By sending both encrypted keys to Alice, the KDC is relieved of maintaining an open session. The session key encrypted under Bob s key that the KDC sends to Alice is called a ticket, and can be viewed as a credential allowing Alice to talk to Bob.

25 Protocols for key distribution using a KDC A very widely-used system for implementing user authentication and secure communication via a KDC is the Kerberos protocol that was developed at MIT. Kerberos has a number of important features, and is the method used by Microsoft Windows (in Windows 2000 and above) for securing an internal network.

26 10.3 Diffie-Hellman Key Exchange

27 Public-key primitives An interactive key-exchange protocol is a method whereby parties who do not share any secret information can generate a shared, secret key by communicating over a public channel. The main property guaranteed here is that an eavesdropping adversary who sees all the messages sent over the communication line does not learn anything about the resulting secret key.

28 Diffie-Hellman Key Exchange

29 8.3.2 The Discrete Logarithm and Diffie-Hellman Assumptions Fix a cyclic group G and a generator g G. Given two group elements h1,h2, define DHg(h1,h2) def = g log g h 1 log g h 2. That is, if h1 = g x and h2 = g y then DHg(h1,h2) = g x y = h1 y = h2 x. The CDH problem is to compute DHg(h1,h2) given randomly-chosen h1 and h2.

30 8.3.2 The Discrete Logarithm and Diffie-Hellman Assumptions If the discrete logarithm problem relative to some G is easy, then the CDH problem is, too: given h1 and h2, first compute x = logg h1 and then output the answer (h2) x. In contrast, it is not clear whether hardness of the discrete logarithm problem necessarily implies that the CDH problem is hard as well.

31 8.3.2 The Discrete Logarithm and Diffie-Hellman Assumptions The DDH problem, roughly speaking, is to distinguish DHg(h1,h2) from a random group element for randomly-chosen h1,h2. That is, given randomly-chosen h1, h2 and a candidate solution h, the problem is to decide whether h = DHg(h1,h2) or whether h was chosen randomly from G.

32 8.3.2 The Discrete Logarithm and Diffie-Hellman Assumptions DEFINITION 8.63 We say that the DDH problem is hard relative to G if for all probabilistic polynomial-time algorithms A there exists a negligible function negl s. t. Pr[A(G, q, g, g x, g y, g z ) = 1] Pr[A(G, q, g, g x, g y, g xy ) = 1] negl(n) where in each case the probabilities are taken over the experiment in which G(1 n ) outputs (G, q, g), and then random x, y, z Zq are chosen.

33 Diffie-Hellman Key Exchange THEOREM 10.3 If the decisional Diffie-Hellman problem is hard relative to G, then the Diffie-Hellman keyexchange protocol Π is secure in the presence of an eavesdropper.

34 Active adversaries Although eavesdropping attacks are by far the most common (as they are so easy to carry out), they are by no means the only possible attack. Active attacks, in which the adversary sends messages of its own to one or both of the parties are also a concern, and any protocol used in practice must be resilient to active attacks.

35 Active adversaries It is useful to distinguish between impersonation attacks where only one of the honest parties is executing the protocol and the adversary impersonates the other party, and man-in-the-middle attacks where both honest parties are executing the protocol and the adversary is intercepting and modifying messages being sent from one party to the other.

36 Active adversaries It is worth remarking that the Diffie-Hellman protocol is completely insecure against man-in-the-middle attacks. In fact, a man-in-the-middle adversary can act in such a way that Alice and Bob terminate the protocol with different keys ka and kb that are both known to the adversary, yet neither Alice nor Bob can detect that any attack was carried out.

37 10.4 The Public-Key Revolution Whitfield Diffie and Martin Hellman

38 10.4 The Public-Key Revolution In 1976, Whitfield Diffie and Martin Hellman published a paper with an innocent-looking title called New Directions in Cryptography. The influence of this paper was enormous. In addition to introducing a fundamentally different way of looking at cryptography, it served as one of the first steps toward moving cryptography out of the private domain and into the public one.

39 The Public-Key Revolution We can imagine a cryptosystem where there are two keys instead of one: one of these keys is an encryption key, used by senders to encrypt their messages, and the other is a decryption key, used by the receiver to recover the message from a ciphertext.

40 The Public-Key Revolution Furthermore and here it is amazing that something of this sort could possibly exist! the secrecy of encrypted messages should be preserved even against an adversary who knows the encryption key (but not the decryption key). Encryption schemes with this property are called asymmetric or public-key encryption schemes, in contrast to the symmetric, or private-key, encryption schemes that we have seen so far.

41 The Public-Key Revolution In a public-key encryption scheme the encryption key is called the public key, since it is publicized by the receiver so that anyone who wishes to send an encrypted message may do so, and the decryption key is called the private key since it is kept completely private by the receiver.

42 The Public-Key Revolution

43 The Public-Key Revolution 1/3. Public-key encryption allows key distribution to be done over public channels. This can potentially simplify initial deployment of the system, and can also ease maintenance of the system when parties join or leave. 2/3. Public-key encryption vastly reduces the need to store many secret keys. Even if all pairs of parties want the ability to communicate securely, each party need only store his own private key in a secure fashion. Other parties public keys can either be obtained when needed, or stored in a non-secure (i.e., publicly-readable) fashion.

44 The Public-Key Revolution 3/3. Finally, public-key cryptography is (more) suitable for open environments where parties who have never previously interacted want the ability to communicate securely. For example, a merchant can post their public key on-line; any user making a purchase can obtain the merchant s public key, as needed, when they need to encrypt their credit card information.

45 Public-key primitives Diffie and Hellman actually introduced three dis- tinct public-key (or asymmetric) primitives. Interactive Key Exchange. Public-key encryption (Chapter 11). Public-key analogue of message authentication codes, called Digital Signatures (Chapter 12).

46 COMP547 Claude Crépeau INTRODUCTION TO MODERN CRYPTOGRAPHY _ Second Edition _ Jonathan Katz Yehuda Lindell Chapter 10 : Private-Key Management and the Public-Key Revolution 46