SymmetricKeyExchange
This report is written with the purpose of explaining how I implemented Key Exchange with Symmetric Cryptography Protocole for my term project in CENG489 Introduction to Computer Security. The main concept of this project is contributing to an ongoing open source project that is Ad Hoc Computing (event-driven component) Model. The protocole facilitates the use of 2 separate secret keys that are shared between the Trusted 3rd party, which we call Trent for convinience, and our users Alice and Bob to eventually create and securely distribute a session key to the users.
The topic of my term project is the implementation of Key Exchange with Symmetric Cryptography from Bruce Schneier's Applied cryptography: protocols, algorithms, and source code in C. Throughout the term, I analysed the design methods used in the project and considered a couple different approaches for my implementation. The protocol facilitates the use of 2 separate secret keys that are shared between the Trusted 3rd party, Trent, and our users Alice and Bob to eventually create and securely distribute a session key to the users. The protocol, however, does not ask the question how the secret keys are distributed. Therefore my main focus was implementing the key exchange part and making sure that the established channel works correctly and efficiently between Alice and Bob.
Here I'd like to explain some vocabulary that will be used throughout the report.
-
Node: An object representation of a user like Alice, Bob and Trent. It is a part of the event-triggered model therefore there are certain reactions a node gives to a certain type of event. These reactions are implemented through event handlers.\
-
Secret Key: There are many different types of keys in the world of computer security. This specific type we are using represents a personal key of a user that is either generated by themselves or a trusted 3rd party. The users are responsible for keeping their secret keys secret and secure.\
-
Session Key: The other type of key this protocol uses. This one is a shared key between the parties who wish to communicate through a channel in a secure manner. It is used to encrypt and decrypt the messages that are sent back and forth.\
-
Event Handlers: The methods that define the actions to be taken when a certain trigger occurs. One example I used in my implementation is on_message_from_bottom().\
-
Triggers: The signals that are delivered to the target nodes. Based on where the triggers are coming from (top, bottom, peer) the related on_message_from method is run.\
The overview of my implementation is as follows. I created separate Node implementations for each party using the ComponentModel class implementation and connected the necessary pairs to each other with Channel class implementation. Each Node has its necessary event handlers implemented. The secret keys as well as the session key of the users are URL-safe base64-encoded 32-byte keys that are generated with Fernet.generate_key() method.
Below you can find the plot of the internal system. If necessary Trent can also be connected to Bob but since the protocol does not require such connection I left it as it is.
{#fig:topo width="450px"}
Trent's only role in this protocol is providing a session key to Alice and Bob in a secure way. Trent shares a pair of secret keys with Alice and Bob individually which he uses to encrypt the session key he generates for them. After he encrypts both copies of the session key, he sends them both to Alice. The safe delivery of Bob's copy of the session key is Alice's responsibility.
The main two roles of Alice in this protocol is initiating the communication and being a bridge between Trent and Bob. Alice starts the protocol when she asks Trent for a session key. After she receives the encrypted session key pair from Trent, she decrypts her copy with the secret key she shares with Trent. She cannot decrypt Bob's copy since it is encrypted with Bob's secret key and due to the nature of encryption it is infeasible. She sends Bob his copy of the key and waits for Bob's encrypted message. When she receives Bob's message, this time she decrypts it with the session key she obtained from Trent and sends her encrypted message to Bob.
Bob's job in this protocol is to wait for Alice to deliver his copy of the session key. When Bob receives his copy of the encrypted session key from Alice he decrypts it with the secret key he shares with Trent and that's the moment Alice and Bob establishes a way of secure communication. Now that they share a session key they can send and receive encrypted messages to each other in a secure fashion.
The Channel class implementation included in AHC has some issues about event types and event triggers that I couldn't resolve. The Event object has to be created with the Event type message from bottom (MFRB) regardless of the direction message is intended to be sent. If it is created as any other type the corresponding Event handler does not get triggered.
To fix this, I tried writing my own implementation of Channel however I couldn't make it work as I desire. In the end I went ahead with the existing Channel implementation by just adjusting my Event creations and Event handlers accordingly.