Assignment #2

Information Security

Rules:
1. You must submit the docx file of final version of your report with the naming
convention as:

✔ RollNumber-FullName-Report-A02.docx
✔ RollNumber-FullName-ChatSystem.zip
✔ RollNumber-FullName-TestReport-A02.docx
2. All snapshots added to the report must be of full screen including task bar and
status bar etc.
Failing to comply with this will result in marks deduction.
3. You can use any programming language for this assignment.
4. Maximum Marks = 300

Question 1:
In this question you will gain some hands-on experience of public key infrastructure
and public key cryptography. You need to complete two SEED Labs for this
assignment:

1. Public-Key Infrastructure Lab

https://seedsecuritylabs.org/Labs_20.04/Crypto/Crypto_PKI/

2. RSA Encryption and Signature Lab

https://seedsecuritylabs.org/Labs_20.04/Crypto/Crypto_RSA/

The detailed tasks are under the Tasks [PDF] link when you visit the links above.
Complete the implementation and submit a detailed report, including screenshots, of all
the steps involved.
Pre-requisite tasks: Container setup and DNS setup (with correct name) (5 marks)
Task 1: Becoming a certificate authority (5 marks)
Task 2: Generating a certificate request for your web server (5 marks)
Task 3: Generating a certificate for your server (5 marks)
Task 4: Deploying Certificate in an Apache-Based HTTPS Website (10 marks)
Task 5: Launching a Man-in-the-Middle attack (15 marks)
Task 6: Launching a Man-in-the-Middle attack with a compromised CA. (10 marks)

Section 2: Lab 2 (RSA Encryption and Signature)

Pre-requisite tasks: Implement the BigNum example and compile and
execute it. (5 marks)

Task 1: Deriving the private key (5 marks)

Task 2: Encrypting a message (5 marks)
Task 3: Decrypting a message (5 marks)
Task 4: Signing a message (5 marks)
Task 5: Verifying a signature (5 marks)
Task 6: Manually verifying an X.509 certificate (15 marks)

Total: 100 marks.

All tasks should be described in your own words and should display your
understanding of what each step is doing. Each sub-task (not listed here, specified in
the lab description) carries marks. All sub-tasks carry equal marks.
Question 2:
Secure Chat System with Registration, Login, and
Encrypted Communication
Introduction:
This manual outlines the process for designing and implementing a secure chat
system. The system should allow clients to register and log in to a server, where they
can engage in an encrypted chat system. The project leverages key cryptographic
techniques such as password hashing and encryption for secure communication,
based on cryptographic fundamentals.

Objectives:
The secure chat system should:

● Allow users to register with a unique username and password.

● Authenticate users with their credentials during login.

● Encrypt communication between the client and server using encryption techniques.

● Store user credentials securely (hashed passwords) in a file.

● Ensure confidentiality of messages during the chat.

Key Components:
User Registration: Users should be able to create accounts with a unique username
and password.

User Login: Users should be authenticated using the credentials provided

during registration.
Encrypted Chat: After login, the server and client should communicate through
encrypted messages.

Credential Storage: User credentials (username and hashed password) should be

securely stored in a file.

Detailed Design and Functionality

Registration Process:

Pre-Phase

A secret key will be exchanged between the server and the client using the Diffie
Hellman Key Exchange protocol. Following are the requirements:

● Keep public parameters fixed for your application i.e., (𝑃, α). Choose any
valid values of your own choice.
● Use random values as secret keys and compute mutual shared secret key
𝐾𝑎𝑏 .

User Prompt at client side:

The client prompts the user to enter:

● A valid email address.

● A unique username.

● A password.

● Encrypt user email address, username, and password using symmetric key
encryption algorithm AES-128 bit-CBC mode and use key 𝐾𝑎𝑏 already
exchanged between server and client.

Server End steps: Username Uniqueness Check and Database update (creds.txt)

At server end, when a user registration request received, decrypt the message using
𝐾𝑎𝑏 , and verify the uniqueness of user by username/user email address.

● Before registering a new user, the system will check whether the entered
username already exists in the creds.txt file.
● If the username is unique, the registration will proceed. Otherwise, the
system will prompt the user to choose another username.
● If username is unique, hash the password.

● Password Hashing: A random salt is generated for each user (salt should
be at least 32 bits in length). The password is combined with the salt and then
hashed using SHA-256 algorithm. Hashing ensures that the password is not
 stored in plaintext. Hashing adds a layer of security even if the credential file is
compromised.
● Storing Credentials: If the username is unique, the server will store the
following details in the creds.txt file:
● Email address.

● Username.

● The SHA-256 hashed password.

● Salt value

Each record in the file will look something like this:

Security Measure:

● By using Diffie Hellman key exchange mechanism, confidentiality

of secret keys is achieved.
● By using SHA-256 hashing on passwords, the system avoids storing
passwords in plaintext, thus reducing the risk of password theft in case the
credential file is compromised.
● Salting prevents attackers from using precomputed hash databases (rainbow
tables) to crack passwords, as even the same password will have different
hashes due to unique salts.

Login Process:
User Prompt: The client should prompt the user to log in by entering their
username and password.

Secret Key Exchange Phase: After user clicks/selects login phase, use Diffie Hellman
key exchange protocol by using same public parameters (𝑃, α) as used in registration
phase, however, use different random secret keys and compute mutual key 𝐾𝑎𝑏.

Once, the user enters username and password, encrypt both using AES and 𝐾𝑎𝑏. Send
this ciphertext to server for login and verification.
Password Verification at Server end:

● Server will decrypt the message using 𝐾𝑎𝑏.

●Retrieves the stored SHA-256 hashed password associated with the provided
username from the creds.txt file along with salt value.
● The user entered password is hashed using SHA-256 using same salt value
as used during registration time.
● The system then compares the hashed version of the entered password to the
stored hash.

Access Control:

● If the hashes match, the login is successful, and the client is granted
access to the chat system.
● If the login fails (either the username is not found or the password hash
does not match), the client is asked to try again and use the same mutual key
𝐾𝑎𝑏 for next try. Optionally you can add timer here for key freshness like if user
did not try login within 5 minutes, new key will be exchanged etc.

Chat system with encryption:

Encryption:

● After successful login, the client and server will use the given encryption
algorithms to securely exchange messages. Before that, a new key will be
exchanged between client and server using Diffie Hellman for message
encryption.

● Use following criteria for key calculation at both client and server end:

o Use Diffie Hellman key exchange algorithm for mutual key calculation
(for example = 19)
o Append the shared key with username you used during registration
(for example john_doe19).

o Use this shared key john_doe19 for message encryption.

● Once the key exchange is complete, both the client and server will use the
agreed-upon symmetric key (AES-128 bit CBC mode) for encryption and
decryption of messages.
 ● The client will send encrypted messages to the server, which will decrypt
them, process them, and reply with its own encrypted message.
Message Flow:

● After the key exchange, the server will prompt the user to start typing
messages.

● The messages will be encrypted using the AES algorithm.

● Both client and server will exchange encrypted messages until one side
terminates the session by typing bye.
Key Points:

● The communication between the server and client should be encrypted

using encryption, where both the client and server use the encryption.
● Diffie Hellman should be used for the secure exchange of encryption keys
between the client and the server.

Credential Storage and Key Management:

File Storage:

● The server should store user credentials (username and SHA-256 hashed
password along with salt value) in a secure file.

● Each entry should consist of the username, corresponding hashed

password, and salt value.
Storing Secure Passwords:

● When a user registers, their password should never be stored in plaintext.

● SHA-256 hashing should be used to generate a secure hash for the password.
Retrieving Credentials:

● During the login process, the server should read from the credential file to
retrieve and verify the stored hashed password.

Security Consideration: Access to the credential file should be restricted to the

server to prevent unauthorized access. Passwords should never be stored or
transmitted in plaintext. Optionally you can add security on this creds.txt file like
encrypting this file etc.

System Architecture and Workflow:

Client-Server Model:

● The system should use a client-server model where the client connects to a
central server to perform registration, login, and chat.
● The server should manage user accounts, verify credentials, and facilitate
encrypted communication between server and client.
Registration Workflow:

● The client sends a register request to the server.

● The server prompts the client for an email, username and password.

● Mutual key is exchanged between the client and the server.

● User registration parameters are encrypted using shared key.

● The server decrypts the registration request parameters.

● The server should verify that the username is unique.

● The server hashes the password along with salt value using SHA-256 and
stores it along with the username and salt value in a secure file (creds.txt).

Login Workflow:

● The client sends a login request to the server.

● The server prompts the client for a username and password.

● Diffie Hellman key exchange is executed for mutual key.

● User enters username and password, sends encrypted login request to

server.

● Server decrypts login request parameters.

 ● The server retrieves the stored SHA-256 hash along with salt value for the
username and verifies the password.

● If the login is successful, again Diffie Hellman key exchange will be used for
message exchanges and the client enters the secure chat session.
Chat Workflow:

● After login, the client and server exchange the key and then compute
mutual key by appending username and computed mutual key and starts the
encrypted messages exchange.
● The client encrypts each message using AES-128 encryption algorithm
before sending it, and the server decrypts it upon receiving using same
algorithm.

The server can reply with encrypted message using same key and AES-128, which
the client decrypts using the same encryption method.

Security Considerations
Password Security:

● SHA-256 Hashing:

o Passwords should never be stored or transmitted in plaintext.

o SHA-256 should be used to securely hash passwords before storage,

ensuring that even if the password file is compromised, the plaintext
passwords remain secure.

Confidentiality:

Encrypted Messaging:

● Encryption should ensure that messages are kept confidential and cannot
be read by unauthorized parties.

● Diffie Hellman ensures that encryption keys are securely exchanged,

adding another layer of security to the communication.
File Security:
Secure File Management:

● The credential file containing SHA-256 hashed passwords should have

restricted access permissions to prevent unauthorized users from accessing
stored credentials.

Additionally and optionally, creds.txt file can be encrypted for more security.

Testing and Evaluation:

Functional Testing
Registration
Testing:

● Verify that new users can register with a unique username and password.
(25 marks)

● Ensure that the password is hashed correctly using SHA-256 and stored
securely in the credential file along with salt value. (25 marks)

Login Testing:

● Test successful logins with valid credentials. (25 marks)

● Test failed logins with incorrect credentials and ensure proper error
messages are displayed. (25 marks)

Security Testing

Hash Verification:

● Verify that identical passwords generate different hashes due to random

salting with SHA-256. (25 marks)

● Verify user passwords are verified during login phase. (25 marks)

Encryption Testing:

● Capture the communication between the client and server using network
analysis tools (e.g., Wireshark) and verify that all messages are encrypted in
both Registration and Login phases including all messages exchanged.
 (50 marks)

Conclusion
This secure chat system should provide robust user authentication and secure
communication between the client and server. With the implementation of SHA-256
for hashing passwords, AES for message encryption, and Diffie Hellman for key
exchange, this system ensures a high level of security. Proper credential storage and
encrypted messaging should protect both user data and communication security,
making this chat system a practical application of secure design principles.

Deliverables
1. A complete report explaining the code and your understanding.

2. All the code in a single zip.

3. A detailed test report showing functional and security testing results, including the
use of Wireshark to verify that all communication is encrypted.