4 Reasons to Choose WebRTC Security over DRMs to Protect Live Video

Digital rights management (DRM) may seem like an unavoidable fact of life in the premium video streaming world, but, when it comes to real-time streaming over WebRTC, it’s helpful to recognize the most rigorous protection requirements can be met without DRM.

Of course, under current licensing policies, distributors of high-value live sports and other programming frequently have no choice but to implement DRM, even if they’re in a position to benefit from the comprehensive and free protection afforded by WebRTC security. The point of this article is to call attention to the fact that, in terms of the basic security merits, content owners and distributors who choose to implement real-time streaming over WebRTC can safely forego the costs and hassles of contracting for DRM support if they have the legal latitude to do so.

Specifically, there are four reasons to choose WebRTC security over DRMs to protect live video:

1. WebRTC, with appropriate authentication support from the platform provider, fulfills all the security requirements targeted by DRM while eliminating DRM licensing fees. These fees are assessed on a per-device and, in some cases, on a per-usage basis, depending on whether new licenses are issued with each session, often to the tune of tens of thousands of dollars per month when big audiences are involved.
2. WebRTC affords greater protection than users get with DRM suppliers by virtue of the fact that such suppliers are subject to and frequently are targets of hacking attacks by pirate distributors and other entities. With WebRTC there is no central point of security operations that can be targeted for ongoing attacks.
3. Even with support of third-party suppliers, the use of DRM requires allocation of administrative resources for accounting purposes and to ensure policies negotiated with license holders are incorporated into the DRM policy management system.
4. With expansion of coverage into new geographic areas or other causes for changes in licensing policies, there’s no need to ensure those policy changes are incorporated into a DRM’s policy management system. Once the distributor is authorized to expand network reach or add new live content from an affiliated provider, WebRTC security is automatically there to support that policy.

That this level of security free of DRM support is available with WebRTC  may come as news to people who haven’t tracked the major strides in security development made by WebRTC working groups within the World Wide Web Consortium (W3C) and the Internet Engineering Task Force, the primary contributors to the open WebRTC project. These efforts have rendered earlier perceptions of WebRTC security or lack thereof obsolete – much as Red5 Pro’s cross-cloud, multi-tiered streaming platform has overcome what were once, and still too often are, commonly cited barriers to using WebRTC as a real-time transport mechanism supporting end-to-end streaming of live content to millions of simultaneous users worldwide.

As described at length in an earlier blog on WebRTC security, the multi-layered security mechanisms that are now part of the protocol stack serve to protect every aspect of the complex signaling operations as well as the communications, media and data payloads streamed over the peer-to-peer connections. All WebRTC traffic is encrypted as a matter of course, whether or not encryption is required by a license holder.

Execution of all these security mechanisms, like everything else pertaining to WebRTC, occurs within the browser, eliminating the need for plug-ins. The streaming platform, utilizing JavaScript-based APIs and the HTML5 extensions that underlie today’s browser operations, is supported by all the leading browsers, including Chrome, Firefox, Safari, Edge and Opera.

For example, when distributors use Red5 Pro’s HTML5 Streaming SDK to instantiate WebRTC, the security mechanisms go into effect automatically. This relieves users of all the complexities attending signaling and other aspects of set-up.

Moreover, there’s no need to ensure adjustments in licensing policies are conveyed to and adopted by DRM suppliers, such as when a distributor negotiates permission to expand the reach of a service in conjunction with onboarding more WebRTC streaming nodes on cloud servers in new regions. The security automatically goes wherever the streams go.

When WebRTC security is used in a situation that would otherwise require DRM, it’s up to the WebRTC streaming platform supplier to provide the means by which publishers and subscribers are authenticated in their respective roles as clients requesting a stream action. For example, Red5 Pro’s RoundTrip Authentication validator is a remote server authorization mediator that implements the appropriate business logic needed to execute server-to-server validation in response to requests from a Red 5 Pro webapp.

Once an authentication process is activated, authentication occurs automatically in response to client requests with no discernable impact on latency. In Red5 Pro’s case, along with providing authentication support for registered users, the authentication validator can be applied in anonymous use cases where validation might be based on just a password or a user name coupled with other identifiers or on custom approaches to identification that don’t employ user names or passwords.

WebRTC security enables the same level of AES (Advanced Encryption Standard) based protection provided by the leading DRM platforms without the need to engage third parties or leverage a DIY platform to manage all the functions related to authenticating devices, authorizing users and securing protected content. Instead, WebRTC uses the video transport protocol SRTP (Secure Realtime Protocol) to send and receive encrypted content over the three channels WebRTC devotes to video, audio and generic data.

Exchanges of the keys used by SRTP to encrypt and decrypt content are managed through a version of the IETF’s TLS known as DTLS (Datagram Transport Layer Security), which is used with UDP (User Datagram Protocol) connectivity, the ultra-low latency packet transmission protocol employed by WebRTC.  All of this happens automatically with instantiation of a WebRTC stream.

SRTP can be used in lieu of DRM even when reverting to alternative protocols to WebRTC. For example, SRTP is the native payload protection mechanism used with SRT (Secure Reliable Transport), and so automatically comes into play when Red5 Pro origin servers ingest SRT formatted content for streaming to SRT-enabled clients.

Similarly, SRTP can be used with RTSP (Real Time Streaming Protocol), which is the protocol used by Red5 Pro customers with native Android and iOS mobile apps like sports betting that are designed to benefit from real-time streaming. Even though mobile devices don’t natively support RTSP, developers using Red5 Pro’s Mobile SDK can build support for RTSP into their apps as a means of achieving real-time streaming comparable to WebRTC but without the signaling complexities. (In such cases, there’s no need to use WebRTC for real-time streaming because the app isn’t relying on a browser to set up the session.)

As another example, Red5 Pro also enables real-time streaming of content that has been formatted for delivery over RTMP (Real Time Media Protocol), the browser-based protocol used with Adobe’s Flash. While Adobe is no longer supporting Flash, RTMP remains in use as an ingest protocol on YouTube Live, Twitch, Facebook and other distribution platforms as well as a means of leveraging old or non-WebRTC compliant browsers to implement a streaming session.

As with the other protocols mentioned here, Red5 Pro servers can ingest RTMP streams for transmission in that format over WebRTC, enabling real-time reception along with execution of the security mechanisms on all devices supported by the major browsers. Browsers like Internet Explorer that can’t handle WebRTC will render the video as an RTMP stream, albeit at higher latencies, owing to the fact that RTMP operates over TCP (Transmission Control Protocol) rather than UDP.

Any protections afforded by DRMs implemented by the original source of the RTMP stream are executed as intended in these instances. Any distributor who is obligated to provide protection over RTMP streams would need to arrange DRM support for Red5 Pro-delivered streams that are transmitted to non-WebRTC compliant devices.

Taking into account all the points raised here, distributors may want to consider using WebRTC security instead of DRM whenever they can. To learn more about how this can be done with Red5 Pro, contact info@red5.net or schedule a call.