We build IPTV / OTT service: content protection
In this article I want to tell how to protect video content, what technologies are used for this. It will be mainly about Internet broadcasting, but I’ll have to touch on DVB and Multicast to make it clear what the difference is.
The Stalker Middleware, which we installed in the last article , has integration with our content protection system, as well as with NGINX X-accel and Secure Link.
The article is intended not only for professionals, but also for those who still do not know anything about IPTV / OTT.
There are two approaches to broadcasting video content:
')
The key difference is the presence of feedback. There are hybrid systems, let's forget about them in this article.
Our company works with video broadcasting via the Internet, so here it is brief, just to make it clearer, what is the difference between video scrambling at the source and video distribution being controlled.
I got Multicast on Broadcast, because, firstly, it is a form of broadcasting, and secondly, I’m talking not only about packet transmission on IP networks, but also affecting DVB.
With Broadcast broadcasting, there is no feedback between the source and the client, so there is only one way to protect the content - to scramble everything on the source. In order for the client to see the protected content, he needs to find out the key that periodically changes. Keys are sent to clients along with the content in such a way that only the recipient can decipher it. As a rule, conditional access modules (CAM-modules) are used for this, and this system is called conditional access system .
Practically everyone who uses pay-TV services has met this way of protecting content. Satellite broadcasters have been using this method of protection for many years, forcing to periodically change access cards and / or CAM modules (or even receivers if the CAM module is built-in).
The main disadvantage of such systems is that keys can be shared ( Cardsharing ). Without feedback, it is impossible to verify the authenticity of the card or module, and it is technically impossible to find out about the existence and the number of intruders.
In IPTV networks, instead of CAM-modules, special software is used, it communicates with the CAS-server and receives keys. This approach virtually eliminates the theft of content, because communication with the CAS server takes place via a secure Unicast connection, and the receiver does not have a card or module that can be fooled or forged. Managed network equipment allows you to limit the number of channels viewed simultaneously (as a rule, operators allow viewing of 2-6 channels at the same time), so all content is problematic, as is the case with satellite / cable broadcasting.
There is nothing to talk about here. Technology fundamentally does not change for many years. Old systems hack, new ones appear. There are drawbacks, but in general the system works.
With Unicast broadcasting, you can use the Broadcast approach: we scramble the stream at the source, and distribute the keys via the Internet. In this case, everything is the same as that of IPTV, only broadcasting is not multicast, but via HTTP.
And it is possible to restrict access to content in a different way: use unique tokens for each user. The idea is that Middleware gives each user unique links to view, and the video server checks these tokens through the Middleware API.
This scheme requires fewer servers and software, which gives good savings both at the start and during operation. The content itself is not encrypted, but access to it will not work without permission from Middleware. The portal provides one-time links, the interception of which does not matter - only the device that requested the link can open the link. And HTTPS saves from banal traffic interception.
“But the content remains open, nothing prevents it from being saved to disk or relayed to other users.” - you will say.
Yes, the end user can save segments to his disk and even organize broadcasting to other users. But, one-time links have a lifespan. Customize and forget will not work. We will have to regularly receive new links from Middleware. Yes, and in the statistics it will be seen that the user 24/7 is watching the same channel. Suspicious.
Since the distribution of content via HTTP is a controlled process, it means that we can track the number of simultaneous connections. And this means that the two channels will not be able to watch simultaneously (unless, of course, the tariff plan allows).
In order to relay all your content, you will have to register a number of accounts equal to the number of TV channels and set up bots that will receive actual temporary links emulating the operation of the console. There will have to show imagination, otherwise the logs will be easy to calculate such users. Just imagine, from one data center (/ 24 networks) 100 users appeared who watched the same channels 24/7. It is necessary to scatter such a botnet on different data centers and set up some system of channel rotation between accounts, so that it is not suspicious. You can discuss in the comments how to steal content and go unnoticed.
“But TV channels do not allow them to be broadcast on cable / local / Internet networks without encryption by a certified CAS system.” - add you.
We will not deal with legal nuances within this article. Different TV channels have different requirements, there are channels that allow open broadcasting, in addition to TV channels, our clients broadcast video from surveillance cameras, which also need to be protected from prying eyes.
The authorization system can be used to transfer video between servers, data centers if you are a content aggregator, and do not broadcast directly to clients.
Many clients come to us just for the sake of the authorization system.
Stalker has several built-in video protection mechanisms. They have several limitations: they are not compatible with some protocols (for example, RTSP), they cannot fully protect HLS streams and do not take into account simultaneous connections. But do not require a specialized video server.
If you include temporary links in the channel setup, but do not check the box next to “NGINX secure link” or “Flussonic support”, then Stalker will use X-Accel-Redirect to access the content.
This configuration is suitable for protecting HTTP MPEG-TS streams, since only one TCP connection is established between the server and the client. Let's see what the NGINX configuration looks like:
Stalker generates a link of the form: stalker / ch / TOKEN123 , where TOKEN123 is a unique, one-time password. When a client opens this link, NGINX rewrite the chk_tmp_tv_link.php file, which checks the validity of the token and returns a link to the stream using the X-Accel-Redirect header.
Source code chk_tmp_tv_link.php:
According to the documentation, to use temporary links, you must set the channel URL in the format: 192.168.1.1 : 8888 / 127.0.0.1: 8899 / udp / 239.1.1.1: 1234, where 192.168.1.1:8888 is the udpxy server, with NGINX installed.
After checking the token, Stalker returns a reference to stalker / get / 127.0.0.1 : 8899 / udp / 239.1.1.1: 1234 in the $ result variable.
As we know from the NGINX configuration, / get / is the internal location, which means that you can only access here via the X-Accel-Redirect header received from the backend.
Further, with the help of a simple regular expression, NGINX starts to proxy (proxy_pass) to a local (or remote) udpxy.
As you can see, protecting content from unauthorized access is easy. One rewrite, one location with the internal parameter and a small backend script - all this is available out of the box and works fine. You can read more about X-Accel in the official NGINX documentation .
NGINX Secure links at Stalker
Now we tick the "NGINX secure link"
Limitations:
Stalker protects access to HTTP MPEG-TS streams and links to m3u8 playlists. Themselves chunks and media playlists remain unprotected and using tcpdump / wireshark you can easily find out the addresses of media playlists and connect to them directly.
The easiest and, most importantly, more reliable way to protect streams is to enable integration with Flussonic. Setting from the side of the Stalker is not required, it is only necessary to put a tick "Flussonic" in the channel settings, and from the side of Flussonic it is only required to specify the address of the Stalker.
Flussonic is a video server of our development, widely used in many OTT and IPTV services. Our strengths are access control and session accounting, archive recording. More on our site .
We have implemented a mechanism for identifying users and tracking connections using authorization backends. HLS and HDS protocols use HTTP session tracking mechanisms, while RTMP, RTSP and MPEG-TS protocols use fixed TCP sessions. Export of the archive in MPEG-TS and MP4 format is also tracked.
Stalker is the authorization backend. When the client comes for the video, we transfer not only the IP address and the name of the channel, but also other important information to the backend:
- token
- HTTP Referer
- Number of open sessions on this stream
- Total number of open sessions on the server
- Requested protocol: (hls, dash, hds, rtmp, rtsp, mpegts or mp4)
- Connection type (new connection or current renewal)
- Type of requested content (live stream, archive, screenshots or access to the API)
- User-Agent
- query string
- Address and port of the server where the request came
This information allows the backend to flexibly control access. You can use all the data to build complex rules.
In response, Stalker returns not just yes / no, but also information about the duration of the permission (or ban), user id and the number of simultaneous connections for this user.
Flussonic saves the response and does not send repeated requests to the backend for the duration of the permission. Since the article turns out so lengthy, I will not show how to configure authorization in Flussonic through Stalker, it is very simple and we have brief but comprehensive documentation on this issue.
In most cases, to protect content from unauthorized viewing on the Internet, you can do without encryption, this is done easily with free tools of popular Middleware, or you can configure integration with the video server by removing the unnecessary role and workload from Stalker.
Tell us in the comments what content protection tools do you use? It is interesting not only about TV broadcasting, but also VOD-services, video surveillance.
Judging by the number of views of the first article of the cycle “Building an OTT / IPTV service”, not everyone has built their solutions and I shouldn’t delay with the following articles.
Then we need to talk about inserting video on the site, this question is not as simple as it may seem. Read our article " What is HTML5 streaming (and why mp4 streaming does not exist) ", she talks about modern means of transmitting and viewing streaming video in a browser. We also launched a free statistics collection service for all our clients.
The Stalker Middleware, which we installed in the last article , has integration with our content protection system, as well as with NGINX X-accel and Secure Link.
The article is intended not only for professionals, but also for those who still do not know anything about IPTV / OTT.
There are two approaches to broadcasting video content:
')
- Broadcast - when data stream is uncontrolledly distributed over the network. Examples: satellite / cable broadcasting, multicast.
- Unicast - the client comes to the server and requests content. It is used in OTT services.
The key difference is the presence of feedback. There are hybrid systems, let's forget about them in this article.
Broadcast
Our company works with video broadcasting via the Internet, so here it is brief, just to make it clearer, what is the difference between video scrambling at the source and video distribution being controlled.
I got Multicast on Broadcast, because, firstly, it is a form of broadcasting, and secondly, I’m talking not only about packet transmission on IP networks, but also affecting DVB.
With Broadcast broadcasting, there is no feedback between the source and the client, so there is only one way to protect the content - to scramble everything on the source. In order for the client to see the protected content, he needs to find out the key that periodically changes. Keys are sent to clients along with the content in such a way that only the recipient can decipher it. As a rule, conditional access modules (CAM-modules) are used for this, and this system is called conditional access system .
Practically everyone who uses pay-TV services has met this way of protecting content. Satellite broadcasters have been using this method of protection for many years, forcing to periodically change access cards and / or CAM modules (or even receivers if the CAM module is built-in).
The main disadvantage of such systems is that keys can be shared ( Cardsharing ). Without feedback, it is impossible to verify the authenticity of the card or module, and it is technically impossible to find out about the existence and the number of intruders.
In IPTV networks, instead of CAM-modules, special software is used, it communicates with the CAS-server and receives keys. This approach virtually eliminates the theft of content, because communication with the CAS server takes place via a secure Unicast connection, and the receiver does not have a card or module that can be fooled or forged. Managed network equipment allows you to limit the number of channels viewed simultaneously (as a rule, operators allow viewing of 2-6 channels at the same time), so all content is problematic, as is the case with satellite / cable broadcasting.
There is nothing to talk about here. Technology fundamentally does not change for many years. Old systems hack, new ones appear. There are drawbacks, but in general the system works.
Unicast
With Unicast broadcasting, you can use the Broadcast approach: we scramble the stream at the source, and distribute the keys via the Internet. In this case, everything is the same as that of IPTV, only broadcasting is not multicast, but via HTTP.
And it is possible to restrict access to content in a different way: use unique tokens for each user. The idea is that Middleware gives each user unique links to view, and the video server checks these tokens through the Middleware API.
This scheme requires fewer servers and software, which gives good savings both at the start and during operation. The content itself is not encrypted, but access to it will not work without permission from Middleware. The portal provides one-time links, the interception of which does not matter - only the device that requested the link can open the link. And HTTPS saves from banal traffic interception.
“But the content remains open, nothing prevents it from being saved to disk or relayed to other users.” - you will say.
Yes, the end user can save segments to his disk and even organize broadcasting to other users. But, one-time links have a lifespan. Customize and forget will not work. We will have to regularly receive new links from Middleware. Yes, and in the statistics it will be seen that the user 24/7 is watching the same channel. Suspicious.
Since the distribution of content via HTTP is a controlled process, it means that we can track the number of simultaneous connections. And this means that the two channels will not be able to watch simultaneously (unless, of course, the tariff plan allows).
In order to relay all your content, you will have to register a number of accounts equal to the number of TV channels and set up bots that will receive actual temporary links emulating the operation of the console. There will have to show imagination, otherwise the logs will be easy to calculate such users. Just imagine, from one data center (/ 24 networks) 100 users appeared who watched the same channels 24/7. It is necessary to scatter such a botnet on different data centers and set up some system of channel rotation between accounts, so that it is not suspicious. You can discuss in the comments how to steal content and go unnoticed.
“But TV channels do not allow them to be broadcast on cable / local / Internet networks without encryption by a certified CAS system.” - add you.
We will not deal with legal nuances within this article. Different TV channels have different requirements, there are channels that allow open broadcasting, in addition to TV channels, our clients broadcast video from surveillance cameras, which also need to be protected from prying eyes.
The authorization system can be used to transfer video between servers, data centers if you are a content aggregator, and do not broadcast directly to clients.
Many clients come to us just for the sake of the authorization system.
Okay, enough theory, let's do some practice.
Stalker has several built-in video protection mechanisms. They have several limitations: they are not compatible with some protocols (for example, RTSP), they cannot fully protect HLS streams and do not take into account simultaneous connections. But do not require a specialized video server.
If you include temporary links in the channel setup, but do not check the box next to “NGINX secure link” or “Flussonic support”, then Stalker will use X-Accel-Redirect to access the content.
This configuration is suitable for protecting HTTP MPEG-TS streams, since only one TCP connection is established between the server and the client. Let's see what the NGINX configuration looks like:
server{ listen 0.0.0.0:8888; rewrite ^/ch/(.*) /stalker_portal/server/api/chk_tmp_tv_link.php?key=$1 last; location /stalker_portal { internal; proxy_set_header Host 192.168.1.1; # <-- IP proxy_set_header X-Real-IP $remote_addr; proxy_pass http://192.168.1.1:88/stalker_portal; # <-- IP } location ~* ^/get/(.*?)/(.*) { internal; set $upstream_uri $2; set $upstream_host $1; set $upstream_url http://$upstream_host/$upstream_uri; proxy_set_header Host $upstream_host; proxy_set_header X-Real-IP $remote_addr; proxy_pass $upstream_url; } } Stalker generates a link of the form: stalker / ch / TOKEN123 , where TOKEN123 is a unique, one-time password. When a client opens this link, NGINX rewrite the chk_tmp_tv_link.php file, which checks the validity of the token and returns a link to the stream using the X-Accel-Redirect header.
Source code chk_tmp_tv_link.php:
<?php include "./common.php"; $result = Master::checkTemporaryLink($_GET['key']); if (!$result){ $result = '/404/'; } header("X-Accel-Redirect: ".$result); ?> According to the documentation, to use temporary links, you must set the channel URL in the format: 192.168.1.1 : 8888 / 127.0.0.1: 8899 / udp / 239.1.1.1: 1234, where 192.168.1.1:8888 is the udpxy server, with NGINX installed.
After checking the token, Stalker returns a reference to stalker / get / 127.0.0.1 : 8899 / udp / 239.1.1.1: 1234 in the $ result variable.
As we know from the NGINX configuration, / get / is the internal location, which means that you can only access here via the X-Accel-Redirect header received from the backend.
Further, with the help of a simple regular expression, NGINX starts to proxy (proxy_pass) to a local (or remote) udpxy.
As you can see, protecting content from unauthorized access is easy. One rewrite, one location with the internal parameter and a small backend script - all this is available out of the box and works fine. You can read more about X-Accel in the official NGINX documentation .
NGINX Secure links at Stalker
Now we tick the "NGINX secure link"
Limitations:
Stalker protects access to HTTP MPEG-TS streams and links to m3u8 playlists. Themselves chunks and media playlists remain unprotected and using tcpdump / wireshark you can easily find out the addresses of media playlists and connect to them directly.
The easiest and, most importantly, more reliable way to protect streams is to enable integration with Flussonic. Setting from the side of the Stalker is not required, it is only necessary to put a tick "Flussonic" in the channel settings, and from the side of Flussonic it is only required to specify the address of the Stalker.
Flussonic is a video server of our development, widely used in many OTT and IPTV services. Our strengths are access control and session accounting, archive recording. More on our site .
We have implemented a mechanism for identifying users and tracking connections using authorization backends. HLS and HDS protocols use HTTP session tracking mechanisms, while RTMP, RTSP and MPEG-TS protocols use fixed TCP sessions. Export of the archive in MPEG-TS and MP4 format is also tracked.
Stalker is the authorization backend. When the client comes for the video, we transfer not only the IP address and the name of the channel, but also other important information to the backend:
- token
- HTTP Referer
- Number of open sessions on this stream
- Total number of open sessions on the server
- Requested protocol: (hls, dash, hds, rtmp, rtsp, mpegts or mp4)
- Connection type (new connection or current renewal)
- Type of requested content (live stream, archive, screenshots or access to the API)
- User-Agent
- query string
- Address and port of the server where the request came
This information allows the backend to flexibly control access. You can use all the data to build complex rules.
In response, Stalker returns not just yes / no, but also information about the duration of the permission (or ban), user id and the number of simultaneous connections for this user.
Flussonic saves the response and does not send repeated requests to the backend for the duration of the permission. Since the article turns out so lengthy, I will not show how to configure authorization in Flussonic through Stalker, it is very simple and we have brief but comprehensive documentation on this issue.
Summing up.
In most cases, to protect content from unauthorized viewing on the Internet, you can do without encryption, this is done easily with free tools of popular Middleware, or you can configure integration with the video server by removing the unnecessary role and workload from Stalker.
Tell us in the comments what content protection tools do you use? It is interesting not only about TV broadcasting, but also VOD-services, video surveillance.
Judging by the number of views of the first article of the cycle “Building an OTT / IPTV service”, not everyone has built their solutions and I shouldn’t delay with the following articles.
Then we need to talk about inserting video on the site, this question is not as simple as it may seem. Read our article " What is HTML5 streaming (and why mp4 streaming does not exist) ", she talks about modern means of transmitting and viewing streaming video in a browser. We also launched a free statistics collection service for all our clients.
Source: https://habr.com/ru/post/314736/
All Articles