Program Excercise – DAV C17 - Kau



Program exercise to encrypt/decrypt a message

Write a program in Java that can encrypt and decrypt a message. The programs should provide a graphical user interfaces (with SWING) where the user can select the action (de-/encrypt), provide a text file and select the crypto algorithm. The coding should follow secure coding principles (which means that design and documentation should be available) and you should also test your program (test code and documentation for the manual tests should be available).

Your program should encrypt with a symmetric algorithm. We expect that your program support at least AES and DES. The secret key should be put in a secure envelope (means encrypted with an asymmetric algorithm after your choice) and attached at the end of the message. Then this message should be stored in a file.

Concerning the asymmetric algorithm your program should be able to generate a key pair or use a stored key pair (DER encoded byte array (PKCS#1)). If the user selects to generate a key s/he should be able to save the key as DER encoded byte array (PKCS#1). Note that private key information is sensitive and should be password protected.

For decryption the process need to be reversed. This means you open the file, extract the secret key and decrypt the message. The message should than be displayed on the screen.

Note that in this exercise we want that you specify the used algorithms in the header prior to the message:

|Block name |Length |Values |

|Cipher |3 Byte |(AES,DES,RSA,DH) |

|Modus |3 Byte |(ECB , CBC, PCB, OFB, CFB) |

|Padding |12 Byte |(NoPadding, PKCS5Padding, PKCS1Padding) |

|Keylength in ASCII |4 Byte |(whatever works) |

|Initialization Vector |32 Byte |(whatever works) |

(Fill the header with blanks to achieve the required block length if necessary)

Example

|AES |CBC |PKCS5Padding |256 |IV |Message (as long as necessary) |

It is not necessary that you implement the cryptographic algorithms yourself – actually after the lectures you should be aware that this would be a bad idea anyhow. To be able to use already coded algorithms you need to use a Java Cryptographic Extension (JCE) provider. Sun provides a standard JCE provider (Sun JCE) with the JDK 1.4.x. and 1.5.x. However, the 1.4.x JCE implementation does not support the RSA algorithm. (It is possible to solve the exercise with the Sun JCE by using Diffie Hellman Key Exchange for the asymmetric encryption.) For those of you who want to use RSA (which is probably easier) we suggest that you use the 1.5.x JDK.

If you want to use the IAIK provider in the code you need to enforce that the IAIK provider is used (otherwise the first provider which supports the algorithms – in our case Sun will be used). This is done at the initialization of the algorithms. The example assumes you want to initialize the either SHA or DES but this works for all algorithms if you use “IAIK”:

MessageDigest sha = MessageDigest.getInstance("SHA", "IAIK");

Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding", "IAIK");

Due to American export restrictions in most Java implementations the maximum key length is limited. So don’t be surprised if the compiler complains. It would be possible to circumvent these limits by editing the policy file – but this is not possible for you at the university (if you program at home make certain that you test at the university as this is the target environment).

Note that there are other ways to solve the exercise and you are free to choose the method that fits you. If you encounter problems be sure that you read the documentation from Sun and from IAIK.

Readiness for Assurance Evaluation

You have to provide documentation under the assumption that your program becomes the Target of Evaluation (TOE) for a Common Criteria (CC) assurance evaluation on EAL 2. The lists of assurance components necessary for this level are listed in the CC.

Security functions the Security Target (ST) contains are:

• Symmetric Encryption

• Symmetric Decryption

• Asymmetric Encryption

• Asymmetric Decryption

• Key Generation

Examination

You will develop the program in pairs (two people). We expect your main class to be named “ExerciseYEAR_YOURNAMES” (i.e. Exercise2005_AndersonZuccato).

In the beginning you have to produce a design which will be inspected in a pair review process (you have to exchange the printed design document with another student group and you have to book a review meeting). Note that this is a time consuming process so sign up in time to able to finish the exercise before the course ends. Based on this design you have to produce the program.

This program will be tested by a teacher at a computer room. You have to book a time with the teacher. For this meeting you have to bring with you an A4 binder containing your printed code, a floppy disk/CD with the code and the documentation. At the meeting your team and another team will exchange your binders for review.

After you and the other group have finished the individual reviews according to the provided checklist you can book a review meeting with the teacher. During this meeting each of you has to supply his/her individual checklist (there are two checklists for each reviewed code) and the checklist will be discussed.

Resources

Java documentation -

Java Security -

Sun JCE -

IAIK JCE -

Design Principles:

PS: There is a Java Tutorial how to sign a message which can give you a clue how to use cryptographic algorithms with Java

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download