ECE646 Fall 2015 Lab 1: Pretty Good Privacy Instruction PLEASE READ THE FOLLOWING INSTRUCTIONS CAREFULLY: 1. You are expected to address all questions listed in this document in your final report. 2. All e-mails exchanged with other students as a part of this lab should be sent with CC: to gmuece646@gmail.com. 3. A LAB REPORT must be submitted using Blackboard by Saturday, October 24, 11:59 PM. In order to perform this lab, you are expected to have an understanding of LECTURES 1, 2, 3, 4A, and 4B, Stallings, Chapters 9.1 Principles of Public-Key Cryptosystems 13.1 Digital Signatures 14 Key Management and Distribution 19.1 Pretty Good Privacy (PGP), and Appendix O Data Compression Using Zip Appendix P PGP Random Number Generation. You can also use: The Gpg4win Compendium, English version, Version 3.0.0, from 3rd August 2015, which should have been copied to your computer during the GPG installation.
1. KEY DISTRIBUTION: DIRECT TRUST GROUP Export your public key to an ASCII file (GPA: Export, Kleopatra: Export Certificates). Send your own public key to all members of your DIRECT TRUST GROUP by email. Please remember to CC: your communication to gmuece646@gmail.com Import public keys of your DIRECT TRUST GROUP members to your public key ring. Verify the public keys fingerprints of imported keys against the fingerprints listed on the cards, you received from your classmates (GPA: displayed by default, Kleopatra: mouse right click, Certificate Details) If this verification is successful, sign the keys of your DIRECT TRUST GROUP. Hint: You can use GPA: Keys => Sign Keys, or Kleopatra: Certificates => Certify Certificates (Certify for everyone to see). Set the trust you have in the owner of each public key you received, when this owner serves as an introducer of other users Hint: You can use GPA: Keys => Set Owner Trust, or Kleopatra: Certificates => Change Owner Trust If you are impatient and do not want to wait for responses from other students, you can start from exchanging public keys with your virtual friend Adele <adele-en@gnupp.de>. Adele will respond to your messages automatically, and she will send you her public key. You may afterwards exchange also signed and encrypted messages with her. Please be aware that Adele is a busy robot, and she may take several minutes to respond to your messages. 1. Which keys are protected by a passphrase and why? 2. How can you transfer your public keys to another user (list multiple ways, beyond those used in this lab) 3. How does the receiver know that a public key you sent really belongs to you? 4. Draw a hierarchal diagram showing your public-key-ring web of trust (including Adele if you exchanged public keys between each other) 2. KEY DISTRIBUTION: INTRODUCING NEW USERS Introduce two new users to each member of your DIRECT TRUST GROUP, using the following rule: To the first member of your DIRECT TRUST GROUP, introduce two true users (i.e., the remaining two members of your DIRECT TRUST GROUP). To the second member of your DIRECT TRUST GROUP, introduce one true user (i.e., one of the two remaining members of your DIRECT TRUST GROUP), and one fake user (for whom you generated an e-mail account and a public-private key pair during the LAB SETUP). To the third member of your DIRECT TRUST GROUP, introduce two fake users (for whom you generated two e-mail accounts and two corresponding pairs of public-private keys during the LAB SETUP). Each introduction should include o o a short cover letter, and a public key of the introduced user signed by you (Hint: you can just sign the key in your public key ring, and then export it).
Import all received public keys to your public key ring, unless you know for sure that they are fake (e.g., because a user introduced to you is already a member of your DIRECT TRUST GROUP). In this case, inform the sender immediately that you rejected his/her introduction. 5. List all fake (e-mail ID, key ID) pairs you created. 6. List two users introduced to each member of your DIRECT TRUST GROUP, and mark which one is true, and which one is fake. 7. Draw a hierarchical diagram showing your entire public-key-ring web of trust (keep updating this diagram as you are introduced to the new users). 3. SIGNATURE GENERATION Using an ASCII text editor, prepare a relatively small text file with a message revealing some information about you, which other students may not be aware of. Prepare similar files with messages pretended to be written by 3 students you are trying to impersonate. Sign all messages using respective private keys, and send them to the users who are in possession of the corresponding public keys. Please note that one of such users is your virtual friend Adele. Please note that you can use at least the following two methods to sign a file: Kleopatra: File => Sign/Encrypt Files (Sign, Sign with Open PGP), or Windows Explorer: choose a file, right click with your mouse, and choose More GpgEX Options (Sign). In each case, you can also choose whether your output will be stored in a binary file, or in an ASCII file composed of only visible characters (Option: Text output (ASCII armor)). Please try both values of this option to see the difference. Investigate all output files, looking at their contents and the length. Send the obtained files (all and only files which are required to verify the signature) to the intended recipients. 8. What transformations are performed during signing (with and without ASCII Armor set)? 9. Which algorithms are used during each of these transformations? 10. What keys are required to perform these transformations? 11. Where are these keys stored? Which of these keys are protected using a passphrase? What are the pros and cons of using passphrases. 12. Determine, compare, and explain the sizes of signatures for each message. 4. SIGNATURE VERIFICATION Verify all signatures generated by yourself, using your public key. Change a single character in each message, and do the verification again. Verify the signatures associated with messages you have received from other students. Decide whether these messages are authentic based on the factors such as: a) your trust in the public key of the sender
b) your trust in a person who introduced a public key of the sender to you c) text of the message. 13. Describe and explain the behavior of the program during verification of correct and modified messages. 14. What transformations, algorithms, and keys are used during the signature verification? 15. Document your conclusions regarding the authenticity of the signed messages you received. 5. ENCRYPTION Using an ASCII text editor please prepare a few secret messages to be sent to users whose public keys are located in your public key ring. You can also encrypt larger binary files such as photos and PDF files. Encrypt these files, using the respective receiver s public keys, and then separately, for testing purposes only, using your public key. Send the obtained files to the intended recipients, using your true e-mail account, as well as fake accounts of other students, which you control. Investigate the encrypted files, looking at their contents and length. 16. How would you explain the relations between the length of the file before and after the encryption for each set of options? 17. What transformations are performed during encryption (with and without ASCII Armor set)? 18. What keys are required to perform these transformations? Where are these keys stored? Which of these keys are protected using a passphrase? 19. Can you change the order of these transformations without affecting the program functionality or security? 20. Which algorithms are used during each of these transformations? What are the key sizes used in each of these algorithms? Can you change these key sizes? If so, how? 21. When you send an encrypted file to a recipient what kind of security service(s) are you using? 6. DECRYPTION Try to decrypt all files you have either encrypted by yourself or received from other students. 22. How can the receiver decrypt the file without having to agree with the sender in advance on using the same set of options and algorithms? 23. Can you be sure of the authenticity of the message sender? If not, how could you possibly change the encryption options to guarantee message authentication? 24. Can you be sure of the integrity of the message? If not, how could you possibly change the encryption options to guarantee message integrity?
25. What happens if you change a single byte in the encrypted file before the decryption? How reliable is the message integrity protection you observe? 7. REVEALING FAKE USERS (this step should be performed only within the last 48 hours before the deadline) Make an educated guess regarding the authenticity of all messages you have received as a part of this lab so far. Communicate this guess to all users you have received messages from. Respond to these guesses, revealing your true identity. 26. Were any of your attempts to cheat successful? If no, why? If yes, what was the major weakness of the key distribution procedure used in this exercise that has made your attack successful? 27. Were you able to identify any fake messages by yourself? If yes, how? If no, why? 28. On the hierarchical diagram showing your web-of-trust, label each key as either legitimate or fake. If a key is fake, write the name of a real owner next to it. 8. OpenPGP CERTIFICATE SERVER Investigate the use of the following Kleopatra options Export Certificate to Server, and Lookup Certificate on Server. 29. Would the use of OpenPGP Certificate Server prevent any weaknesses of the key distribution scheme used in this lab. If yes, how? If no, why? 9. PGP & E-MAIL PROGRAMS (BONUS) GnuPG can be integrated into some popular e-mail programs, such as Outlook. 29. Describe all steps necessary to plug-in GnuPG into a selected e-mail program. 30. Using this integrated environment, send a signed message to gmuece646@gmail.com, the message should contain at least, your name, email address and public key fingerprint in HEX. Include your e-mail in the final report.
10. COGNITIVE WALKTHROUGH Evaluate the usability of Gpg4win v. 2.2.6, using the method of Cognitive Walkthrough, described in the paper: A. Whitten and J.D. Tygar, Why Johnny Can t Encrypt: A Usability Evaluation of PGP 5.0, in Proc. USENIX, 1999. [Online]. Available: http://www.gaudior.net/alma/johnny.pdf Perform your evaluation separately for: 1. GPA used together with GpgEX (required) 2. Kleopatra used together with GpgEX (BONUS) Summarize your findings regarding at least the following aspects of the program usability, analyzed in the aforementioned paper: 1) Visual metaphors 2) Different key types (and applications) 3) Key server 4) Key management policy 5) Irreversible actions 6) Consistency 7) Too much information as well as 8) Agreement of terminology used by the program with terminology introduced in ECE 646. For each evaluated aspect, please do your best to determine whether the new version of the program is easier or more difficult to use and fully understand compared to PGP 5.0, evaluated in 1999 by the authors of the aforementioned paper. Please suggest any possible improvements to the user interface, functionality, and documentation of the program to make it easier and more secure to use. 11. USER TEST (BONUS) Using a small group of volunteers with the limited earlier exposure to cryptography (such as family members, roommates, friends, colleagues, etc.), perform a user test described in the papers: 1. A. Whitten and J.D. Tygar, Why Johnny Can t Encrypt: A Usability Evaluation of PGP 5.0, in Proc. USENIX, 1999. [Online]. Available: http://www.gaudior.net/alma/johnny.pdf 2. A. Whitten and J.D. Tygar, Usability of Security: A Case Study, Carnegie Mellon University School of Computer Science Technical Report CMU-CS-98-155, Dec. 1998. [Online]. Available: http://reports-archive.adm.cs.cmu.edu/anon/1998/abstracts/98-155.html 3. S. Sheng et al., Why Johnny Still Can t Encrypt: Evaluating the Usability of Email Encryption Software, in Proc. Symposium on Usable Privacy and Security, 2006, [Online]. Available: http://www.chariotsfire.com/pub/sheng-poster_abstract.pdf Start the test from the short Orientation and Task Description (see [2], Appendix F). After the test, perform the debriefing of each participant using the questionnaire provided in [2], Appendix G. As a part of your report, please provide at least: 1. Participant demographics, i.e., Gender, Age, Highest education level, Education or career area. See [2], Appendix A. 2. Short description of testing process. See [2], Appendix B. Please feel free to significantly simplify the test. 3. Summary of answers provided by the participants to the questions from the debriefing questionnaire. See [2], Appendix G. 4. Summary of your own observations regarding correct steps and mistakes made by the participants. See [1], Section 5.3. 5. Any conclusions from your user test. See [1], Section 6. 6. Proposed improvements in the user interface and functionality of the program.