This was a project that we worked on for ECE 296: HP Nomadic Computing Project, a research program sponsored by Hewlett-Packard. Under the guidance of Martin Roth, and ECE graduate student, we created a Java peer-to-peer chat client that implements the Rijndael Algorithm of encryption. We chose this method because it is the current Advanced Encryption Standard (AES) chosen by the National Institute of Standards and Technology (NIST), and it is fast enough to run efficiently with limited memory resources and processing time. Our chat client currently supports encrypted text, audio, and video transfer using a 192-bit key.
For our project, we first studied the Rijndael algorithm, before creating our own implementation of it with a Java program. The reason we chose to research encryption, was due to the growing amounts of sensitive data flowing through the internet, along with advances in computing that have started to make compromising existing encryption standards within the reach of a dedicated malicious agent. The Advanced Encryption Standard, which set Rijndael as its algorithm, is the next-generation defense against malicious persons tampering with confidential data. Compared to current standards and rates of technological progress, it is almost safe to say that Rijndael is undecipherable. Although it is never possible to safeguard against physical breaches of security such as stealing the decryption key, this algorithm will aim to remove the weak link of cryptography from the security equation.
The Rijndael Algorithm is a cipher capable of encrypting data (encoding it to make it difficult for others to read) using a key to encode and decode. It was developed by vincent Rijmen and Joan Daemen. The beauty of the Rijndael algorithm is that a system running it does not require a great deal of processing power or memory to run. All of the processes done on the data to be encrypted are simple matrix operations. Additionally, each one of the steps can easily be reversed, provided that the user has a key. Of course, without the key, little short of a brute force key search can decrypt the data. In fact, the algorithm is so good that it was chosen as the Advanced Encryption Standard (AES) by the National Institute of Standards and Technology (NIST).
We chose Java over other programming languages because of the availability of the numerous functions in the Java API which allowed us to focus more on the abstract ideas rather than low level programming implementing everything from media capture and encoding, to network transfer. Although the speed issues with Java were considered, the media components, which required the most processing, were done through a platform dependent, optimized distribution of Java.
The Chat module is implemented through UDP. Each datagram s data field is simply the text inputted, after passing it through the encryption function as described earlier. The module also opens up port 625 for receiving communications. Once it receives a packet, it attempts to decrypt that packet based on the key currently loaded into memory, and print out the results in the interface. If the key was incorrect, the decryption will fail. Upon successful receipt of the packet, the program will send back an ACK packet in clear text on port 626. The reason for this acknowledgement is so the sender knows that the recipient is both online, and has gotten the message. Although this may have been implemented with TCP, providing automatic control for receiving the packet, the custom control mechanism we have implemented also ensures that this program is indeed running.
The media component, has two separate send classes, AVTransmit2/AVReceive2, AVTransmit3/AVReceive3; First, the DataEnable class will return an array of data sources, with the [0] position occupied by Raw video, and [1] by Raw audio. Because this array is sent as a single object, it is imperative for any machine seeking to broadcast data to have both an audio input device and a video input device. Based on the interface code, these can be then sent using the AV classes. The AV classes are responsible for encoding the video (when applicable) using a motion JPEG encoding mechanism, before establishing an RTP connection with the remote computer and start either transmitting the data, or playback of the data. The only difference between the set of 2 vs. 3 classes, is that the 3 s use a modified transport layer.
Originally, our plans were to send the encoded video encrypted through RTP. That may still be the case once Sun releases its Java Media Framework source code for us to modify and add in encryption. However, to ensure that we can have encrypted communications by the deadline of this project, we have decided to wrap the RTP protocol through UDP, and encrypt the UDP packets as described earlier in the chat module. The RTP protocol is wrapped using a custom socketAdapter, which implements the OutputStream for RTP with UDP datagrams. The operation of the program is simple, all one needs to do for text send/receive, is to put in the host name of the recipient, and hit send. An IP address works as well, but the ACK portion will show a discrepancy in origin, since it actually looks up the host names of ACK datagrams. As for the usage in communications, a user will check the appropriate audio/video to send, and choose send. The client computer may choose receive at any time during the transmission, and the appropriate windows will open up. Those windows will automatically close when the sender terminates the transmission.
Due to the architecture of sending through RTP, where one port may function as receive or send only, for the time being only one machine may be actively broadcasting at once. However, in the future, it is not difficult to edit the source code to enable user selected ports for sending and receiving data, which will enable true, fully featured video conferencing.
Processing power was always optimized against memory when necessary. As a result, our code will perform at decent speeds for audio and text purposes. For video on the other hand, the major factor bring speed down is the mechanism by which we decrypt the RTP stream. The way this is done, is by examining the read-input buffer, and decrypting all bits there. Because this buffer is significantly larger than the actual packets received, there is a significant amount of decryption that is not necessary. However, due to the lack of a mechanism to monitor the modified portions of the buffer, this is our only option. This problem should alleviate itself once Sun releases the source code for their Java Media Framework, since we'll be able to access the data source and encrypt that directly.
Although the Java implementation is fast enough to encrypt 8 kHz mono audio on Pentium III PCs, and raw video on faster machines, there is still room to improve its efficiency. Currently, in order to encrypt or decrypt data, the key must be passed in along with the data. Then the key must be extended to the necessary length. Clearly, when audio is streamed, this means there will be thousands of needless key extension. In a future release of our program, Rijndael should be an object that takes in a key, and stores an extended form of it. Additionally, calculating the multiplicative inverses of bytes and affines has proven to be difficult enough that the program solves for all possible byte inputs by trial and error, and stores the results in arrays, which are maintained for the rest of the process. While array lookup is clearly efficient with respect to speed, and not too expensive in memory, solving by trial and error can take a while. Ideally, this data should be store in a data file included with the classes to speed up the initialization. Matrices are currently stored in row major form, but column major might be better, since data is often operated on as entire vectors. The java code for Rijndael.java looks vastly different from the implementation on the Rijndael website since our code was written for readability at the expense of efficiency. For example, in our code methods for byteShift and mixColumn, for example, were made explicit, in consistency with the Rijndael pseudo C-code in the specifications. After all, this project was mainly to show that encryption of audio could be done well with the Rijndael algorithm; the next step is to polish the code.
In terms of future development and other applications of this program, we believe due to the modularity of the encryption mechanisms, (which are capable of encryption on any array of bytes), it should be readily integrated into any java application out there. This can provide either pure AES encryption, or serve as a communications pack that will give voice transmission for applications such as multiplayer games.
|
|
|
Figure 1: A simple test to see if I can chat with myself.
|
|
|
|
|
Figure 2: A conversation between two computers where
everything is working...
|
|
|
|
|
Figure 3: But if the keys don't match, the messages
become corrupted gibberish...
|
|
|
|
| The keys match again, so everything is fine. | |