DTLS Streaming Protocol: Encryption in Transit for Live

DTLS Streaming Protocol: Encryption in Transit for Live

Need additional ways to safeguard your live streaming video content while in transit?

IBM’s video streaming and enterprise video streaming solutions can work with a virtually secure streaming protocol. This provides DTLS (Datagram Transport Layer Security) encryption from the encoder, sending the live streaming content, to the ingest servers at IBM receiving it.

Note that this is an added service. Contact us to learn more details if you are interested in encrypting your live streaming content in transit through a DTLS streaming protocol.

Video encryption

By its nature, the encryption process is intended to encode data or assets in a manner that keeps it hidden and inaccessible to unauthorized individuals. In execution, this means that even if an unauthorized user is able to access it, they can’t use it. To make this possible, an encryption algorithm is used that encodes the readable data into an unreadable format generally known as ciphertext. In order to decode this and turn it into a useable format, a decryption key is needed. This essentially reverts the ciphertext into plaintext where it can be used again.

Now video assets have several different states they can be in, such as at rest. For the purposes of live streaming, though, this will start its journey in transit.


Encryption in transit

To encrypt video content in transit, this can be done through using AES (Advanced Encryption Standard), which comes in different key sizes such as 128 bits or 256 bits. The process involves the key, plaintext and an input before being transformed into something random, i.e. the ciphertext. To turn it back into a useable format, the same key, which is actually a number, is required. The safety in this approach is in the amount of different possibilities the key could be. For example, an AES-128 bit key has 2 to the power of 128 different possibilities. To elaborate, this means 340,282,366,920,938,463,463,374,607,431,768,211,456 different numbers that the key could be.

Now encrypting content being delivered can be done through using SSL (Secure Sockets Layer) or TLS (Transport Layer Security). While the two technologies are sometimes mentioned in an interchangeable manner, TLS is actually the successor technology and was built from SSL 3.05. Versions of SSL prior to TLS, 3.0 and lower, have notable exploits that have been pointed out publicly by Mozilla. As a result, it’s been prohibited from use by the Internet Engineering Task Force (IETF) as of 2015 and blocked in modern browser versions of Google Chrome and Mozilla Firefox among others.

In the case of IBM, video streaming content in transit uses AES-256 through TLS. It functions through encapsulating communication between a client’s or viewer’s machine and the server through four protocol layers. These layers are:

  • Record Layer
  • ChangeCipherSpec Protocol (signals the beginning of a secure communication)
  • Alert Protocol (sends errors, problems or warnings about the connection)
  • “Handshake” Protocol

Across these, a server presents its digital certificate to the client’s machine, using public-key encryption to validate both the certificate and also confirm the server’s identity claim. After a successful authentication, both the client and server establish a cipher setting and a shared key to encrypt data that is exchanged during the session.


DTLS streaming protocol

In addition to all of this, a protocol can also be utilized for DTLS (Datagram Transport Layer Security) encryption from the encoder to ingest servers. It is a communications protocol that allows systems to exchange data with appropriate systems while preventing eavesdropping and tampering.

DTLS Streaming Protocol: Encryption in Transit for Live

Now DTLS is actually a modified version of TLS that functions over datagram transport. It reuses protocol elements of TLS, with small modifications and improvements for it to work properly with UDP (User Datagram Protocol). Like TLS, DTLS data is carried in records and is only processed once the entire record is available. A difference, though, is that DTLS avoids fragmentation by requiring that records fit within a single datagram. There are a few benefits to this approach, such as the case datagrams carrying the remaining fragments are lost, the received ones cannot be processed. DTLS also doesn’t buffer partial records, meaning that host memory is used more efficiently leading toward it being less susceptible to a DoS (denial of service) attack.



Content owners and enterprises can utilize IBM’s video streaming services with the DTLS streaming protocol, netting additional security measures for their live content. This can be used to protect use cases as diverse as monetized content to internal facing material, such as town halls or broadcasting department meetings.

Contact us to learn more details if you are interested in encrypting your live streaming content in transit through the DTLS streaming protocol.