Secure modules: Keys and certificates in the software architecture

Contents

In times when there is an app for everything and everything can be controlled remotely from the home office, it is unthinkable to only physically secure systems and prevent communication with the outside world. Companies collect data centrally or outsource the entire software to the cloud. This applies to traditional IT as well as OT (operational technology) and IoT environments. Many devices and even objects are connected to the internet, production facilities make data available centrally, for example as a digital twin, and even Industry 4.0, which was thought to be dead for networking suppliers, producers and customers, is receiving new attention with Manufacturing-X. With the EU Cyber Resilience Act, the European Union has created a legal regulation that prescribes security for software within the member states and demands security by design.

Security must be at the beginning of the software design process. Attacks that exploit buffer overflows, incorrect parameter validation or vulnerabilities in concurrency are still commonplace. Teams need to consider such potential vulnerabilities at the software design stage, both in the selection of tools and programming languages and in the architecture.

This article focuses on one aspect of the architecture that is important for security: the correct use of cryptography. It does not prevent vulnerabilities in the code, but protects both the data with which the software works and the program. It is therefore aimed at the usual protection goals in IT security: Confidentiality, integrity, authenticity.

Confidentiality means that data can only be seen by those who are supposed to see it. Confidentiality is classically achieved through encryption. The second protection objective, integrity, ensures that the data cannot be manipulated: Whoever receives the data must be able to ensure that it has not been altered in transit by the sender. Digital signatures help here. Authenticity ensures that the other party to the communication is who it claims to be. This prevents someone from intervening by means of a man-in-the-middle attack. This protection goal can be achieved with cryptographically verifiable identities.

Codesigning against manipulation

Cryptography helps to implement the aforementioned protection goals in many areas of software development. Firstly, it can protect the application itself so that attackers cannot attack its integrity by reprogramming functions or introducing malicious code and thus tapping into or manipulating data directly at the source, for example.

Digital signatures are intended to ensure that no one has manipulated the software. To this end, the binary is given a signature with a private key that can be verified using the public key as a counterpart. It is essential that the integrity of the software that verifies the signature is also protected. A chain of checks is usually used for this purpose. The first part of the software, the firmware, the BIOS or UEFI, is checked for integrity by the hardware itself.

The firmware can then check the signature of the boot loader, which checks the signature of the kernel, which in turn ensures that the application is correctly signed. There must be no gaps in the check chain, as this would be a gateway for an attack. In systems that can be fully controlled, such as embedded systems, you can and must ensure that the chain is fully implemented yourself. The only challenge there is the limited hardware resources.

On systems that you do not have complete control over, certificates are often used for code signing. Here, the operating system does not need to know the public key as the counterpart of the private key used for the signature. It only needs to be able to verify the authenticity of the certificate, as the public key is part of the certificate. Such verification is carried out by a certificate authority (CA). This acts as a trusted third party that has signed the certificates so that the validity of the certificates can be checked using the CA's public key.

On Windows, macOS, iOS and Android, unsigned binaries cannot be executed without explicit confirmation. The appropriate tools are also available here for developers to easily integrate code signing in to the development workflow. However, the situation is different in other areas, for example in the embedded sector, but also under Linux. Unsigned binaries are often still used here, as the ecosystem may be missing in the operating system or development environment. The hardware often does not have the necessary computing power or the ability to check the firmware. This means that the architecture of the hardware is also crucial for the software architecture in order to develop secure software.

Secure updates

If you take all points into account when designing software, you still can't rest assured. Bugs are often discovered later or cryptographic procedures are broken. It also happens that someone discovers weaknesses in protocols that were previously considered secure at a later date. It is therefore essential for secure software to be able to carry out updates. The EU Cyber Resiliance Act (CRA) requires lifelong software updates – for all products marketed in the European Union for at least five years, unless the product's lifetime is proven to be shorter.

Obligations of manufacturers in the EU Cyber Resiliance Act
Protection goals	Protection of the confidentiality of data through encryption with state-of-the-art mechanisms, protection of the integrity of data, commands, programs and configurations against manipulation, protection against unauthorized access through authentication, identity or access management systems, availability of essential functions, including the ability to defend against and contain denial-of-service attacks.
Security by default	Delivered with a secure default configuration, with option to reset to this configuration. Processing must be limited to data that is appropriate and relevant for the purpose.
Security by design	Minimization of own negative impact on the availability of services of other devices or networks, minimization of attack surfaces including external interfaces, implementation of suitable mechanisms to minimize the potential impact of an incident.
Monitoring	Logging security-related information and relevant internal processes (e.g. access to and changes to data, services or functions).
Security updates	Regular security updates to eliminate vulnerabilities, including automatic updates if necessary.

While mobile apps can be updated via the App Store, just like Linux distributions, software manufacturers have to take care of this themselves in other areas. They must provide a process for (automatically) distributing software updates and ensure that this process is secure. Otherwise, updates are the perfect target for attack. The most important thing here is to ensure integrity by having the manufacturer sign the updates and verifying this signature during the update process.

Many libraries are also often used in software development. The development team is therefore also a consumer of content and must ensure secure integration. It must not simply integrate a container from Docker Hub or a module from a random registry, but must ensure that authenticity (where does the library come from?) and integrity (has it not been manipulated?) are guaranteed.

Beyond cryptography, the Cyber Resilience Act requires Software Bills of Material (SBOM), which are essential for secure design and indicate which components have been incorporated into software to test it against known vulnerabilities. Ultimately, the software manufacturer is responsible for providing a secure update path. They cannot rely on public repositories over which they have no control.

It is the task of the software architecture to check binaries, containers and modules for security vulnerabilities and to sign them without exception, unless they are available in signed form in public, trustworthy repositories. Above all, it must be ensured that the system only executes components whose signature has been checked beforehand.