I am a pretty frequent user of LinkedIn — as I do like the style of the network much more than for example Xing, and I feel like it has a much more active community. And I get spammed a lot with advertisements about security appliance, firewall, identify management systems, and so on. But what most people do not know: Security, no matter if it is a firewall, VPN appliance or ballot system — it always starts at the firmware level. Let’s learn how to build such a system — and why security always starts in the firmware.
Security Engineers tend to speak about the chain of trust. This means that a system which has various components need to build the security on top of each other, chaining the trustworthiness through the complete system. And this chain always has a so called trust anchor, the root of trust. The root of trust is the one code block, binary or hardware part in your system you need to trust, in order to build up a chain of trust. Let’s do an example here:
First of all — there is no secure system. Security is measured in: How much effort does it take to break it. Anyways, imagine you want to build a VPN appliance. So what do wee need for this
Most people now throw these parts together, do some nice configuration in Linux so that it does only allow specific ports to pass through, no root login and your VPN appliance is good to go. But what does actually happen, from the point where the system starts booting until the application has been loaded?
Every computer always starts at the reset vector. The reset vector is a System-on-Chip specific address which points to a position with the storage, most of the time this could be a SPI flash chip, of the initial code that runs on the system, so called firmware.
The firmware will initialize most of the hardware running on your system and will jump to a bootloader, which then loads your operating system. Once your operating system has been loaded, in our scenario, the OpenVPN server will start up and provide the needed services to our clients.
So clearly the root, the beginning of the whole system is the firmware. And within the firmware we can even be more specific. The firmware consists of multiple parts. As my main area of expertise is x86 firmware, we can divide this into several stages. The first part of the code is called bootblock or security phase in UEFI. The security phase does not contain security at all, the name has been chosen unfortunate. The security phase does initialize the CPU and brings up the CPU cache as RAM, as no RAM is available yet.
The next phase is the Pre-Efi Init (PEI) or romstage. The romstage has mainly two purposes. Do additional hardware initialization and most important: bring up the RAM.
Next is the ramstage or Driver Execution (DXE) phase. The DXE phase does everything your system needs. Bring up hardware, talk to our devices in your system like the Baseboard Management Controller. Loads USB drivers if necessary and so on. We do not need to go into full detail here. After all drivers have been initialized the bootloader pops up, and start executing your operating system kernel (Yes — Windows does also have a Kernel).
The kernel basically does a lot of these steps that happened in the firmware again — especially the DXE part. Once the user-space has been loaded, the application starts up and we are good to go.
Within most systems the root of trust is just the complete firmware. As we do not really know what is happening down there, as most of it is closed source, we just have to take the firmware as one big blob which acts as our root of trust. From there where can build up a chain of trust using known techniques like UEFI Secure Boot.
#crypto #programming #computer-science #firmware #security
Security starts in your firmware — want to know why? Read it up!