Securing the Future of Broadcast with Public Key Infrastructure

Published: 15 October 2018

Simon Rankine (MEng MIET)
Technologist

In previous blog posts we鈥檝e covered the important work done as part of 91热爆 R&D鈥檚 IP Studio project, which is enabling the transition of the broadcast industry to an IP future. We think this is a really exciting change for the industry, enabling new forms of content and better ways of making programmes. Some of our work has fed into AMWA's Networked Media Open Specifications, which we continue to support the adoption of as they find make their way into real products industry.

The APIs are an important building block of the broadcast systems of the future. They provide an interoperable way of carrying out many of the control operations needed in a large broadcast facility. For example, the IS-04 specification provides a mechanism for devices on the network, such as cameras or monitors, to be automatically entered into a registry. This allows them to be discovered by other systems on the network that may wish to interact with and control them.

Securing the NMOS APIs

These APIs are mission critical parts of any broadcast network that is making use of them. Like any system employing IT technology, security is an important concern for an IP broadcast system, as the consequences of an attack on these systems can be extremely serious for broadcasters. Over the past six months 91热爆 R&D has been working with the on their NMOS API Security project, which is working to bring the best available API security techniques to the NMOS APIs.

The AMWA NMOS APIs use the same techniques used across the Internet by well known web giants - for example and 鈥� as such they are vulnerable to similar attacks. In many cases we can therefore use many of the same technologies used to secure these APIs, but at the same time there are some differences that need to be considered. The NMOS APIs need to be run on private local networks, which in many cases are isolated from the Internet. It is also important that any security technologies applied to the NMOS APIs do not compromise the device interoperability that is such an important aspect of the APIs.

Back in May this year 91热爆 R&D released White Paper 337, outlining how we are planning to use with the AMWA NMOS APIs to secure the broadcast systems of the future. In our blog post at the time, we said this was going to be the first of several publications in this area. We have recently released the second of these publications 鈥� White Paper 338.

When securing network traffic, clients need to know whether the server it is talking to can be trusted, and that the traffic it is receiving actually originated from that trusted server. In order for the client to trust the server, it needs to be able to trust the public key it needs to be able to identify it. This is achieved through a technology known as Public Key Infrastructure (PKI).

To understand PKI it is first important to understand the concept of asymmetric cryptography. For those not already familiar with this technology, I鈥檒l do my best to explain it here. If you have come across this concept before you might want to skip the next couple of paragraphs.

Sign up for the IP Studio Insider Newsletter:
Join our mailing list and receive news and updates from our IP Studio team every quarter.
First Name:
Last Name:
Company:
Email:
or Unsubscribe

Asymmetric Encryption

Normal 鈥渟ymmetric鈥� cryptographic methods rely on some kind of secret shared between the sender and receiver. Anyone in possession of that secret or 鈥渒ey鈥� can encrypt and decrypt messages. For the most part this is how the TLS protocol used to secure Internet traffic works. Clearly though there needs to be a way to share the secret used to encrypt and decrypt traffic in the first place.

works quite differently to symmetric cryptography. In asymmetric cryptography a pair of different but related keys are generated. A public key is generated which can safely be shared with anyone, and a private key that must be kept secret. Messages that are encrypted with the private key can be decrypted with the public key, and visa-versa. However, once a message has been encrypted with a key, that key cannot be used to decrypt it. This means that a public key can safely be published online, and be used by others to encrypt messages to send to the owner of the keys. Because only the owner of keys holds the private key, only they can decrypt these messages. This means messages can be sent encrypted without the need to share a shared secret beforehand.

Asymmetric encryption requires more compute power than symmetric encryption to send the same amount of data. Therefore TLS uses it to establish an initial shared secret which can then be used to communicate using a more efficient symmetric encryption algorithm. This is all important, but it isn鈥檛 immediately clear how it can be used to solve the problem of allowing a client to identify the server that it鈥檚 talking to. In order to understand how that works we need to introduce the concept of digital signatures.

Asymmetric encryption can be used to generate a digital signature. This allows the recipient to use the sender鈥檚 public key to verify that the party it is communicating with holds the corresponding private key. At its most basic, this simply takes the form of the sender using its private key to encrypt data known to itself and the client. The client will use the public key on the resulting message, and check it gets back to the original data. If it does, it knows that the private key that encrypted the data is the partner of the public key used to decrypt it. Often the known data is a mathematically computed digest of some larger piece of data that needs to be sent (a 鈥渉ash鈥�) - by signing this with its private key the sender allow the recipient to verify the validity of the entire message.

Public Key Infrastructure

It is this property of allowing a sender to 鈥渟ign鈥� data that is at the heart of public key infrastructure. If a client knows it has the public key of a server it trusts it can use that verify the identify of server it is talking to. Browsers and operating system vendors distribute sets of trusted public keys as part of their software. But with hundreds of millions of websites on the Internet it isn鈥檛 practical to distribute all their public keys in this way. Instead these public keys correspond to private keys held by organisations known as CAs (Certificate Authorities).

These highly trusted organisations are vetted by the browser and operating system vendors, and have to comply to strict industry rules. They hold the private keys that correspond to the keys that are publicly distributed by browser and operating system vendors to clients. They use these keys to sign digital certificates for those wishing to use TLS on their website. These certificates contain the public key of the server that will host the site, and the domain name of the site. In order to acquire a certificate the buyer must first demonstrate to the certificate authority that they own the domain, so that an attacker cannot obtain a certificate to impersonate a site they do not own.

When the client visits a site with such a certificate it is able to use the public keys it has been issued with to check that the CA鈥檚 signature is one that it trusts. If it is, it knows it may also trust the public key of the server, which is contained in the certificate. It can then proceed to check the identity of the server using the techniques described above. This process of using a central certificate authority to sign and distribute certificates is what is known as Public Key Infrastructure (PKI), and is a central pillar of cyber security.

Challenges for Broadcast

This process is well established on the web, with a large number of certificate authorities in operation. However, matters are slightly more complex on private networks, like those at the heart of IP broadcast networks. Public CAs cannot sign certificates for such networks, so mechanisms are required to carry out the role of the CA, and distribute and renew certificates and CA public keys. A wide range of technologies exist for doing this on private networks, but if we want a secure broadcast ecosystem that is still flexible and easy to configure we need to choose which of these we use carefully.

Our white paper goes into greater depth on the operation of PKI. It explores the challenges around PKI in an IP production ecosystem, and the technologies available to tackle those problems. It gives guidance on best practice for deploying PKI on private networks, and highlights technologies that will be useful in this process. This will ultimately feed into the work of the AMWA Inter-operable API Security Group, and ensure that we provide the best possible security for future broadcast systems.

We鈥檙e continuing to do more work in this area, including lots of exciting collaboration with partners across the 91热爆 and in industry. Check back for further updates soon!

91热爆

Accessibility links

Simon Rankine (MEng MIET)

Rebuild Page

Useful links

Theme toggler

91热爆