Articles in this series:

Modern IT networks are divided into two sections: the data plane and the control plane. Although these are often more of an abstraction than physical separation, the concept of the division helps enormously with security.

The data plane provides the actual transfer of datagrams across the network and may be thought of as the switch or router fabric. And the control plane provides the management and orchestration where user roles and access to storage and applications are set.

Separating Data From Control

Software Defined Networks (SDN) often use this topology to facilitate manual routing and monitoring of a network. By separating the data and control plane, management systems have much more freedom for control.

This may be a relatively new method of working for the IT industry, but broadcasters have been working in this way since NTSC, PAL, and analog switchers were first used. An SDI router has a control and a data plane. The control plane is governed by the selection and routing panels, and the data plane is provided by the X-Y matrix cards in the SDI router.

In the SDI analogy, security is provided during system installation and programming to stop certain routings taking place. For example, the VT operator will be unable to route bars and tone to an outgoing line, whereas the MCR operator will have this option, albeit heavily guarded!

NMOS uses a similar configuration with the APIs providing the control plane and the network switches and cables providing the data plane. During registration, a camera connected to the network announces its presence to the registration and discovery system through a node API call. Alternatively, devices can request information from the registration and discovery server, which could be a list of the connected devices, or device labels.

Securing APIs

The APIs are the core of the NMOS system control plane and consequently must be protected from malicious actors. It’s also worth remembering that security isn’t just about hackers and bad people, it’s also about protection from mistakes. Even the most experienced technologist makes errors, and without adequate protection it would be all too easy for somebody to route bars and tone to the program output.

Through its document “BCP-003-01 Secure Communications in NMOS Systems”, a series of best practices are provided to help keep systems secure. The key objectives are to maintain confidentiality, validate server identification, confirm messages have not been tampered with, and guarantee the message came from the validated server.

The API call uses a REST type command structure similar to the protocols used in web page services. Consequently, NMOS takes advantage of many of the web page type communications protocols as well as some of its security implementations through commands such as GET, POST, and DELETE.

HTTPS (HTTP Secure) is often associated with serving web pages as it reduces the risk of man-in-the-middle attacks. If only the HTTP protocol was used (without the Secure), an infiltrator masquerading as the Registration and Discovery server could intercept the messages between the broadcast devices and potentially take control of them.

Adding the HTTPS protocol reduces the risk of this happening as messages are encrypted using the TLS (Transport Layer Security) protocol (RFC 8446). The TLS protocol allows two devices, such as a camera and the Registration and Discovery server to initially negotiate a protocol version, select an encryption algorithm, authenticate each other, and establish a shared secret key. After which, the two devices can freely exchange encrypted data between each other. Both parties can be certain no man-in-the-middle attack has taken place and that the messages haven’t been tampered with.

Authentication Certificates

The man-in-the-middle attack is thwarted by the concept of encrypted authentication certificates. An HTTP server, such as the Registration and Discovery server will require the installation of an authentication certificate issued by a trusted certification authority (CA) like IdenTrust or Amazon Root. As part of their due diligence, the CA will confirm the certificate requester is who they say they are, then encrypt their details into a certificate using the CA’s own private key.

When a browser or TLS initiates a session with the HTTP server it will request the encrypted certificate and validate it using the CA’s public key. The certificate is then opened and validated, thus confirming the browser or TLS session are communicating with the server they expect and not an intruder.

NMOS does allow for self-signed certificates to be used between clients and servers if a certificate cannot be provided by a CA. However, they do advise that this approach should be restricted to a small number of devices such as connecting a camera and control unit. The self-signing system does not scale well as certificate management becomes incredibly difficult and a significant overhead.

Although TLS confirms the server authenticity, practical systems also require end-users, such as a control panel, to have restricted access to APIs and limit the functionality of the API. This is achieved through user authorization using OAuth 2.0 access tokens.

Access Tokens

OAuth 2.0 (RFC 6749) requires a separate authentication server that can validate a user and assess their read and write access to the system. A VT control panel will have a subset of the available source and destination routing of the MCR control panel, and this restriction will be defined by the system administrator. This access and authentication information is embedded within the OAuth access token.

The authentication server issues the access token (a block of data) that the client uses when initiating a request with the NMOS servers. The code is unique, and encrypted and embedded within it is a code which the OAuth client decodes so that it can provide the appropriate access for the device.

The OAuth method provides additional security for API calls as it stops malicious users from gaining access to key components within the system and manages access for authenticated users. In this context, a user may well be a person, but also a device, such as a camera, or control panel. OAuth negates the need for a physical device to enter credentials as the access token can be stored in the device itself and pre-authorized by the authorization server.

As well as providing interoperability between media devices for IP systems, NMOS also contains infrastructure and protocols to improve security and reduce the risk of costly operational errors.