|
T. Andrew Yang
|
last updated: 4/2/2009 |
|||
|
CSCI 5233
Computer Security & Integrity Assignment 1
1.A (10 pts) Visit the class
discussion group and join the group as a member. Throughout this class,
you shall regularly visit the discussion group to find recent announcements,
reminders, and discussions. Print out the confirmation message in
response to your membership request, and hand it in as part of this
assignment. Review information in the file “Installation of JCE security provider for unlimited strength security”, and become familiar with JCE security providers and the unlimited strength Java security policy. Please note that the instructions given in the document have been rigorously tested and, if followed correctly, should enable your Java environment to run all the sample programs that come with the 'Java Security' book. If you run into problems, double check and make sure you have correctly completed the required steps. Note: Sample programs from the book are available on line at http://sce.uhcl.edu/yang/teaching/proJavaSecurityCode.html. A zip file is
available at the top of that page for you download all the programs. After you have properly configured your Java environment, perform the following tasks:
1.C Read the white paper “The Alarming Shift in Cybercrime: How Organized Attacks Now Target Your Wallet” (available by clicking this). Answer the following questions.
2.A (10 pts)
Using the Extended Euclidean Algorithm, find x and y such that 35
x + 11 y = 1. 2.C On page 252 of the Bishop book, a variation of man-in-the-middle attack in the context of public key cryptography is discussed, in which the hacker Eve successfully steals a session key transmitted from Alice to Bob. Examine the attack scenario and answer the following questions:
2.D The questions below are based on the 'signature chain' discussion on page 258 of the Bishop book. Suppose that X<<Y>> represents the certificate that X generated for the subject Y (X is the CA that issued the certificate). It is assumed that a subject always has the public key of its root CA, but not necessarily its immediate CA. (1) (5 pts) Suppose Y has generated a certificate for Z. How does Z's certificate look like? (2) (10 pts) (Continued from above) When Z sends its certificate to another entity R, how would R verify that certificate? Explain in detailed steps how the verification would work. Assumption: The only trusted public key that R has is X’s public key. (3) (10 pts) Suppose P’s certificate is created by O, and Q’s certificate is created by P. The only trusted public key that Q possesses is O’s public key. Show how cross-certification may be implemented between X and O such that, when Q receives Z’s certificate, Q will be able to verify that certificate. (4) (10 pts) (Continued from above) Show in detailed steps how Q would verify Z’s certificate (when cross-certification between X and O is in place).
Go to the Index
The purpose of this project is to build a client/server application which uses symmetric encryption to exchange a new key. The application will be used as a base for the later projects. The communication between the client and the server is to be implemented as sockets.
o Preliminary Report (to be handed in as hardcopies in the class) a. Use UML to define class diagrams for CLIENT, SERVER, and any other necessary classes. Clearly identify the attributes and methods defined in each of the classes, and the associations among the classes. b. For each of the methods, briefly explain its functionality and clearly indicate its parameters (if any) and returned data type. o Final Report (to be submitted electronically to yang@uhcl.edu, cc'ing the TA, as a single zip file) NOTE: You are required to give the TA a demo of your final project during his/her office hours. The demo shall be completed no later than three days after the project’s due date. The demo constitutes 30% of the project's total grade.
To be included in your submission: · A copy of the class diagram (possibly refined from the preliminary report). If no revisions were done, simply attach the original UML diagram. · The source programs implementing your design · A readme file explaining how to compile and run your source programs · Test the application by using three different plaintext messages. For each of the test cases, attach a screen output showing the following: a. the original message (m), b. the ciphertext sent by the CLIENT (ci), c. the decrypted message by the SERVER (dm), d. the ciphertext sent by the SERVER (cs), e. the decrypted message by the CLIENT (dmc), f. The result of the CLIENT's comparing m and dmc. Go to the Index
The purpose of this project is to create multi-level certificate paths (aka. Certificate chain), and use a sample program to verify the certificate paths.
1. Perform the following tasks to familiarize yourself with the basic tools and information with respect to multi-level certificate chaining. - Refer to http://java.sun.com/javase/6/docs/technotes/tools/windows/keytool.html to learn how to use keytool to create self-signed certificates. - Study the sample program, SignCertificate.java (in Chapter 6 of the Garms and Somerfield book, see http://sce.uhcl.edu/yang/teaching/proJavaSecurityCode/Chapter6/SignCertificate.java), which can be used to allow one entity to sign the certificate of another entity. -
A document explaining how to create
multi-level certificate paths is available as Creating Certificate Chain.doc. 2. Use keytool to create the following certificate chains. Use proper names and relevant information for each of them. - Create the certificates of the following certifying authorities: rootCA, CA1, and CA2. - Create certificates for the Server and the Client applications. - Use RSA when generating the key pairs for the server, the client, and the CAs. - CA1 and CA2 are certified by rootCA. - The Server (S) is certified by CA1; the Client (C) is certified by CA2. 3. To learn how to process multi-level certificate paths in your Java programs, unzip and run this sample application.
· Screen snapshots showing the content of the certificate paths for Server and Client, which you created in step 2 above. (This part should be submitted electronically to yang@uhcl.edu, cc'ing the TA, as a single zip file.) · Give the TA a demo during his/her office hours to show that you are able to run the sample application in step 3 above. The demo shall be completed no later than three days after the project’s due date. The demo constitutes 70% of this project's total grade. Go to the Index
The goal of this project is to
extend the FileEncryptorRSA program (pages
98-110 of the Garms book) into a two-user
application, incorporating certificates and digital signatures. The FileEncryptorRSA.java
file can
be found at http://sce.uhcl.edu/yang/teaching/proJavaSecurityCode/Chapter5/FileEncryptorRSA.java.
1.
Create
certificate chains 1.1. Use keytool to create the certificates of five certifying authorities, including rootCA, CA1, CA2, CA1a, and CA2a. Use proper names and relevant information for them. Also create certificates for the server and the client applications. Use RSA when generating the key pairs for the server, the client, and the CAs. 1.2. The server (S) is certified by CA1a, which is certified by CA1. 1.3. The client (C) is certified by CA2a, which is certified by CA2. 1.4. CA1 and CA2 are certified by rootCA. 2. The Server (i.e., the encryptor/sender) 2.1. The server should get its certificate as specified in step 1 above, and then sends the certificate to the client. 2.2. The server should get the client's public key from the client's certificate. 2.3. The server needs to verify the client's certificate. 2.4. If the verification succeeds, the server retrieves the client's public key from the certificate. Otherwise, an appropriate error message should be displayed. 2.5. The server should generate a 256-bit Blowfish session key (sk), which is to be used to encrypt a data file. Use this sample data file when testing your program. 2.6. Protection of the data file: 2.6.1. For the purpose of data and origin integrity, the server will generate a message authentication code (mac) based on the content of the data file. That is, the content of the data file is the source data used by the server to generate the mac. 2.6.2. The content of the data file should be encrypted using the session key (sk). The result is ciphertext representing the encrypted data file (edf). 2.7.
Protection of the
session key: 2.7.1.
The session key (sk) should be protected as follows: First, it
should be hashed, and then encrypted by the
server's private key (for origin integrity), resulting in a signature
for the session key (ssk). 2.7.2.
The session key
itself (sk) should be
encrypted by the client's public key
(for confidentiality), resulting in an encrypted
session key (esk). 2.8. The encrypted session key (esk), the signature for the session key (ssk), the mac for the data file, and the encrypted data file (edf) are then sent to the client. 3. The Client (i.e., the decryptor/receiver) 3.1. The client should get its own certificate by following steps as specified in step 1 above, and then sends the certificate to the server. 3.2. The client should get the server's certificate and verify it. 3.3. If the verification succeeds, the client retrieves the server's public key from the certificate. Otherwise, it displays an appropriate error message. 3.4. Once receiving the data sent from the server (step 2.8 above), the client should extract the encrypted session key (esk), the signature for the session key (ssk), the mac for the data file, and the encrypted data file (edf). 3.5. The client then uses the server's public key and its own private key to decrypt the encrypted session key (esk). The extracted session key (sk2) should be examined for its integrity. 3.6. If the data integrity of sk2 is not verified, the client should print an appropriate error message; otherwise, it uses sk2 to decrypt the encrypted data file. 3.7. The client then verifies the mac using the session key (ks) and the content of the data file. 3.8. If the verification succeeds, the client displays the content of the file on the screen. Otherwise, it prints an appropriate error message. 4. Testing Cases: Run your programs three times, once for each of the three test cases outlined below. 4.1. Generate proper keyPair respectively for the server and the client. Run the programs so the content of the file sent by the server is displayed on the client's screen. Use the sample data file mentioned above. 4.2. Produce an error in the generation of the client's certificate such that the verification performed by the server would fail. An example of such errors is that the client's certificate is not signed by a proper CA. 4.3. Produce an error in the generation of the server's certificate such that the verification performed by the client would fail. 5.
Preliminary Report (to be handed in
as hardcopies in the class) 5.1. Use UML to define class diagrams for SENDER, RECEIVER, and any other necessary classes. 5.2. Clearly identify the attributes and methods defined in each of the classes, and the associations among the classes. 5.3. For each of the methods, briefly explain its functionality and clearly indicate its parameters (if any) and returned data type. 6.
Final Report (Pack items 1
through 5 listed below
into a single zip file, and then send the zip file
electronically to yang@uhcl.edu, cc'ing the TA.) 6.1. The UML class diagrams (possibly revised after the preliminary report). 6.2. The source programs. 6.3. The data file. 6.4. Screen snapshots of using keytool to create the certificates. 6.5. Screen snapshots of running the programs (showing certificate verification, MAC verification, signature verification, data file decryption, etc). 6.6.
Arrange
time to give a demo for showing the testing cases to the TA. Note: You
will loose 30% of the project's grade if a demo is
not given by the end of the last
teaching day. Go to the Index |
Teaching Research o Grants Services o Centers
|