CyberSecurity

Video: What is NMOS? with a Secure Control Case Study

Posted on by Russell Trafford-Jones

Once you’ve implemented SMPTE ST 2110‘s suite of standards on your network, you’ve still got all your work ahead of you in order to implement large-scale workflows. How are you doing to discover new devices? How will you make or change connections between devices? How will you associate audios to the video? Creating a functioning system requires an whole ecosystem of control protocols and information exchange which is exactly what AMWA, the Advanced Media Workflow Association has been working on for many years now.

Jed Deame from Nextera introduces the main specifications that have been developed to work hand-in-hand with uncompressed workflows. All prefixed with IS- which stands for ‘Interface Specificaion’, they are IS-04, IS-05, IS-08, IS-09 and IS-10. Between them they allow you to discover new devices, create connections between then, manage the association of audio with video as well as manage system-wide information. Each of these, Jed goes through in turn. The only relevant ones which are skipped are IS-06 which allows devices to communicate northbound to an SDN controller and IS-07 which manages GPI and tally information.

Jed sets the scene by describing an example ST-2110 setup with devices able to join a network, register their presence and be quickly involved in routing events. He then looks at the first specification in today’s talk, NMOS IS-04. IS-04’s job is to provide an API for nodes (cameras, monitors etc.) to use when they start up to talk to a central registry and lodge some details for further communication. The registry contains a GUID for every resource which covers nodes, devices, sources, flows, senders and receivers. IS-04 also provides a query API for controllers (for instance a control panel).

While IS-04 started off very basic, as it’s moved to version 1.4, it’s added HTTPS transport, paged queries and support for connection management with IS-05 and IS-06. IS-04 is a foundational part of the system allowing each element to have an identity, track when entities are changes and update clients accordingly.

IS-05 manages connections between senders and receivers allowing changes to be immediate or set for the future. It allows, for example, querying of a sender to get the multicast settings and provides for sending that to a receiver. Naturally, when a change has been made, it will update the IS-04 registry.

IS-08 helps manage the complexity which is wrought by allowing all audios to flow separately from the video. Whilst this is a boon for flexibility and reduces much unnecessary processing (in extracting and recombining audio) it also adds a burden of tracking which audios should be used where. IS-08 is the answer from AMWA on how to manage this complexity. This can be used in association with BCP-002 (Best Current Practice) which allows for essences in the IS-04 registry to be tagged showing how they were grouped when they were created.

Jed looks next at IS-09 which he explains provides a way for global facts of the system to be distributed to all devices. Examples of this would be whether HTTPS is in use in the facility, syslog servers, the registration server address and NMOS versions supported.

Security is the topic of the last part of talk. As we’ve seen, IS-04 already allows for encrypted API traffic, and this is mandated in the EBU’s TR-1001. However BCP 003 and IS-10 have also been created to improve this further. IS-10 deals with authorisation to make sure that only intended controllers, senders and receivers are allowed access to the system. And it’s the difference between encryption (confidentiality) and authorisation which Jed looks at next.

It’s no accident that security implementations in AMWA specifications shares a lot in common with widely deployed security practices already in use elsewhere. In fact, in security, if you can at all avoid developing your own system, you should avoid it. In use here is the PKI system and TLS encryption we use on every secure website. Jed steppes through how this works and the importance of the cipher suite which lives under TLS.

The final part of this talk is a case study where a customer required encrypted control, an authorisation server, 4K video over 1GbE, essence encryption, unified routing interface and KVM capabilities. Jed explains how this can all be achieved with the existing specifications or an extension non top of them. Extending the encryption methods for the API to essences allowed them to meet the encryption requirements and adding some other calls on top of the existing NMOS provided a unified routing interface which allowed setting modes on equipment.

Watch now!
For more information, download these slides from a SMPTE UK Section meeting on NMOS
Speakers

Jed Deame Jed Deame
CEO,
Nextera Video

Video: Hacking ATSC 3.0

Posted on by Russell Trafford-Jones

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!
Speaker

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

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

Posted on by Russell Trafford-Jones

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