Encryption of a Video Streaming

Encryption of a Video streaming application

1. Goals

This assignment is to apply security to an application; in particular cryptography to secure the data that this application uses. You are provided with a simple but working C# streaming video server and video player client. The client and server in this system are communicating using the Real-Time Streaming Protocol (RTSP) and send data using the Real-time Transfer Protocol (RTP). This system as provided is totally insecure; all the streaming data are transmitted in the clear. You will be required to provide confidentiality, message authentication, and replay protection to the RTP traffic, using both the cryptography and security features found in the .NET platform and Mono library. The required security features are:

1. A key exchange between the Video player (the client) and the video streaming server when the client connects.

2. The confidentiality of the RTP payloads only, using a block cipher in CBC.

3. The integrity of the entire RTP packet (payload and header), using Message Authentication Codes (MAC).

4. You must invent and implement a way to prevent replay attacks.

Find these features in detail in the following sections.

2. Security Features

2.1 Key Exchange

You may use the Diffie-Hellman key exchange protocol. Note that we have not yet discussed a method to prevent the “man-in-the-middle” MiM attack on key exchange protocols. Consequently, in this assignment you are only required to apply the key exchange protocol to come up with a shared secret between client and server. We will deal with the MiM attack in a later assignment.

The data flow of the key-exchange protocol and the agreement of encryption mode (CBC) will take place out-of-band, i.e., through RTSP protocol not RTP protocol. You should also use the secret obtained during key exchange to generate your block cipher key, IV and your MAC key.

2.2 Encryption

Each RTP packet transmitted from the server to the client must be encrypted using a block cipher. You may use any standard block cipher you like, e.g. AES, but all messages must be encrypted using the CBC mode. As mentioned above, you should generate both the cipher key and the IV from the secret obtained during key exchange. You need also to add an option in the player UI to make the client plays the video without payload decryption.

2.3 MAC

Every message that goes over the network should have a MAC to enable the detection of a malicious attacker tampering with messages en route. You should generate the key for this MAC from the secret obtained during key exchange as described above.

2.4 Preventing Replay Attacks

Cryptography itself is vulnerable to attack and is not something that can be "plugged into" an application and then forgotten. Even after you secure your system with encryption and MACs, there is still an obvious replay attack. Trudy can capture some encrypted data flow and then re-route (or inject them) repeatedly to the client – which is still a valid data – flooding or corrupting the entire system. For example, Trudy may keep sending STOP or TEARDOWN command to the server during the video play-out.

Your solution should prevent an attacker from replaying the RTSP data flow from client to server and vice versa.

2.5 Security Holes

Even with these security features, it should be clear that there are still holes in this streaming video server and client. Aside from the “replay attacks” and the “man-in-the-middle” attack on the key exchange protocol, the biggest remaining problem is authentication. The easiest way for an attacker to play and watch the movie is simply by connecting to the server normally. Address these problems is outside the scope of this assignment.

Can you complete it in 48 hours?

C# Programming Computer Security Engineering Web Security

Project ID: #3999226

About the project