What is ConCert?​

ConCert is a Certificate Lifecycle Management System (or CLMS).

• A system to monitor, update, and deploy certificates to broadcast systems.
• A proof of concept how a CLMS for broadcast could look like.
• A first step to an automated process.
• A software building block to learn, to integrate and to gain experience.

Time for Action​

Technical staff in broadcast and media facilities need to act now. Here ist why:

• In 2029, all major web browsers will only accept HTTPS certificates that are valid 47 days or less.
• Most broadcast systems – both hard- and software – use web sites for user control and APIs for system integration. Both connections need secure communication – that means using certificates.
• Currently, many broadcast systems lack functions and/or hardware ressources to deal with certificates in a flexible and automated way.
• So we need: Automated Certificate Lifecycle Management.

Background​

The topic is complex and sometimes tedious. However, it is no option to ignore this. Here are som e points to give you an overview:

The state of the control interface​

1. Almost all media technology systems have some sort of control interface. There are still a few GPIOs, serial ports and CAN interfaces around, but in general control and status signals use Ethernet and TCP/IP.
2. On IP, there are specific protocols tied to certain devices or vendors. Also, there are several "standard" protocols in use like ProBel or Ember+. These have been around for long, are used a lot and are well understood. However, they mostly lack a very important feature: SECURITY.
3. Current systems mostly use web UIs for users interactions (no more hardware knobs necessary) and APIs (REST, SOAP, gRPC,…) over TCP/IP.
4. To secure things, communication is encrypted, mostly using TLS (the Transport Layer Security protocol). For this to work properly, Certificates are needed.
5. Certificates must be renewed in regular intervals. It is no option anymore, to do this manually!

Certificates in a nutshell​

A certificate as such is just a "digital token" which is signed by a trusted entitiy. This entity is called Certification Authority (or CA for short). If a system A presents this token to a system B, B will verify this token before starting further communication.

As an example, system A is the control system and system B is an audio mixer which A wants to remote control.

The communication process works this way:

1. System B creates an internal certificate to proof its own identity.
2. It uses a process to have this certificate signed by a Certicication Authority (CA). That way the CA approves, that system B is really the system it pretends to be. In this process, system B creates a Certificate Signing Request (CSR) which it sends to the CA.
3. The CA checks the request. If it approves the CSR, the CA signes it and sends it back to system B. System B now has a certificate validated and signed by the CA.
4. System A connects to system B. System B presents its signed certificate.
5. System A verifies the certificate presented by system B. It can do this, because it has the certificate of the signing CA in its internal memory (or "rucksack").
6. Now system A is safe that system B is the right one.
7. Both systems create a session key which is than used to encrypt further communication.
8. Now some sort of Authentication process runs to make sure that system A is really allowed to control system A. Usually system A presents a token containing a shared secret which is checked by system B.

When all these steps are done without error, system A cann indeed control system B.

Certificate Challenges​

The process described is very simplified, but gives you the main idea. To have this work in practice, there are several challenges:

Certificate Chain: The broadcast organisation needs to have a proper inhouse CA to manage the certificate signing flow for all applications.

Certificate lifetime: Certificates have two dates built in "Do Not Use Before" and "Do Not Use After". If the system clock of system A or B is out of this range, no connection is established. If the system clocks are ok, certificates will become invalid at a certain date. As a result, certificates in devices need to be renewed in regular intervals.

Updates in Cryptography: The whole "certificate universe" relies heavily on advanced crypto algorithms. Over time, these algorithms are updated and sometimes become incompatible with older software version. Also, some algorithms are retired after some time, because their mathematics and/or implementation is not secure anymore when technology advances. In such cases, the crypto code in all participating systems needs to be updated. This process is calles Crypto-Agility and has its own challegenges.

Automation: Usally it is no option, to renew certificates manually. This process is time-consuming and error-prone. Unfortunately, most broadcast systems have no or very individual ways to handle their certificates. A CLMS solution must adapt to this specialized environments. (See next section for details.)

Broadcast Equipment and Certificates – the Real Challenge​

Let's face it: Most of the developments around certificates are driven by two main factors: The big world of services and systems on the open Internet and the other big world of Enterprise IT. Since broadcast equipment has moved from specialized hardware devices to mostly IT based systems, it has to follow the development there and to adapt it to the special situation in the media industry.

In this context, there are some special things to consider:

Lack of functions for certificate handling in hardware systems​

Broadcast systems are specialized equipment, often they are a combination of signal processing hardware and IT based control system. However, like most systems they have web interfaces, APIs and use TLS communication. For pure "server systems" like SRT Gateways, CMS systems and the like this is no issue. These systems have enough hardware ressources to be flexible when it comes to certificate processing. Embedded systems like audio mixers, video encoders and decoders are different. They have limited hardware ressources in their controller units - mostly this affects RAM and CPU power. As a result, certificate handling is limited oder just not there at all. In the latter case, API-gateways (or proxies) are the only way out of this.

Long living hardware​

Compared to standard IT hardware, broadcast hardware tends to have a longer "technical live". That means, that the limitations described above are also there for a long time. As cryptographic algorithms move on, it is likely that some systems will not be able to keep up.

No standard for certification handling​

The two current standards for automatic certificate update – ACME and EST – are seldom supported by broadcast devices. Instead, there are many different options for certificate handling. Most systems support some sort of manual upload. Even if there are API routes, there is no standard to that. A broadcast CLMS therefore needs adaptions for each new device.

Special requirements for update schedules​

With standard IT systems, certificate updates are no big deal. Sometimes some services need to be restarted after an update, but rarely the whole computer is rebooted. Broadcast systems are different. Often a certificate update requires a system reboot, which in turn cuts running audio and video signals. Sometimes the current system configuration needs to be restored after the reboot. Also a reboot can take several minutes until the system is operational again. This situation requires a CLMS to schedule automated certificate updates to planned downtimes or use manual triggering of the update.

Conclusion & ConCert​

If you read until here, congratulations! If you now have the impression, that the topic is complex, sometimes tedious but absolutely necessary – you are right. There is no alternative to automated certficate updates - and the issue is even more complicated in the realm of broadcast systems.

This is where ConCert will help you: It provides the first building blocks towards an integrated solution for certificate updates on broadcast systems. There is no quick solution to this challenge - it is more a long road trip than a quick sprint. If you would like to start this now, please get in touch. We will try to help you to get started.

Please get in touch with us at concert@treetop.de.