2

For Video on Demand, DRM seems the way to go. I've been told that providers might be using a token-based system, but I haven't found any provider so far that uses token, just DRM (except Akamai, although it integrates with DRMs anyway).

However, I'm not sure which technologies are being used to protect LIVE streams.

The industry is using something called "forensics watermarking", which is a technology to track who's the source of an illegal video stream and eventually shut it down. That technology is rather a detective control though. I'm interested in technologies to prevent that unauthorized users access the original stream.

So my question is, what technologies are there available to protect an OTT LIVE stream?

Notice that geoblocking, IP access control, HLS/DASH encryption (AES-128) or use EME/CENC are not the answers I'm looking for. My question is regarding the technologies that make it possible to implement these things based on user authentication/authorization.

The Illusive Man
  • 10,487
  • 16
  • 56
  • 88
  • Could you specify what formats do you use specifically, like HLS and DASH only? – Aria Aug 23 '16 at 11:26
  • @Aria both. If your question is regarding to the use of EME and CENC, that's not the answer of my question. Both are just a mean to transparently work with DRMs. – The Illusive Man Aug 23 '16 at 11:33
  • And what do you use to deliver content? Any particular CDN? And if yes, then what service in particular, is it push or pull? Or maybe your own distribution? Do you use standard HTTP server or do you use some sort of media server? – Aria Aug 23 '16 at 11:37
  • @Aria I haven't said I own an infrastructure. I'm interested, and therefore asking, which technologies are used to protect OTT live streams, independently of the format (the standard nowadays is HLS, increasingly moving to DASH). Everything you said now is irrelevant, the same technology may be used by a CDN or by a custom HTTP/Media server. – The Illusive Man Aug 23 '16 at 11:41
  • There's no technology to protect live stream independently of the format. There are RTMP streams (dominant today), fMP4 delivered over HTTP, HLS and so on. There's no single technology to protect that and even "technology" is bad naming for the issue. For example, "Flash Player is technology and it includes Flash Access to protect streams". Each format of live streaming is technology on its own and includes its own protection mechanisms. – Aria Aug 23 '16 at 12:10
  • And technology includes A/V coding, packaging, encrypting, delivering, playing, protection in form of DRM (as it is for given format). So then the delivering part can have token checking module which connects to the website. Akamai has one. However it's different for each protocol because each protocol works in different way since there are different technologies for playback. – Aria Aug 23 '16 at 12:18

2 Answers2

2

So to support Live Stream and requirement that only logged-in users are allowed, the database of the users is needed. This also means there's need for registration.

To allow only registered users to view the live stream, you need your own website with user registration, and then you need a media server or CDN which will check with your web site if token (cookie) is valid.

The below scheme is in its simplest form. Normally there's dedicated "Key Server" as with typical encryption system. Additionally the stream is also encrypted and the key server is not only checking your username / password or token but if the content owner allows you to play the stream. It would also send you the decryption key (or the license, depends on the technology used).

Media Token

Most media servers and CDNs support this. With HTTP servers can have custom authentication module.

If you look for technology which can do all of that look at Kaltura, they got free version as well.

Regarding HLS and DASH streams, ideally it would be:

  • CDN service which checks the tokens with your Key Server (because main app server is not the one you want to query because of performance, the Key Server must have cache of tokens or dedicated scalable database).
  • Your media server can have simple plugin to check for tokens
  • Your HTTPd server can have custom module to check for the tokens

In case of DASH and HLS you have 1. metadata files (like m3u8 or manifests) and media fragments. All fragments are usually encoded with single AES key and the key is normally stored in the meta-data files. It's quite different for DASH as there can be optional key server.

So the solution for HLS is for example to send Cookie to every possible request and then check for that Cookie. HTTPD server has to have cache of this stuff. You could extend this method to DASH however they provide more decent mechanisms.

The current technology to protect content:

  • Most live streams are using Flash Access (as flash is major platform for live stream delivery)
  • There's Widevine by Google which is slowly being adopted (Android)
  • Microsoft Playready
  • W3C EME
  • Custom token-based authentication in simplest form - and that's not a technology but a way of integration.
Aria
  • 2,706
  • 11
  • 19
  • 1
    4 out of your 5 final points are DRM / DRM-related. Basically you are saying in your answer the same I said in my question: DRM and token. Anyway, I already found the answer I was looking for. OTT "direct" providers (Netflix, Hulu, Prime...) use DRM, OTT "CDN" providers (Akamai, Limelight, Level3...) use token-based auth, which then usually integrates with a third-party DRM. Anyway, I'll accept the answer because it's related (though out of the scope of the question) – The Illusive Man Aug 23 '16 at 12:55
1

Token based auth doesn't actually work. DRM works, but only because no one reverse-engineered things like Widevine yet.

Nothing is stopping people from recording their screen with obs and broadcasting it with nginx - no DRM will help you with that at the moment.

The only thing token based auth and DRM actually help with is hotlinking - which token/cookie based auth doesn't really help with very much but DRM solves pretty well until someone reverse-engineers it.

In real life applications - things like Kodi deal with cookie/token based auth but not with DRM.

Benjamin Gruenbaum
  • 111
  • 3