Secure modules: keys and certificates in software architecture

In a time when there is an app for everything and everything can be controlled remotely from the home office, it is unthinkable to simply have physically secure systems and prevent communication with the outside world. Companies collect data centrally or outsource all software to the cloud. This applies to both classic IT as well as OT (Operational Technology) and IoT environments. Many devices and even objects have a connection to the Internet, making production plant data centrally available, for example as a digital twin, and even networking suppliers, producers and customers across industries. 4.0, which was thought to be dead, is also getting attention. Manufacturing-X New focus. EU has A legal regulation created with the EU Cyber ​​Resilience ActWhich sets the security for software within member countries and demands security by design.

Advertisement

Flow Lite Mechanical Keyboard by Lofree

Security should be at the beginning of the software design process. Attacks that exploit buffer overflow, incorrect parameter validation, or concurrency vulnerabilities are still common. When designing software teams must take such potential vulnerabilities into account in both the selection of tools and programming languages ​​as well as the architecture.

This article primarily highlights one aspect of architecture that is important for security: the correct use of cryptography. It does not prevent vulnerabilities in the code, but it protects both the data the software works with and the program itself. Thus it aims for the common security goals in IT security: confidentiality, integrity, authenticity.

Privacy means that data can only be seen by those who should see it. Privacy is traditionally created through encryption. The second security goal, integrity, ensures that the data cannot be manipulated: whoever receives the data must be able to ensure that it has not been altered en route by the sender. Digital signatures help here. Authenticity ensures that the other party in communication is who they claim to be. This prevents someone from interfering using a man-in-the-middle attack. This security goal can be implemented with cryptographically verifiable identities.

code design against manipulation

Cryptography helps many areas of software development to implement the above security goals. It can first of all secure the application itself so that attackers cannot attack its integrity by reprogramming functions or introducing malicious code and thus cannot, for example, exploit or manipulate data directly at the source.

The purpose of a digital signature is to ensure that no one has tampered with the software. To do this, the binary receives a signature with a private key, which can be verified using the public key as its counterpart. It is important that the integrity of the signature checking software is also protected. A series of tests are commonly used for this purpose. The first piece of software, the firmware, BIOS or UEFI, is checked for integrity by the hardware itself.

The firmware can then check the signature of the bootloader, which checks the signature of the kernel, which in turn ensures that the application is signed correctly. There should not be any gaps in the test chain, as this would be a gateway for attack. In systems that you can fully control, such as embedded systems, you can and should ensure that the chain is fully implemented. The only challenge there is limited hardware resources.

Certificates are often used for code design on systems that are not fully under control. The operating system does not need to know the public key as a counterpart to the private key used for signing. It only needs to be able to verify the authenticity of the certificate because the public key is part of the certificate. Such verification is done using a Certification Authority (CA). It 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. Suitable tools are also available here for developers to easily integrate code design into the development workflow. However, in other places, for example in the embedded area, but also under Linux, things look different. Unsigned binaries are often used here because the ecosystem may be missing in the operating system or development environment. Often the hardware does not have the necessary computing power or there is no way to check the firmware. This means that when it comes to software architecture, the architecture of the hardware is also important for developing secure software.

secure update

Even if you keep all the points in mind while designing the software, you cannot feel safe. Bugs are often discovered later or cryptographic processes are broken. It also happens that one later discovers vulnerabilities in protocols that were previously considered secure. That’s why it’s important to be able to update for secure software. The EU Cyber ​​Resilience Act (CRA) requires lifetime software updates for all products marketed in the EU – at least five years, unless the product’s lifespan is proven to be shorter.

While mobile apps through the App Store offer an update option just like Linux distributions, software makers have to take care of this themselves elsewhere. You must provide a process to deliver software updates (automatically) and ensure that this process is secure. Otherwise, updates are the correct target. The main thing here is to ensure integrity by getting the update signed by the manufacturer and checking this signature during the update process.

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

Beyond cryptography, the Cyber ​​Resilience Act requires Software Bills of Materials (SBOMs), which are essential to secure design and show what components have gone into the software to check against known vulnerabilities. Ultimately, the software manufacturer is responsible for providing a secure update path. He cannot trust public repositories over which he has no control.

The function of software architecture is to check security gaps and sign binaries, containers and modules, until they are available in signed form in trusted public repositories. Above all, it must be ensured that the system only executes those components whose signature has been previously checked.