Security Engineering Coursework Handout - Google Sites

Security Engineering Coursework Handout

Dr. Ervin Ramollari May 11, 2017

Address: Rr. “Kodra e Diellit”, Selitë Tirana, Albania

Telephone: +355-(0)445 12345 Web site: http://www.unyt.edu.al

Coursework details Title Type Contribution Hand-out date Submission date Feedback date

Application for secure exchange and signing of documents Individual work 40% of the course final grade 11/05/2017 15/06/2017 29/06/2017

Description / Scenario As a developer and security engineer, you have been asked to analyze and develop a JCA application that supports secure document/file exchange and signing. Towards this aim, the following tasks are assigned. Task 1 (70%) The users of the secure application exchange and share with each other sensitive documents (such as commercial secrets, legal bindings, and so on) through unsecure public channels (email attachments, messengers, social networks etc.). Therefore, they require the application to help them ensure the confidentiality, authenticity, as well as integrity of the documents they exchange. Towards this goal, each of the users has his/her local copy of the application, which offers two basic features: • •

Encrypting/decrypting documents, so that no one else is able to read their contents Signing and verifying documents, so that each user can verify their authors and ensure they were not maliciously modified by someone else

As documents can be quite large, their encryption and decryption has to be as efficient as possible. Furthermore, as the number of documents exchanged daily is large, keys have to be refreshed frequently. Therefore, it is a requirement for encryption to be symmetric and keys to be changed whenever required. New symmetric keys are to be exchanged by means of insecure channels, thus it is a requirement to deploy public key cryptography. Public keys don’t need to be changed and users can meet face to face, so it is assumed that users know each other’s public keys. The application therefore should support: •

Generating a new symmetric key for document exchange and encrypting it with a contact’s public key. The user of the application inputs the contact’s username, and an encrypted session key file is created. This file can be then sent manually by email



•

•

attachment, etc. If there is no local public key for the particular contact, then the application asks user to input it in a suitable way. Accepting a received, encrypted session key file, in order to encrypt a document. The application should know the current user’s private key in order to obtain the symmetric key. The document can then be sent by email attachment, etc. Notice that the encrypted session key file is the input the application should accept to encrypt documents and not direct symmetric keys. Accepting an encrypted session key file, similarly as above, in order to decrypt a received document.

For the signing functionality, the application should support: • •

Signing a document with own private key. Verifying a received document (through insecure channels) with the public key of a provided contact’s username. If there is no key for the contact, it is input by the user.

As regards key management: •

Each user in the network should possess a private-public key pair. If the application is run for the first time, this key pair is generated for the user.

Task 2 (30%) In Task 1 it is assumed that users know each other’s public keys. This may not be practical or even possible, as users may not be able to meet face to face. In this task you will assume the existence of a trusted entity (call it Trent) that signs public keys of users along with their usernames. Everyone knows Trent’s public key (e.g. hard-coded in the application or provided by the user) in order to verify signatures on contacts’ public keys. Whenever a user joins the group for the first time, he/she chooses a unique username to attach to the public key and send to Trent for signing. Although Trent cannot verify who the person really is over the network, at least he can associate new usernames with new public keys. Therefore, in this task you are asked to extend the functionality of the application developed in Task 1, as well as develop a new application for Trent, which serves to sign public keys. The extended application should support: • •

Generating a request file to be sent to Trent for signing own public key with own username. This file is sent to Trent via insecure channels (email, etc.). Verifying a public key signed by Trent for a given username.

Trent’s application should support:



•

Signing a public key with associated username and producing an output file. If the username has already been taken, then Trent’s application gives an error. This file is to be sent back (manually) to the user via an insecure channel (e.g. email attachment), which he/she can forward to contacts to verify. Although the output file serves the role of a “digital certificate”, it does not have to comply with any standard.

For both Task 1 and Task 2, as a developer and security engineer, you will go through the analysis, design and implementation of the required application. As the above requirements are only outlined by the customer, you have to conduct an analysis, in order to fill in the missing details in the security protocol, steps, application user interface (either CLI or GUI), file formats, input formats, etc. You are free to use ciphers and signature algorithms of your own choice. Besides developing the program, you are asked to critically evaluate the security of the protocol and procedures supported by the application for document confidentiality, integrity and authenticity. Identify and discuss possible vulnerabilities and corresponding attacks, as well as what could have been done better to prevent against those anticipated attacks.

Submission Students are expected to submit: •

•

Short report documenting the results in Task 1 and 2. o It should consist of two parts. a) In the first part describe the analysis and high-level design of the application. Also, describe how the application is installed / used, possibly with sample screenshots. b) The second part is about the critical evaluation of the application security for both Tasks 1 and 2, as asked above. o The report must be submitted electronically through TurnitIn before the deadline. Program code, compressed in a zip file and sent by email to instructor’s address ([email protected]) before the deadline.

Evaluation Criteria •

Submissions will be assessed according to the following criteria: o Report structure, completeness and clarity. o Proper analysis of security requirements and critical security assessment of the application.



o Program functionality and completeness in implementation of the required features. Proper code documentation through comments is also taken into consideration.

Important Notice •

• •

This coursework is subject to the STUDENT HONOUR CODE. The University’s rules on academic dishonesty (e.g. cheating, plagiarism, submitting false information) will be strictly enforced. It is on the discretion of the instructor to ask the student to give a demonstration of the program or to come for a question session about the work she/he submitted. Late submissions are accepted with the following penalties: -20% if submitted the next day it is due, and -10% for each day late after that.

