Video: Hacking ATSC 3.0

ATSC’s effort to bring IP into over-the-air broadcast has been long in the making and its deployment in South Korea along with the ITU’s inclusion of it in it’s list of recommended digital broadcast standards is a testament to it gaining acceptance. But as US broadcasters continue with test broadcasts and roll-outs in 2020, what security problems arise when IP’s included in the mix?

Acting is a great network security primer, this talk from Texas A&M’s Wayne Pecena, explains the premise and implications of creating and maintaining security in your broadcast plant. Starting by documenting the high profile attacks on broadcasters over the years, Wayne hones in on the reasons they should care from the obvious, omnipresent threat of ‘dead air’ to ‘loss of trust’ which is particularly motivating in recent years as we have seen state actors move to influence, not disrupt the normal course of life, in low-key, long-burn persistent attacks.

The talk hinges around the ‘AIC’ triad, comprising confidentiality, integrity and availability which are the three core aspects of data to protect. Integrity involves ensuring that the data are not altered either in transit or, indeed, in storage. Confidentiality revolves around ensuring that access control is maintained at all levels including physical, network-level and application live. Finally availability encompasses the fact that if the data isn’t available to the people who need it, the whole thing is pointless. Therefore supporting the availability side of the triangle includes thinking about redundancy and disaster recovery procedures.

Wayne, who is also the president of the Society of Broadcast Engineers, explains some of the attributes of a secure system which starts with security policies. These are the outer layer of any secure environment detailing how the many other layers of security will be managed and applied. Other aspects of a secure environment are appropriately layered and segmented network design, to limit what is available to anyone who does penetrate part of a system, access controls and logging.

After looking at the IETF and IEEE standards bodies, we see how the standard network models overlay neatly on the ATSC layered model with networking in the centre of them all. This leads in to a brief introduction to ‘IP’ in the sense of the the IP protocol on which are based TCP/IP and UDP/IP, between them central to most network communications around the world.

As we see how a small hole in defences can be slowly changed and enlarged allowing the attacker to move forward and create another hole in the next layer, Wayne talks about the types of security threats such malware, denial of service attacks and, of course, inside threats such as your employees themselves being complicit.

As the talk draws to a close we look at how this plays out in the real world talking through diagrams of broadcasters’ systems and how mitigations might play out on premise before talking cloud security. As the threat model in the cloud is different, Wayne explains the best practices to ensure safety and how these and the other security technologies used on the internet keep ATSC 3.0 secure including TLS secure certificate and the use of DNSSEC

The talk finishes with a look at security in the home whether that be with the myriad of consumer media consumption devices or items from the ‘internet of things’.

Watch now!
Speakers

Wayne Pecena Wayne Pecena
Director of Engineering, KAMU TV/FM at Texas A&M University
President, Society of Broadcast Engineers AKA SBE

Webinar: ATSC 3.0 Signaling, Delivery, and Security Protocols

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: User Requirements Beyond SMPTE ST 2110

Work on ST 2110 continues although the main elements of it have been standardised for well over a year now, but many companies are thinking beyond ST 2110.

The EBU’s Willem Vermost presents the wider picture of next generation broadcast facilities charting the need and desires of public broadcasters in Europe. We look here at the need for many broadcasters to move buildings and the problems they face doing so – only one of them being implementing a ST 2110 infrastructure.

The talk then goes on to the problems that broadcasters face and the need for a way of working which defines some common approaches. This has arrived in the form if a document with the lengthy title JT-NM TR-1001-1:2018 which outlines many practical approaches to making ST 2110 work. Many are simple, such as using DHCP but without an agreed set of practices, incompatibilities will come in.

Willem talks about the interoperability tests for this, the results of which are publicly available rather than previous closed-door tests. And before rounding off the talk with questions, he looks at the increasingly well-known EBU Pyramid which shows the availability of different parts of the IP ecosystem; media transport being green, configuration and security being red.

For more information about JT-NM, look at this talk from SMPTE and Imagine Communication’s John Mailhot which covers it in much more detail.

Join Willem at IBC to find out more about ST 2110 at a panel from IET Media discussing ST 2110 and NDI. NDI provides video over IP and is more widely supported than ST 2110, yet major broadcasters seem blind to its benefits. Is this because NDI doesn’t meet the needs of these broadcasters or are there other reasons? What are the use cases where both can be used together?

Join Willem Vermost, The Broadcast Knowledge Editor Russell Trafford-Jones, Marc Risby CTO of Boxer and Liam Hayter from Newtek/NDI to find out more at IBC, IABM Theatre, Future Zone. Friday 13th 15:00-15:45.

Speaker

Willem Vermost Willem Vermost
Senior IP Media &Technology

Video: AMWA BCP 003 NMOS API Security

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