T. Andrew Yang

Email: yang@uhcl.edu

Web page : http://sce.uhcl.edu/yang/

Tel.: (281) 283-3835

last updated:

 

1/16/2010

 

CSCI 5233 Computer Security & Integrity


 

Assignments

  • Assignment 1

1.A (10 pts) Visit the class discussion group. Throughout this class, you shall regularly visit the discussion group to find recent announcements, reminders, and discussions. Send a brief message to the discussion group to introduce yourself (including your full name) and one item you most desire to learn about computer security.

1.B  Java Cryptography
If you have not done so, you may want to download the most recent Java Development Kit from http://java.sun.com/j2se/ (for example, JDK 6.0).

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.      (15 pts) Test the FileEncryptor.java program (from chapter 4 of the Garms and Somerfield book). Add a printline statement at the beginning of the program to print your name as part of the program's output. Run the program using sample data of your choice. Hand in the screen output from the program.

2.      (15 pts) Test the FileEncryptorRSA.java program (from chapter 5 of the Garms and Somerfield book). Add a printline statement at the beginning of the program to print your name as part of the program's output. Run the program using sample data of your choice. Hand in the screen output from the program.

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.

1.      (10 pts) Explain why it is said in the paper “The years 1999-2001 were banner years for hackers.” Do you agree with this statement? Justify your answer.

2.      (20 pts) In the white paper it is said, “What was once the pastime of a computer geek on an ego trip has become an estimated $100 billion worldwide cash cow for professional criminals.” The figure, ‘$100 billion’, however was not supported by any cited reference. Conduct a literature search (whether on line or using resources in the UHCL library) to confirm that figure. Clearly indicate the sources of your data.

3.      (20 pts) A major drawback of the white paper is its lack of cited references, meaning that facts and statements are not supported by valid source(s) of information. Information related to proper citing can be found at http://sce.uhcl.edu/yang/citing.htm. Carefully read the white paper and identify at least three statements in the paper where proper citing should have been done. For the sake of comparison, check out this paper, which deals with similar issues as the white paper (but with proper citing).

 

Go to the Index


  • Assignment 2

2.A (10 pts) Using the Extended Euclidean Algorithm, find x and y such that 35 x + 11 y = 1.

2.B  (10 pts) Solve 11x mod 30 = 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:

1.      (5 pts) What is the source of the problem? That is, why would the attack succeed?

2.      (10 pts) Explain how the problem may be mitigated? Justify your answer.

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



Projects

  • Project 1

o    Project description

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    Requirements

1.      The client application will take a plaintext message (m) from the user, encrypt the message using a 448-bit Blowfish key (assuming an existing key, k), and then send the ciphertext over the socket to the server. NOTE: The key may be generated by the client program, stored into a file, and then shared with the server program.

2.      The server will read the ciphertext from the socket, get the secret key k from the user, and then decrypt the ciphertext. The decrypted message (dm) should be printed as part of the screen output.

3.      The server then generates a new random key (nk), encrypts dm by using nk, encrypts nk by using the existing symmetric key (k), and then sends the encrypted new key and the encrypted dm over to the client.

4.      Once the client receives the encrypted dm and the encrypted nk, it first decrypts the encrypted nk to get the new symmetric key, and then uses the new key to decrypt the encrypted dm. The outcome from the decryption of dm should be compared against the original plaintext message (m), which was originally sent over to the server. Print appropriate message depending on the result of the comparison.

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

  • Project 2 (Certificate Chaining)

o    Project description

The purpose of this project is to create multi-level certificate paths (aka. certificate chains), and use a sample program to verify the certificate paths.

o    Requirements

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, which can be used to allow one entity to sign the certificate of another entity. The program is discussed in Chapter 6 of the Garms and Somerfield book; see http://sce.cl.uh.edu/yang/teaching/proJavaSecurityCode/Chapter6/SignCertificate.java for the source codes.

-          A document explaining how to create multi-level certificate paths is available as Creating Certificate Chain.doc. Practice the examples in that document to learn how to create multi-level certificate paths.

 

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.

o    To be included in your submission:

·         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

  • Project 3

o    Project description

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.

o    Requirements

1.      Certificate Chaining:

·         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 (S), the client (C), and all the CAs.

·         The server is certified by CA1a, which is certified by CA1.

·         The client is certified by CA2a, which is certified by CA2. 

·         CA1 and CA2 are certified by rootCA; rootCA’s certificate is self-signed.

2.      The Server (i.e., the encryptor/sender)

1)       The server should get its certificate from rootCA its CA, and then sends the certificate to the client.

2)       The server should get the client's public key from the client's certificate.

3)       The server needs to verify the client's certificate.

4)       If the verification succeeds, the server retrieves the client's public key from the certificate. Otherwise, an appropriate error message should be displayed.

5)       The server should generate a 168-bit Triple DES session key (sk), which is to be used to encrypt a data file. Use this sample data file when testing your program.

6)       For the purpose of data and origin integrity, the server will generate a digital signature (ds) based on the content of the data file. That is, the content of the data file is the message used by the server to generate the digital signature.

7)       A signature should be generated out of the session key (sk). That is, it should be hashed first and then encrypted by the server's private key (for origin integrity).  The session key itself (sk) will then be encrypted by the client's public key (for confidentiality), resulting in an encrypted session key (esk).

8)       The encrypted session key (esk), the digital signature (ds), and the encrypted data file (edf) are then sent to the client.

3.      The Client (i.e., the decryptor/receiver)

1)       The client should get its own certificate from the rootCA its CA, and then sends the certificate to the server.

2)       The client should get the server's certificate and verify it.

3)       If the verification succeeds, the client retrieves the server's public key from the certificate. Otherwise, it displays an appropriate error message.

4)       Once receiving the data sent from the server (step 8 above), the client should first extract the encrypted session key (esk), the digital signature (ds), and the encrypted data file (edf).

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, by using the attached MAC.

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.

7)       The client then verifies the digital signature (ds) using the server's public key and the content of the data file.

8)       If the verification succeeds, the client will display the content of the file on the screen. Otherwise, it prints an appropriate error message.

1.      Testing Cases: Arrange three test cases as outlined below.

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.

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.

3)      Produce an error in the generation of the server's certificate such that the verification performed by the client would fail.

Part A: Preliminary Report (to be handed in as hardcopies in the class)

·         Use UML to define class diagrams for SENDER, RECEIVER, and any other necessary classes.

·         Clearly identify the attributes and methods defined in each of the classes, and the associations among the classes.

·         For each of the methods, briefly explain its functionality and clearly indicate its parameters (if any) and returned data type.

·         Explain what security features are built into this application. For each of the features, explain how it is achieved in the application.

Part B: Final Report (Pack items 1 through 4 listed below into a single zip file, and then send the zip file electronically to yang@uhcl.edu, cc'ing the TA.)

a)      The source programs.

b)      The data file.

c)      Screen snapshots of using keytool to create the certificates.

d)      Screen snapshots of running the programs (showing certificate verification, MAC verification, signature verification, data file decryption, etc).

e)      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

  Main Page

  Biography

  Teaching

o    Office hours

   Research

o    Active projects

o    Research interest

o    Publications

o    Presentations

o    Grants

   Services

o    Student support

o    Committees

o    Curricular development

o    Centers

    Other Links