One of the trending security threats according to OWASP is related to supply chain security, which involves every component that developers use to build applications.
In the end, it is important to use high-quality components, produced by trustworthy organizations and constantly maintained to fix security flaws.
The problem is that organizations increasingly use open-source code, which does not always have the properties mentioned above, exposing individuals and organizations to security risks.
The outstanding question is how organizations can use and trust open-source software.
This post will not answer this question, but it takes us back a little into the past, when UEFI replaced BIOS in our computers (2005), giving us a glimpse of how simple concepts can help increase confidence in the software we are executing.
When the power button of a computer is pressed, the first thing that wakes up is a small chip soldered onto the motherboard that contains firmware responsible for locating a bootloader.
A bootloader is a small piece of software responsible for initializing the hardware (disk, RAM, etc.) and loading the operating system kernel into memory so that the OS can start.
We can already identify three components, UEFI → bootloader → kernel, that need to be executed in order to boot a computer.
Before UEFI computers used BIOS, which did the same job with more limitations but essentially without verifying the provenance of the bootloader or kernel, leaving the door open to dangerous malware such as rootkits.
The problem that the industry needed to solve was to find a way to verify that when you want to install a linux distribution in your computer, the software that is running is trusted by UEFI.
These types of challenges can be addressed using public-key cryptography. Essentially, whoever creates the software (bootloader, kernel) generates a pair of public and private keys.
The creator uses the private key (which remains private to them) to sign the software and distributes the public key to say: “Hey, you can verify that this software was created by me using this public key”
Usually, UEFI has a very limited set of public keys that it trusts (Microsoft, for instance), so if the software is signed by Microsoft, it can use the public key available in its super small “database” to verify the origin of the bootloader.
But what should be done in the case of Linux? UEFI is firmware that resides on a small chip on the motherboard, and it would not be feasible to add public keys for all the different Linux distributions.
Essentially, there is a trust gap between motherboard manufacturers and Linux organizations.
How was this solved? They all agreed to trust one universal key: the Microsoft UEFI CA key. Linux distributions create a file called SHIM that contains their public key. They send this file to Microsoft only once, which signs it, and the Linux distribution integrates this file into the bootloader. At this point, UEFI checks this file. It can trust it because it recognizes the Microsoft public key and obtains the bootloader’s public key from SHIM. It can then verify the bootloader code signed by the Linux distribution.
This describes how it works a simple but powerful chain of trust that works regardless of all technical and organizational limitations.