DF391 Burris Fall 2007 Lab 2: To receive credit for the lab you must demonstrate to me your code performs the desired task in a live demonstration outside class. You may use university or personnel equipment. You may not use code from any source other than the notes without my expressed written permission. Use of outside resources including family, friends, tutors, or paid help will result in an “F” for the class. You are however encouraged to discuss strategy, how you solved problems, and provide reasonable comfort/aid to other members of the class. Submit printed copies of all code, data files, and other pertinent materials. Code and executables (were possible) should be submitted on a CD. Your lab should be submitted in a 8-1/2 by 11 mailing envelop. You may use the same envelop for all labs. To master the field of Digital Forensics, you must be knowledgable in all aspects of digital communications. I recommend the use of Java for this lab as it will minimize your learning curve. You may however use other languages by asking permission prior to starting the lab. Due: Monday November 26, 2007. Early submissions are appreciated. Write this lab in a highly modular fashion. Expect to implement essentially the same lab at a future date using servlets, SSL, and RMI. You should consider reuse of your code as a major goal! You need not concern yourself with the man-in-the-middle attack on this lab. Future labs should be “significantly” easier to implement, i.e., minimal modifications of this lab. An interesting application requiring authentication is logging in to a computer network, host computer, or automated money machine (ATM). Generally, a user is required to supply a user name and corresponding password. The host creates and stores a table of usernames and corresponding passwords. If an unscrupulous user or hacker is able to obtain access and copy the table off the server, ATM, or backup media, they now have substantial leverage. In 1969, Roger Needham and Mike Guy (http://www.smat.us/crypto/auth/authent01.pdf as reported in Chapter 1 of “Authentication: From Passwords to Public Keys,” by Richard E. Smith (9/12/01) ISBN 0-201-61599-1, Addison Wesley Longmire Inc) noted a server really does not need to know the passwords; it just needs to be able to differentiate valid passwords from invalid passwords. Their technique is known as Authentication Using One-Way Functions and is widely utilized especially by operating systems. The technique proceeds as follows: Storing the one-way function: As legitimate users and passwords are entered into the system, a one-way hash is computed for the password. The user name and hash are stored for future reference. The password is discarded. Access to the system: 1) To login, the user enters their user name and password. 2) The host computes a one way hash of the password then discards the actual password. 3) The host now compares the one way hash to the previously stored value of the hash associated with the account name. If it is the same as the stored value the user is authenticated. “C” Option ( best grade is 75): Please implement a password system for a manufacturer storing at least 10 user names and password hashes in an array as described by Needham and Guy. You may create the contents of the array using any reasonable manner desired so long as you actually create the hash values. Once users are authenticated, they wish to be able to exchange an arbitrary number of communications with the manufacturer using symmetric encryption. The following protocol has been agreed upon to determine an encryption algorithm and secret key. Protocol: 1) Using a socket, customers contact the server (manufacturer) and login in for validation using their account name and password. 2) Upon validation, the manufacturer and customer determine a secret session key via a two part process. First they determine an initial secret key based on the work of Diffie-Helleman. It has been decided to use the SKIP protocol with a 1024 bit key. Once the initial key has been determined, you may utilizing hashing or another technique of your choice to reduce it to a size appropriate (number of bytes) to initialize the symmetric key encryption algorithm. The rest of the communications are completed using symmetric encryption. 3) The client should determine the symmetric algorithm to be used and communicate their choice to the server. The server should support at least three symmetric encryption algorithms. You are free to take advantage of code from examples used in class as long as you document the source (do not plagiarize). Implement the client and server. Both client and server should print sufficient material to show they have: 1) Properly completed the login protocol. 2) Generated the same initial key using SKIP. 3) The client must encrypt a file and transmit it to the server. The server must then decrypt the file. You must convenience me this communication has been accomplished during a live demonstration. 4) The server must encrypt a file (with different contents) and transmit it to the client. The client must then decrypt the file. You must convenience me this communication has been accomplished during a live demonstration. “B” Option (best grade is 85): The server must send an email to an address supplied by the client acknowledging the day and time the conversation was initiated obtained from the system clock. The table of user names and password hashes must be kept in a database as opposed to an array. You will be expected to access the database via SQL statements. You must convenience me your design and implementation are three-tier. “A” Option: Implement the “B” option but the server must create a separate instance of itself to service each client. You must convenience me during your demonstration that you can support multiple clients simultaneously.