The video segments are encrypted by the same key? It's not a per-user key? So if a single "authorized" viewer can just get all decryption keys then they can allow anyone to decrypt the video stream. Completely bypassing these authorization checks.
> WARNING: This method of DRM will keep honest people honest. But determined people will figure out how to break it. This is the case with any kind of DRM.
It seems to me that this is more about essentially preventing the link being shared.
Having not played around with HLS I don't see why this couldn't be done by simply doing an authentication check and refusing to serve content if the auth check fails.
Preventing decryption of the video is obviously impossible as it's being decrypted on the box itself.
The key rotation seems odd to me.
If you're worried about users sharing their session key or something then that can be dealt with on the back end (it surprises me that, for example, YT seemingly don't care about the same IP downloading a ton of videos in parallel with ytdl, say; I suppose NAT makes it slightly more difficult to detect, but not much more so...).
The software my uni uses for recording lectures does this. I have to get the playlist link from the dev tools in firefox and then give that to a script that downloads and decrypts it all, and saves it for prosterity.
> The video segments are encrypted by the same key? It's not a per-user key? So if a single "authorized" viewer can just get all decryption keys then they can allow anyone to decrypt the video stream. Completely bypassing these authorization checks.
Once someone has the decryption key they have the plaintext. It's the same plaintext for everyone so what does it matter if it's the same key for everyone? Once they have the plaintext they don't have to give some other users your encrypted stream + key, they can just give the other users the plaintext.
One thing they can do is create a website that streams it from the official servers without having to proxy it. I think I saw some websites were actually doing this.
Correct. Every user get the same key. That is why a real DRM system (which this article is not) has the complexity around secure key delivery and secure playback.
Netflix is not one key per user. It's one (or more) keys per title. But every user get the same key. What is describes in the post is NOT DRM. It is encryption. DRM add a secure player (that comes with your browser) along with a server to distribute keys that are encrypted per user.
This right here. The closest this comes to DRM is that it's obfuscation, which makes it difficult to find the right download link. But once you have the right download link and you're logged in, it's trivial to rip the stream. Real DRM can't be broken without either a flaw in the encryption scheme or reversing the proprietary and closed source bit of code that handles the decryption. In other words, if you want to have real DRM, you have to use Widevine or some other browser-supported scheme that you trust.
Streaming with a custom built NGINX instance? This person is one of maybe 3 in the world that can actually make this work. This blog post is representative of years of life obiterated in nonsensical DSL syntax / grammer mistakes.
Buyer beware. Seriously, don't do this to yourself. I read this because streaming is an enigma to me, but this post is suicide.
If you want something this fragile for yourself, just pay this guy to do it for you.
> Streaming with a custom built NGINX instance? This person is one of maybe 3 in the world that can actually make this work.
From a cursory look, it looks like he is using nginx-RTMP - one of the most widely used streaming solutions out there: https://github.com/arut/nginx-rtmp-module + ffmpeg
If you know Linux - shouldn't take more than 5-10 minutes to set it up.
After reading, I was excited to read the previous two. The links at the bottom of the page are broken, as they appear to include the wrong date (off by 1).
Proliferating DRM is evil. The most disgusting are some companies like Denuvo which make money on it.
The video segments are encrypted by the same key? It's not a per-user key? So if a single "authorized" viewer can just get all decryption keys then they can allow anyone to decrypt the video stream. Completely bypassing these authorization checks.
The author did include this caveat:
> WARNING: This method of DRM will keep honest people honest. But determined people will figure out how to break it. This is the case with any kind of DRM.
It seems to me that this is more about essentially preventing the link being shared.
Having not played around with HLS I don't see why this couldn't be done by simply doing an authentication check and refusing to serve content if the auth check fails.
Preventing decryption of the video is obviously impossible as it's being decrypted on the box itself.
The key rotation seems odd to me.
If you're worried about users sharing their session key or something then that can be dealt with on the back end (it surprises me that, for example, YT seemingly don't care about the same IP downloading a ton of videos in parallel with ytdl, say; I suppose NAT makes it slightly more difficult to detect, but not much more so...).
This kind of DRM will turn honest people in to pirates when the video doesn't play properly.
The software my uni uses for recording lectures does this. I have to get the playlist link from the dev tools in firefox and then give that to a script that downloads and decrypts it all, and saves it for prosterity.
> The video segments are encrypted by the same key? It's not a per-user key? So if a single "authorized" viewer can just get all decryption keys then they can allow anyone to decrypt the video stream. Completely bypassing these authorization checks.
Once someone has the decryption key they have the plaintext. It's the same plaintext for everyone so what does it matter if it's the same key for everyone? Once they have the plaintext they don't have to give some other users your encrypted stream + key, they can just give the other users the plaintext.
One thing they can do is create a website that streams it from the official servers without having to proxy it. I think I saw some websites were actually doing this.
That seems like more of a "sending the stream to people who haven't paid" problem than a "people who haven't paid having the decryption key" problem.
Correct. Every user get the same key. That is why a real DRM system (which this article is not) has the complexity around secure key delivery and secure playback.
But it was a sick blog post, right?
I think this one isn't per user, but likely Netflix's keys would be per user.
Netflix is not one key per user. It's one (or more) keys per title. But every user get the same key. What is describes in the post is NOT DRM. It is encryption. DRM add a secure player (that comes with your browser) along with a server to distribute keys that are encrypted per user.
This right here. The closest this comes to DRM is that it's obfuscation, which makes it difficult to find the right download link. But once you have the right download link and you're logged in, it's trivial to rip the stream. Real DRM can't be broken without either a flaw in the encryption scheme or reversing the proprietary and closed source bit of code that handles the decryption. In other words, if you want to have real DRM, you have to use Widevine or some other browser-supported scheme that you trust.
Here's an even better solution:
1. Don't use DRM.
2. Feel ashamed for considering using DRM.
3. Repeat.
Streaming with a custom built NGINX instance? This person is one of maybe 3 in the world that can actually make this work. This blog post is representative of years of life obiterated in nonsensical DSL syntax / grammer mistakes.
Buyer beware. Seriously, don't do this to yourself. I read this because streaming is an enigma to me, but this post is suicide.
If you want something this fragile for yourself, just pay this guy to do it for you.
> Streaming with a custom built NGINX instance? This person is one of maybe 3 in the world that can actually make this work.
From a cursory look, it looks like he is using nginx-RTMP - one of the most widely used streaming solutions out there: https://github.com/arut/nginx-rtmp-module + ffmpeg
If you know Linux - shouldn't take more than 5-10 minutes to set it up.
Nice write up!
After reading, I was excited to read the previous two. The links at the bottom of the page are broken, as they appear to include the wrong date (off by 1).
This is fantastic! I started doing webwork a few years back and while I've gotten a chance to do some cool projects, streaming wasn't there.
This seemed like something that parts 1 and 2 of would be much more interesting, but the links to them both 404 :(
https://benwilber.github.io/nginx/rtmp/live/video/streaming/...
https://benwilber.github.io/nginx/rtmp/live/video/streaming/...
Here is how you do it with real DRM: https://github.com/Axinom/drm-quick-start