The Diffie-Hellman/Karn Encryption App

Transcription

1 The Diffie-Hellman/Karn Encryption App University of Cincinnati College of Engineering and Applied Science July, 2015 What can be done with this app? A group of students may send messages to each other. The entire group may be located in a single room, spread out over an entire building, or spread out anywhere as long as they have access to the internet address (xxx.xxx.xxx.xxx) of the server (described later). In this version a message may not be broadcast to a group of students. Any student may eavesdrop on a conversation taking place between other students. To counter this, students may encrypt their messages using the supplied Karn symmetric key cryptosystem. The Karn symmetric key cryptosystem requires communicating parties to share a number, calledakey, thatisnotknownbyanyoneelse. Akeythatissharedbytwostudents andnooneelsemaybecomputedusingadiffie-hellmankeyexchange, evenwitheavesdroppers watching all public key related transactions that are needed to compute the shared key. The shared key is used by a sender to encrypt a message (using Karn) and by a recipient to decrypt it. To counter this, an eavesdropper may perform a brute-force search for the shared key, trying numerous possibilities on an observed encrypted text until a message that makes sense is revealed. The task of breaking an encrypted message using a brute-force search for a shared key may be made easy or difficult by choosing a generator and modulus for the Diffie- Hellman key exchange from a list of four possibilities. This is decided by the teacher. Two communicating students may counter a brute-force attack on their key by recomputing a new Diffie-Hellman public key (generated from a personal secret) and performing a Diffie-Hellman key exchange before each message is sent. Although old messages may be saved by an attacker and broken over time, having many keys to break makes the task of breaking all of them more difficult (two students may send an important message between many garbage messages, all encrypted with different keys, to make the task difficult). A student may manually compute his or her Diffie-Hellman public key using a specialized calculator. A Diffie-Hellman public key requires a personal secret, known only to one individual. This can be chosen automatically or by the student.

2 A student may become an attacker and hijack a connection that exists between two other students. In that case, a sender s message arrives at the hijacker s console. The hijacker may manipulate the message, replace it with a totally different message, or discard it. The hijacker may send the message on to the intended recipient or some other student. The hijacker will be able to create shared secrets between itself and the sender and recipient in order to decrypt messages from the sender and re-encrypt for the recipient. What components does the app contain? Thetwomaincomponentsofthisapparetheserver, interfacedbytheserverwindowshown in Figure 1, and the client, interfaced by the opening student window shown in Figure 2. The server window is best opened from a jump drive that contains a file called server.jar and possibly a file called names.txt which holds student names. Insert the drive into a USB port. In the case of the Windows operating system, open Computer, find the drive, and click on the jar file. In the case of Linux, run the script called runserver which is also on the drive. The server jump drive should be operated only by the session administrator, probably a teacher. Every student should get a jump drive containing client.jar. A student brings up an opening student window by clicking on the file s icon (Windows) or by running the supplied script runclient (Linux). The following describes these and other windows that can be opened once the above are opened. Figure 1: The server window Figure 2: The opening student window The purpose of the server is to handle all communications between students. That is, if student A sends a message to student B, it is routed to the server first, then it is routed to B or student C, if student C is intercepting. If student C is just listening, the message is routed to both B and C. The server only routes messages and holds public keys. The server does not contain any personal secrets or shared keys. The server window controls the server and must be up and running on an administrator s system before students have signed on. All participants, students and administrators, use the contents of a single file of student names which is called names.txt. The names file is normally on the administrator s jump drive and is loaded by the server when it is started. If the file does not exist, it can be created by pressing the Names button (Figure 1). This opens the window shown in Figure 3. If names.txt exists in the same directory as server.jar when it was executed, the text area shows its contents, otherwise the text area is blank. Names, one per line, can be inserted 2

3 Figure 3: Editing the names file Figure 4: The file dialog into the text area, or deleted from it. Pressing the Write button creates or overwrites names.txt with the current contents of the text area. It is possible to read any file into the text area: press Search to bring up a file dialog box as shown in Figure 4 and select a file. To refresh the text area from names.txt press the Read button. Returning to Figure 1, the server is started by pressing the Server button. The server will not start without a names.txt file. If names.txt does not exist, the window of Figure 3 will open to allow the administrator to enter the roster and write names.txt. A message in the msgs: field of the server window will indicate a successful start of the server. Students will need to know the IP address of the server so their client apps can communicate with it. The IP address of the server is displayed in the text area of the server window. In Figure 1 the IP address shown is Finally, the modulus size may be set by selecting an entry in the modulus size: menu. Menu items are 2, 3, 6, 10, and 24 reflecting keys that are trivial, easy, moderate, difficult, and (practically) impossible to break using brute-force, respectively. These sizes can be changed at any time (more about this later). At startup, the system is set to have a modulus size of 2. The administrator can change the modulus size at any time during the session, even before the server is started, but, when a change occurs, students will have to redo Diffie-Hellman key exchanges for the change to take effect. A student must connect with the server and get the roster before opening the main student window which contains all the controls needed by a single student to transmit, receive, eavesdrop on, and intercept messages. The IP address of the server, mentioned earlier as being provided in the server window, must be known to the student. The student enters this number (or host name) in the upper left text field of Figure 2. If the server is running, the student presses the Get Names button which results in a list of names appearing in the who are you? menu field, shown on the right side of Figure 2. The student selects a name from the list as shown in Figure 5 to open a main student window. See Figure 6 for an example. The following bullets describe the features of the main student window and refer to Figure 6: The top-left radio button, labeled encryption, is used to select the mode in which 3

4 Figure 5: Selecting a student name Figure 6: A main student window messages are sent and read. The selection can be changed at any time. The yes selection means encryption and decryption will be applied to all messages and the no selection means messages will pass as is. The Calc button will be discussed last. The port field indicates the communication port numbers over which command and message traffic is sent. These are set without human interaction. The Public Key button is pressed to compute a Diffie-Hellman public key from an automatically generated personal secret. Pressing this button causes the p: and g: fields to be filled in as well as the pub key: field. The automatically generated personal secret is displayed in the p secret: field. The button is initially colored red to remind the student that a public key must be generated before the student can be considered online. See Figure 7 for an example using a modulus width of 24. Observe that the Public Key button is no longer red. 4

5 Figure 7: A main student window after a public key is generated Alternatively, a student may generate a public key by entering a chosen number in the p secret: field, and hitting return. The resulting computation is the same as if the Public Key button is pressed except the entered personal secret is used. The Send PK button is pressed to send the public key to the server. The Public Key and Send PK buttons are typically pressed one after the other at any time. However, when such action takes place, Diffie-Hellman key exchanges (see below) likely should be done with partners as well to make sure that the shared secret keys are the same for both. The Connect button makes the connection over which messages pass. Pressing this button will have effect only after a public key is generated and sent to the server. The button will stay red as a reminder until the student has established a message connection, in case some unexpected behavior is observed during communication operations. The DH Exchange button is pressed to generate a key that is shared between the student shown in the me: field and the student shown in the to: field (see the upper left side of Figure 7 for the location of these fields). The to: field is a menu so the me: student can choose any other student to share a key with, as long as that student has created and sent a public key to the server. The shared key is only computed for the me: student. The to: student may perform a similar operation as a me: in its own window to complete the Diffie-Hellman exchange. A list of shared keys is shown as a menu object which is labeled share secret key with: (see Figure 7 near the bottom, on the left). The Clear DH Key button is used to clear a shared key that exists between the students named in the me: and to: fields. This might be done if the me: 5

6 student suspects the to: student has hijacked a connection. To send a message to another student drop the to: menu and select that student s name. Type the message in the msg out: field and hit return or press the Send button. If encryption is OFF, that message appears in the sent: field of the sender and in the rcvd: field of the recipient unless Intercepting is ON for someone who is intercepting messages between the sender and recipient. The message is also shown in the recipient s msg in: field, preceded by the sender s name plus >>. If encryption is ON, the sent: and rcvd: fields will be encrypted. A message like Hello might encrypt to something like this: 1ae8pb0h9fjcfeoes08m5t9dks0dk4j5cvb1peh54v4ep6vbcu4svhl0stiqomiaec A student is a good guy by default. A student can become a bad guy using the following steps: 1. Press the Good Guy button (right side of window). This opens two menus with victim: labels, changes the button label to Bad Guy, and enables the Go button. 2. Choose a name from each menu. 3. Press the Go button. This enables the Not Intercepting button. Figure 8 shows an example after Jeremy Steel has become a bad guy and is eavesdropping on a conversation between Jill Simpson and Roger Doofenschmitz. Jill has encrypted the message so, although Jeremy can see the message, and he can see the message is intended for Roger, he cannot make sense out of it. Roger also sees the message and decrypts it because he shares a key with Jill. A bad guy can hijack a connection and intercept messages, modify them, and send them on to the intended recipient or someone else. To enable this feature press the Not Intercepting button as a bad guy. This will change the button to Intercepting. Pressing the Intercepting button releases interception for this particular bad guy only. When a bad guy becomes a good guy by pressing the now Bad Guy button, the Intercepting button returns to being Not Intercepting regardless of the state it is in when the Bad Guy button is pressed. the share secret key with: menu shows all shared secret keys that exist between me: and all other students. The Get Online Students button gets a list of the current online students and displays them in the online students menu to its left. This information could be used many ways, for example by a bad guy who can only hijack a connection that exists between online parties. Finally, the Calc button opens a utility window that may be used to check cryptographic computations and to crack shared keys. The utility window is shown in Figure 9. A student can perform a fundamental cryptographic calculation of g a mod p where a is a random number, g is a generator and p is a modulus. The student enters these values in the a:, g:, and mod: fields, respectively, and hits return to see the result in the = field. Alternatively, the student may press the Import g & p button and the Import Secret button to bring in the g, p, and 6

7 Figure 8: A main student window after becoming a bad guy. Jeremy Steel is eavesdropping onaconversationbutcannotdecryptbecausehedoesnothavethekeythatissharedbetween Roger and Jill. If Jeremy presses the Not Intercepting button, he can decrypt, hold, and modify messages and then destroy or send them on. p secret values from the student window, then hit return in one of those fields to see the public key (which should match the pub key: value in the student window) appear in the = field. Generators are an important mathematical concept and generators for a prime number may be found by pressing the Get Generators button. Every time this button is pressed a new generator is displayed in the messages: field. Figure 9 shows some of the generators for the prime number 131. A student may attempt to crack or verify a shared key in the three rows at the bottom of the utility window. Suppose a student is a bad guy, encryption is ON, and interception is OFF and suppose the student sees an encrypted message coming from some other student. The bad guy likely does not possess the shared key needed to decrypt. The bad guy can press the Import Encrypted button to load the encrypted message into the encrypted: field. Then the bad guy can guess a shared key for decryption in the guess secret: field and hit return. If the guess is the correct shared key, the message will decrypt to a readable plaintext message which will be displayed in the decrypted: field. Otherwise, garbage is displayed, as shown in Figure 9, and the bad guy will try another key. To speed up the process of guessing keys, the student may press the Step Up or Step Back buttons to instantly advance or regress the shared key value and attempt decryption. Possibly useful is the Auto button which cycles through many key guesses as the observer watches without having to press any other buttons. The Stop button stops the cycling. 7

8 Figure 9: A utility window showing a cryptographic computation g a mod p, an attempt at decrypting text using a guessed secret key, and some generators for the number 131. A student may press the Inverse button to open the window shown in Figure 10 to allow finding the modular inverse of a number. The example of the figure has found the inverse of 34 modulo 131 to be 27. The two numbers are entered at the top left, although in this case pressing the Get number & modulus button would do the same thing. The Start button is pressed and then the next button is pressed repeated until either the inverse is found or it is determined that no inverse exists. The Reset button allows another calculation to be made. Some examples Explore setting a public key in a main student window The server is started, modulus size is 2, no student windows have been opened Press the Server button (see Figure 1) to try to start a second server. A message server already running appears in the msgs: field of the applet window. 8

9 Figure 10: A windows for calculating the modular inverse of a number. Open a student window as described in the second bullet of the second section (see Figure 2 for the button and menu to use and Figure 6 for a main student window). Press Connect. The message public key must be made and sent before connection is made appears in the messages: field of the student window. Press DH Exchange. A message like Diffie-Hellman exchange canceled: perhaps Jay Collada has no public key appears in the messages: field. Press Send PK. The message public key has not yet been made appears in the messages: field. Press Public Key. This should give a successful public key computation and the messages: field should show Diffie-Hellman public key computed and set. Press Send PK. The messages field shows public key sent to server. See Figure 7 fields p:, q:, pub key:, and p secret for a possible result, at this point (forget about the bad guy for now). If the server had not been running the messages: field would have displayed public key exists but not a connection. If a server is started after a public key is set, the Public Key button then the Send PK buttons will have to be pressed, in that order, to register a public key. Press Connect to open a connection that will carry messages. 9

10 Have two students talk to each other. The messages are sent plaintext and encrypted. The server is started, modulus size is 2, one student window is open with public key computed and sent and a message connection established. Encryption is OFF. Interception is OFF. Open a second student window, choosing a name that is different from the already open student. Drop the to: menu of the first student and choose the name of the second student. Type Hello Dolly 1 in the msg out: field of the first student and hit return. The messages: field of the first student says the message is sent and the sent: field says Hello Dolly 1 but the message is not received by the second student because the second student has not yet established a message connection with the server. Now drop the to: menu of the second student and choose the name of the first student. Enter Hello Dolly 2 in the second student s msg out: field and hit return. Nothing happens due to the lack of a message connection with the server but the messages: field says that the modulus size has been received. Now create a public key for the second student, send it to the server, and establish a message connection with the server. Repeat the above two action sequences. Both sent: and both rcvd: fields contain Hello Dolly <1 or 2>. Both msg in: fields show the name of the sender, followed by >> and then Hello Dolly <1 or 2>. Next, click yes to encryption in the upper left corner of each student window and attempt to send a Hello Dolly message from one student to the other. This fails with the message Do Diffie-Hellman exchange with receiver first! in the messages: field. Press the DH Exchange button in both student windows. The messages: field says that the secret is set with the opposite student. Repeat sending the message from both students. The message is received by both and the sent: and rcvd: fields show the encryption. See Figure 11 for an example. Have a bad guy listen to a conversation between two students. The messages are sent plaintext and encrypted. The server is running. Two students have public keys and have established message connections with the server. The students have also completed a Diffie-Hellman key exchange. They have already sent messages to each other. Currently, encryption is OFF and interception is OFF. Open a third student window, choosing a name that is different from the other two. In the new student window, press Public Key, then Send Pk, then Connect to make and send a public key to the server and to establish a message connection. Press the Good Guy button. The Good Guy turns into a Bad Guy, victim menus appear, and the Go button is enabled. See Figure 8 for an example. Select the name of the first student in one menu and the name of the second in the other. Press the Go button. The messages: field says the student is becoming bad and names the students he or she will be watching (listening to). Send a message from one of the good guys to the other. The recipient will see the message, as usual. However, the bad guy also sees the message and knows who it is from. 10

11 Figure 11: A student window after an encrypted message exchange Turn encryption ON for all three students. Send a message from one good guy to another. The encrypted text is decrypted by the intended recipient and captured by the bad guy but the bad guy does not have the secret that is shared by the good guys so the bad guy cannot decipher the message. Press the Calc button of the bad guy s window to bring up the utility window. Press the Import encrypted button of the utility window to bring the captured text into the encrypted: field. Enter a number into the guess secret: field and hit return. Use the Step Up and Step Back buttons to change the guess incrementally. The guessed secrets are applied to the encrypted text to yield the result in the decrypted: field. See Figure 12 for an example. Have a bad guy intercept a conversation between two students. The messages are sent without encryption. The server is running. Two students have public keys and have established message connections with the server. The students have also completed a Diffie-Hellman key exchange. They have already sent messages to each other. A third student has become a bad guy and is listening to the other two students. The third student has not yet completed a Diffie-Hellman key exchange with the other two students. Currently, encryption is OFF and interception is OFF. 11

12 Figure 12: A bad guy has captured encrypted text and is using the utility window to attempt to decrypt it. In the foreground and in focus, is the sender s window which shows the plaintext message and its encrypted form. The background window belongs to the receiver and shows that the message was received and decrypted. The window that belongs to Jeremy Steel (the bad guy ) has captured the encrypted text but, as the msg in: field shows, this has not been decrypted. So Steel has opened the utility window, shown in the foreground but not in focus, has pressed the Import encrypted button to put the encrypted text into the encrypted: field, and has guessed a key value of Applying to the decryption algorithm results in the garbage shown in the decrypted: field. Press the Not Intercepting button on in the bad guy window. It becomes Intercepting. Setthe to: fieldofthe badguy swindowtothenameofoneofthetwo goodguys. Press the DH Exchange button in the bad guy s window and note success in the messages: field. Do the same for the other good guy. At this point, when one good guy sends a message, it will be intercepted by the bad guy - the key used for encryption will be a key shared by the bad guy and the good guy sender. The bad guy will be able to modify the message and send it to whomever it wishes. Choose a good guy window and make sure its to: field has the name of the other good guy. Enter a message in the msg out: field of the chosen good guy and hit return. The message appears in both the msg out: and msg in: fields of the bad guy. The message is placed in the msg out: field, without the name of the sender preceding it, for convenience as it can easily be edited and sent on from there. The message is not seen by the intended recipient. Note that the to: field of the bad guy has been automatically set to the intended recipient in case the bad guy wants to forward a modified message to that student. 12

13 Have a bad guy intercept a conversation between two students. The messages are sent encrypted. The server is running. Two students have public keys and have established message connections with the server. The students have also completed a Diffie-Hellman key exchange. They have already sent messages to each other. A third student has become a bad guy and is listening to the other two students. The third student completed a Diffie-Hellman key exchange with both good guy s and interception is ON. If encryption is not on, turn it on for all parties. See the previous example for details about setting up this scenario. The only difference between that scenario and this is the encryption. As before, send a message from one good guy to another and note that the message arrives at the bad guy. The rcvd: field of the bad guy shows an encrypted message but the msg in: and msg out: fields show the message has been successfully decrypted. As long as the to: field has not been changed manually, it should hold the name of the intended recipient. Modify the message in the msg out: field and hit return. The message will be encrypted with a secret that is shared between the recipient and the bad guy and the encrypted version will be sent to the recipient. Look at the recipient s window to verify that it has received the modified message and has decrypted it. Note that the name displayed in the msg in: field of the recipient is not the name of the bad guy but the name of the sender. Thus, is is not a trivial matter for the recipient to verify that the message can directly from the sender although it is likely that the sender was involved in sending some message to the recipient. Note also, that sending time in the message to help with the identification of the message is useless as the bad guy can modify the time as well. Have a bad guy return to being a good guy. The server is running. Two students have public keys and have established message connections with the server. The students have also completed a Diffie-Hellman key exchange. They have already sent messages to each other. A third student has become a bad guy and is intercepting the conversation between the other two students. Currently, encryption is ON and interception is ON. Click the Bad Guy button. It becomes a Good Guy button, the victim menus disappear, the Intercepting button becomes a Not Intercepting button and is disabled, and the Go button is disabled. Send a message between the good guy s and note that it arrives without modification and the former bad guy does not see it. Things to remember and things of note It is OK to send messages to oneself and it is OK to do a Diffie-Hellman exchange with oneself. Thus one can send encrypted messages to oneself and witness the entire encrypt-decrypt process without interacting with anyone else. This may be useful in determining the cause of some problem. 13

14 Every time the Public Key button is pressed, a new personal secret is generated and used for the public key. There is no way to get it back by clicking a button. However, thecurrentpersonalsecretisshowninthe psecret: field, sothisvaluecanberecorded manually before pressing the Public Key button if later use of the current public key is anticipated for some reason. In the case of a man-in-the-middle attack, an eavesdropper C will convince good guys A and B that A shares a key with B although A and B actually share keys with C. Thus, if the eavesdropper ends the attack, A and B will be stuck without a shared key. This app does things a little differently: the original key that is shared between A and B, if any, is saved and reinstated after C leaves. When switching from a good guy to a bad guy, the student does not really become a bad guy until the Go button is pressed. Thus, the Intercepting button is not enabled until that happens. Messages from a bad guy to anyone else are not intercepted. This could easily be changed, perhaps with a button on the server. There could be more than one bad guy intercepting a connection between two good guys. Only one interception is enough to divert a message sent to B from A to an attacker. If the name in the to: menu is changed and there is no shared secret with that name, the DH Exchange key will be colored yellow as seen in Figure 13. If a shared secret exists between the name shown in the me: field and the name displayed in the to: menu and one of the two changes its public key ( Public Key button, say), sends the public key to the server ( Send PK button), and presses the DH Exchange button to generate a new secret, then the DH Exchange key of the other nameturnsblueto indicate an updateisnecessary (Figure 14). When ablue DH Exchange button is presses, a new secret matching that of the first name is computed and saved. 14

15 Figure 13: Roger Doofenschmitz shares no secret key with Jill Simpson. The background window belongs to Jill. Figure 14: A secret between Roger Doofenschmitz and Jill Simpson had existed but Jill s public key was updated and her DH Exchange button was pressed resulting in a secret that does not agree with Roger s, as seen in the background window (belonging to Jill) near the bottom. This mismatch is indicated to Roger with a blue DH Exchange button. Roger s likely next step is to press his DH Exchange button. Doing so will cause the keys to match and return the DH Exchange button to its original color. 15