Security

Webinar: Securing Live Streams

Posted on by Russell Trafford-Jones

Piracy in France cost €1.2bn in 2017 and worldwide the loss has been valued up to US$52 billion. Even if these numbers are inflated, over-counted or similar, it’s clear there is a lot of money at stake in online streaming. There are a number of ways of getting to protect your content, encryption, Digital Rights Management (DRM) and tokenisation are three key ones and this webinar will examine what works best in the real world.

All these technologies used together don’t always stop piracy 100%, but they can significantly impact the ease of pirating and the quality of the final material.

Date: Thursday January 30th – 10a.m. PT / 1p.m. / 18:00 GMT

It’s important to understand the difference between encryption and Digital Rights Management. In general DRM relies on encryption, whereby encryption is a way of making sure that decodable video only lands in the hands of people who have been given the encryption key. This means that people who are snooping on traffic between the video provider and consumer can’t see what the video is and can be accomplished in a similar way to secure web pages which are secured against eavesdroppers. The problem with encryption is, however, that it doesn’t intrinsically decide who is allowed to decode the video meaning anyone with the decryption key can video the content. Often this is fine, but if you want to run a pay-TV service, even ignoring content, it’s much better to target customer by customer who can video the video. And this is where DRM comes in.

DRM is multi-faceted and controls the way in which consumers can view/use the content as much as whether they can access it to start with. DRM, for instance, can determine that a display device can show the work, but a recorder is not allowed to make a recording. It can also determine access based on location. Another aspect of DRM is tracking in the form of insertion of watermarks and metadata which mean that if a work is pirated, there is a way to work back to the original subscriber to determine the source of the leak.

Tokenisation is a method in which the player requests access to the material and is passed a token, by means of a response from the server after it has checked if the player is allowed access. Because of the way this token is created, it is not possible for another player to use it to access the content which means that sharing a URI won’t allow another user access to the video. Without some form of access control, once one subscriber has received a URI to access the video, they could pass that to another user who could also then access it.

What’s the best way to use these technologies? What are the pros and cons and what are the other methods of securing media? These questions and more will be discussed in this Streaming Video Alliance webinar on January 30th.

Register now!
Speakers

Peter Cossack Peter Cossack
Vice President Cybersecurity services,
Irdeto
Kei Foo Kei Foo
Director of Advanced Video Engineering,
Charter Communications
Orly Amsalem Orly Amsalem
Product Manager, AI/ML based video security and anti-piracy solutions ,
Synamedia
Marvin Van Schalkwyk Marvin Van Schalkwyk
Senior Solutions Architect,
FriendMTS
Jason Thibeault Jason Thibeault
Executive Director,
Streaming Media Alliance

Webinar: ATSC 3.0 Signaling, Delivery, and Security Protocols

Posted on by Russell Trafford-Jones

ATSC 3.0 is bringing IP delivery to terrestrial broadcast. Streaming data live over the air is no mean feat, but nevertheless can be achieved with standard protocols such as MPEG DASH. The difficulty is telling the other end what’s its receiving and making sure that security is maintained ensuring that no one can insert unintended media/data.

In the second of this webinar series from the IEEE BTS, Adam Goldberg digs deep into two standards which form part of ATSC 3.0 to explain how security, delivery and signalling are achieved. Like other recent standards, such as SMPTE’s 2022 and 2110, we see that we’re really dealing with a suite of documents. Starting from the root document A/300, there are currently twenty further documents describing the physical layer, as we learnt last week in the IEEE BTS webinar from Sony’s Luke Fay, management and protocol layer, application and presentation layer as well as the security layer. In this talk Adam, who is Chair of a group on ATSC 3.0 security and vice-chair one on Management and Protocols, explains what’s in the documents A/331 and A/360 which between them define signalling, delivery and security for ATSC 3.0.

Security in ATSC 3.0
One of the benefits of ATSC 3.0’s drive into IP and streaming is that it is able to base itself on widely developed and understood standards which are already in service in other industries. Security is no different, using the same base technology that secure websites use the world over to achieve security. Still colloquially known by its old name, SSL, the encrypted communication with websites has seen several generations since the world first saw ‘HTTPS’ in the address bar. TLS 1.2 and 1.3 are the encryption protocols used to secure and authenticate data within ATSC 3.0 along with X.509 cryptographic signatures.

Authentication vs Encryption
The importance of authentication alongside encryption is hard to overstate. Encryption allows the receiver to ensure that the data wasn’t changed during transport and gives assurance that no one else could have decoded a copy. It provides no assurance that the sender was actually the broadcaster. Certificates are the key to ensuring what’s called a ‘chain of trust’. The certificates, which are also cryptographically signed, match a stored list of ‘trusted parties’ which means that any data arriving can carry a certificate proving it did, indeed, come from the broadcaster or, in the case of apps, a trusted third party.

Signalling and Delivery
Telling the receiver what to expect and what it’s getting is a big topic and dealt with in many places with in the ATSC 3.0 suite. The Service List Table (SLT) provides the data needed for the receiver to get handle on what’s available very quickly which in turn points to the correct Service Layer Signaling (SLS) which, for a specific service, provides the detail needed to access the media components within including the languages available, captions, audio and emergency services.

ATSC 3.0 Receiver Protocol Stack

ATSC 3.0 Receiver Protocol Stack

Media delivery is achieved with two technologies. ROUTE (Real-Time Object Delivery over Unidirectional Transport ) which is an evolution of FLUTE which the 3GPP specified to deliver MPEG DASH over LTE networks. and MMTP (Multimedia Multiplexing Transport Protocol) an MPEG standard which, like MPEG DASH is based on the container format ISO BMFF which we covered in a previous video here on The Broadcast Knowledge

Register now for this webinar to find out how this all connects together so that we can have safe, connected television displaying the right media at the right time from the right source!

Speaker

Adam Goldberg Adam Goldberg
Chair, ATSC 3.0 Specialist Group on ATSC 3.0 Security
Vice-chair, ATSC 3.0 Specialist Group on Management and Protocols
Director Technical Standards, Sony Electronics

Video: Stopping Geolocation Fraud Via “Rented” Residential IPs to Protect Territorial Content

Posted on by Russell Trafford-Jones

Securing streams is a cat-and-mouse game and this is the latest move to keep content secure.

In order to maximise returns on content, the right to show the content is usually limited to certain geographies and sometimes streaming rights are sold separate to broadcast rights. This means it’s common to geo-lock streaming services whereby each IP address requesting content is checked against a database to see in which country that computer is located. This system isn’t perfect, but it tends to work fairly well.

The key, then, for people wanting to access content from outside the geography is to use someone else’s IP. You can do this by renting time on a computer such as in AWS, Digital Ocean or other similar providers where you can select in which country the computer you are using is located. However the IP addresses owned by these providers are also in the databases and are often blocked from access.

The determined viewer, therefore, needs a VPN which uses residential addresses from within that location. The OTT providers can’t block legitimate IP addresses, therefore access will be given. Access is provided to these addresses by VPNs which offer free use of their service in exchange for them being able to route traffic via your computer.

Detecting this kind of use is difficult, and is what Artem Lalaiants discusses in this talk from SMPTE 2018.

Watch now!

Speaker

Artem Lalaiants Artem Lalaiants
Service Delivery Manager,
GeoGuard

Video: AMWA BCP 003 NMOS API Security

Posted on by Russell Trafford-Jones

Building security into your infrastructure is more and more important for broadcasters with many now taking very seriously a topic which, only 6 years ago, was only just being discussed. Attacks on broadcasters like TV5 Monde have brought into focus that it’s not just copmanies who have high value rights who are ripe for breach – attacking a broadcaster is a high impact way of getting your message accross.

We have seen how the internet, which was built on very open and trusting protocols, has struggled in recent times to keep abuse to a minimum and to implement security to keep data safe and to keep out unauthorised persons.

And so AMWA is looking at its recent specifcations to ensure there is a clear and interoperable way of implementing security. The benefit of IP should be that that as an industry we can benefit from the work of other industries before us and here, having based these specifications on HTTP interfaces, we can do exactly that. Just like sites on the internet can implemnt HTTPS, we, too use the same mechanism of security certificates and TLS (colloquially known as SSL) encryption to ensure that not only is our data encrypted but also that no one can impersonate anyone else on the network.

Simon Rankine from BBC R&D explains the work he has been part of in defining this secure interface which not only protects from mal-intentioned actors, but also offers some protection from accidental mistakes by staff.

Simon gives a good intorduction to not only how this is a benefit but also how the underlying mechanisms work which are just as applicable to the NMOS APIs as they are to general websites.

Speaker

Simon Rankine
Simon Rankine
Project Research Engineer,
BBC R&D