salemohamedo / securechannel Goto Github PK

Threat Model: An attacker could attempt a MITM attack, trying to eavesdrop over the channel and/or read and modify messages. Moreover, an attacker might try to take advantage of a lack of forward secrecy and decipher previously sent messages. This attacker could also try and carry out replay attacks which could potentially compromise the order in which messages have been sent. 


The SecureChannel class would be initialized with input and output streams, a PRGen and a serverkey. Passing these parameters will call the constructor that implements DHE RSA handshake, and afterwards encrypted messages are sent via send/recieve message. This class attempts to implement the DHE_RSA protocol as seen in lecture 9. The DH handshake is handled for both parties in the SecureChannel constructor. Both client and server start off by sending eachother random nonces client_random and server_random. A keyExchange object is created that is given the SecureChannel's rand prgen in order to calculate the a,b values used in DH. Each party then sends the other g^(a) mod p or g^(b) mod p, which is then processed to determine a pre_master_secret for both sides. Note this scheme provides forward secrecy as a,b are different everytime a new handshake or communication line is opened. This pre_master_secret along with the client and server randoms are used to generate a master secret which is subsequently used to create instances of AuthEncryptor and AuthDecryptor for the purpose of sending encrypted messages. The AuthEncryptor and Decryptor provide confidentiality and integrity for the messages (attacker cannot decrypt the messages unless they have the same master_key and nonce). Moreover authentication is provided in the handshake by having the server sign their outmessage with their private key, and having the client verify the signature. Note, this model assumes that the server has already authenticated the client, perhaps via a password. The final task of the constructor(and the handshake by extension) is to confirm that the client and server have agreed on the same master key. This is done by hashing the message history and adding this to a string as input for a prf seeded with the master key. Client and server both send the outputs of the prf, reconstructing what the output should be, and confirming that the two are the same. 

To defend against replay and MITM attacks, that could result in the reordering of messages, a unique nonce is concatenated to each message. This nonce also detects any threats to the integrity of the message, along with the MAC in the AuthEncryptor/Decryptor. The PRGen that produces the nonce has been seeded with the master_key that both client and server have. Thus, each time a client or server sends a message, attached with a unique nonce, the receiving party will also produce the expected nonce (in receive message). If the two nonces are the same, then the messages have not been reordered, otherwise the receiving party returns null.