Learning Objectives:

On completing this assignment you will gain sufficient expertise in the following skills:

- Understanding and developing security protocols.
- Reading and understanding standard documents for security such as RFCs.1 Learning Objectives:

On completing this assignment you will gain sufficient expertise in the following skills:
- Understanding and developing security protocols.
- Reading and understanding standard documents for security such as RFCs.

Project Scope

We will implement a simplified version of SSL/TLS (miniSSL) and a sim-plified application-layer protocol (miniGet) in this project. The goal is to get a better understanding of the SSL/TLS protocols.

miniSSL and miniGET

An miniSSL is a barebone version of Secure Socket Layer (SSL). An miniSSL includes a simplified SSL handshake, which leads for user authentication.

A session key need to be distributed securely for data encryption and in- tegrity check (by HMAC) in miniGet later. You are expected to use RSA and implement the client authentication (advanced requirement: mutual authentication).

An miniGET is simply a GET operation sent from client to server after the miniSSL hand-shake. The server sends the requested file, encrypted and HMACed with the session key. The session key for data encryption and integrity check was established during the miniSSL handshake. We always use the off-the-shelf cryptographic algorithms, AES 128-bit encryption and SHA1-based HMAC, for data encryption and integrity check. Once the file is delivered, both client and server would terminate the session without any further notifications.

Protocol flow

The simplified protocol you are going to implement is shown as follows. C denotes as client, S denotes as server. We have an miniSSL-CA.

We start with the miniSSL handshake. Note that we group the different message types of SSL/TLS in new, custom ones. In the following, the comma operator indicates the border between message fields, and the | operator indicates concatenation of two (bit) strings.

1. C chooses a nonce nc of length 28 bytes. It chooses the cipher suite to be 128-bit AES encryption and SHA1 as the HMAC function. It is denoted as a string AES-HMAC. The type of the first message is ClientInit. C sends this to S:

C → S : ClientInit, nc, AES-HMAC

2. Upon receiving this message, S chooses a random nonce ns of length 28 bytes. It acknowledges the client's cipher choice and also sends a certificate. It can add an optional request for the client to authenticate with a certificate by sending the CertRequest string:
S → C : ServerInit, ns, AES-HMAC, Certs [, CertReq]

3. C verifies that the unexpired server certificate was issued by the miniSSL- CA (checking the signature, with the certificates in its root store) and whether the common name matches with the expected one. It extracts S's public key. It generates a pre-master secret p as a random value with 46 bytes in length. From this, it derives two session keys k1 and k2 as k1=HMAC-SHA1(p, nc|ns|enc) and k2=HMAC-SHA1(p, nc|ns|mac), with enc,mac being the binary strings 00000000 and 11111111. Finally, it computes an HMAC over all messages up to this point in the following way:

mc=HMAC-SHA1(k2,ClientInit- nc-AES-HMAC-ServerInit-ns-Certs
[|CertReq])
C sends the following to the server (note the optional client certificate).
E means encryption with the respective public key:
C → S : ClientKex, ES (p), mc[, CertC, SigC(ns|ES(p))]
SigC (ns) is C's signature on the server's nonce.

4. The server, upon receiving this message, also verifies that CertC was issued by miniSSL-CA (see above) and that the certificate is not ex- pired. There is no need to check the Common Name. It computes k1, k2 and verifies that mc has the correct value. It computes an HMAC over all messages up to this point in the following way:
ms=HMAC-SHA1(k2,ClientKex-ES (p)|mc|[, CertC]).
It sends this to C:
S → C : ms

5. C verifies ms. The handshake is complete. C will now initiate miniGET. This protocol uses k1 for encryption and k2 for HMACs.

Compulsory Requirements
The following requirements are compulsory for your program.

- Your implementation must allow the protocol to run between client and server on different hosts, with different IP addresses. Therefore, TCP/IP sockets should be specified readily in your program.

- The miniSSL handshake should be implemented with the establishments of two session keys, one for AES data encryption, the other for HMAC integrity check.

- Your program should be able to accommodate multiple sessions, i.e. it must be possible to have two clients communicating with one server at the same time.

- Client and server must record the state of the current handshake, i.e., session management. All cryptographic information in a given protocol (nonces, keys, etc.) must be stored internally! There is an immediate effect that client and server cannot be confused when a third party starts sending them well-formed messages - they should be able to reject these as the state information is incorrect.

- Your client must verify that the server certificate has been issued from the minissl CA, carries the expected Common Name (it is in the cer- tificate), and is not expired. No other checks are necessary. It must use the public key found in the server certificate.

- Your server must support two modes: Simple and ClientAuth. In Simple, the client does not need to authenticate to the server. In ClientAuth, the server verifies that the client presents a valid certificate from the minissl CA and this certificate is not expired.

- After the handshake, the client must download the text file payload.txt from the server. Generate this file yourself. This messages must be encrypted with the session key, with the respective HMAC. In Clien- tAuth mode, the server could only process the received message if the client has presented the correct certificate. You have liberty of the design and implementations on your own session termination sig- nals in miniGet . We suggest you implement a simple GET and have server and client(s) simply terminate the connection when the file is successfully received.

- By checking the SHA-1 checksum, you must prove that both client and server have identical copies of payload.txt.

- If either the server or client presents an invalid certificate, the other side must terminate the connection (i.e., close the socket). There are rogue certificates in the attached project package. Use them to verify that you do not accidentally accept the invalid certificates.

- Your program must handle all the exceptions well without crashing if the packet is misconfigured. In addition, client and server must terminate the session successfully if it happened.

l implement a simplified version of SSL/TLS (miniSSL) and a simplified application-layer protocol (miniGet) in this project. The goal is to get a better understanding of the SSL/TLS protocols.

Attachment:- mini-ssl.pdf