|
T. Andrew Yang
|
last updated: 4/7/2011 |
|||
|
CSCI/CINF 4233 Computer
Security
1.A (10 pts) Visit the class discussion group (http://groups.google.com/group/csci5233spring2011?hl=en). Post
a message with your full name as the subject line. In your post, briefly
introduce yourself (including your full name) and one item you most desire to
learn in this class. Throughout this class, you shall regularly participate
at the discussion group to find recent announcements, reminders, and
discussions.
1.B Java Cryptography 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 to download all the sample 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. Note: Replace all occurrences of the
cipher ‘PBEWithSHAAndTwofish’ with
‘PBEWithMD5AndDES’ in the
source 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. Note: Replace all occurrences of the
cipher ‘PBEWithSHAAndTwofish’ with
‘PBEWithMD5AndDES’ in the
source 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 2.A (10 pts) Using the Extended Euclidean Algorithm, find x and
y such that 35 x + 13 y = 1. 2.B
(10 pts) Solve 13x 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, what vulnerability makes the attack possible? 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 o
Project description All
the programming projects for this class involve client/server communications
using sockets. The purpose of this project is for you to become familiar with
Java Sockets programming by running a sample application. o
Requirements Run
the KeyAgreement application in
Chapter 5 of the Java Security book. The application consists of two Java
programs (KeyAgreementClient.java and KeyAgreementServer.java). 1.
Compile and run
both programs (as two separate processes). 2.
In your demo,
show the TA how those programs interact with each other. Figure 1 shows a
sample execution of the programs.
Figure 1. Demo of the KeyAgreeement
application (original) 3.
Revise the
KeyAgreementServer.java program, so each time the server program receives a
NewLine character sent from the client, it will display a message like
‘Line n from the client: <the mesg>’. See Figure 2 for a
sample screen snapshot of a revised program.
Figure 2. Demo of the KeyAgreeement
application (with revised KeyAgreementServer.java) 4.
In your demo,
show the TA how those programs interact with each other. 5.
Zip the revised
KeyAgreementServer program and the
screen snapshot of running the revised application into a single zip file.
Send the zip file electronically to yang@uhcl.edu, cc'ing the TA. Go to the Index 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. 6.
The client
application will take a plaintext message (m) from the user, encrypt
the message using a TripleDES 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. 7. 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. 8. The server then generates a new TripleDES 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. 9. 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
before the project’s due date. The demo constitutes 30% of the
project's total grade. To
be included in your submission:
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 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 before the
project’s due date. The demo constitutes 70% of this project's
total grade. Go to the Index 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’s certificate should be
signed by its CA, as specified above (certificate chaining). Then, the server
can either send its certificate to the client or save it in a keystore, which
is then shared with 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’s certificate should be
signed by its CA, as specified above (certificate chaining). Then, the client
can either send its certificate to the server or save it in a keystore, which
is then shared with 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 lose 30% of the project's grade if a
demo is not given before the project’s due date. Go to the Index |
||||
