When a general user enables his laptop or desktop, there's often happens a question - is the current OS secure? Or maybe some core files were replaced by hackers and after load your device will open a backdoor to bad people or even be transformed in part of botnet? What if the Trojan horse already inside? Well, a limited quality of paranoia can be helpful sometimes. There's must be some control of chain hardware-bootloader-core files to prevent modifying them and easy "enemy" detection. Package management mostly supports checksum verification and can replace bad or just broken file or several files, but it can be too late - file verification will be skipped one time (you can't do it several times per day, right?) and bum! OS was already loaded and yet another cryptolocker started to encrypt all files and will ask for money in a minute - too late to verify files with software manager now. Let's dig deeper and figure out what can be done to prevent this type of attack and many more.
Developed by: Microsoft
The UEFI Secure Boot designed to do code verification and make sure all code launched by UEFI is trusted. Surprisingly, the name is very clear: it makes OS boot secure by checking files signature and checksum, before the OS loading - to make sure no malicious code will be used. The signing key can be a hardware vendor key, Microsoft's key or user or corporation key, verified by Microsoft or another hardware vendor. In paranoid mode, a user can upload his own key and sign his files, without relying on evil corporations like Microsoft. Another people probably don't like idea to pay for Microsoft key for securing his machine boot process - you don't need to do it!. Secure boot can be enabled or disabled by user, some people were scared about MS vendor-lock 'cause most devices coming with preloaded MS keys, signed by MS. If you want to deal with Secure Boot - you also need a bootloader supporting it: a lot of troubles happened in Linux distribution world in 2012, part of them like Fedora and Ubuntu have implemented them sooner, second part - later and forums were full of Secure Boot issues. Funny enough, GRUB2 still doesn't support it directly and use another primary bootloader called
Secure boot fear: I don't want to use it 'cause NSA will steal all my files! Will stay on BIOS forever!
Well, it's not going to happens in real life. UEFI is proprietary, yeah, but BIOS isn't open source too - no advantages here. Coreboot is an open source bootloader, but hardware support is quite limited. If you don't buy any cheap no-name Chinese hardware - your Secure Boot will work as expected in most cases, chances to hack it are very low 'cause UEFI network access is mostly disabled and there are many software realizations - creating a universal "UEFI-virus" is hard task.
How to manually generate the key on Linux
- First, we need a tool called
mokutil, a part of shim bootloader. Let's verify if OS is already booted via Secure Boot:
sudo mokutil --sb-state || bootctl status
- Now we should enable it in UEFI interface. The second tool also required -
openssl. Generated keys will be available in
/var/lib/shim-signed/mok/directory, we probably need to create it.
mkdir -p /var/lib/shim-signed/mok/
- Are you ready? We can generate it right now!
sudo openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -days 36500 -subj "/CN=Glorious Nix User Inc./"
sudo openssl x509 -inform der -in MOK.der -out MOK.pem
- Use the generated key to sign a kernel:
sudo apt install sbsigntool # another tool we need
sudo mokutil --import MOK.der
sudo dmesg | grep cert # verify the key
sbsign --key MOK.priv --cert MOK.pem "/boot/vmlinuz-$VERSION" --output "/boot/vmlinuz-$VERSION.tmp"
sudo mv "/boot/vmlinuz-$VERSION.tmp" "/boot/vmlinuz-$VERSION"
Sign kernel modules:
for i in *.ko
do sudo --preserve-env=SIGN_PIN_CODE /usr/lib/linux-kbuild-$VERSION/scripts/sign-file sha256 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der "$i"
Secure boot can also be disabled in OS:
sudo mokutil --disable-validation
sudo mokutil --enable-validation
Some possible issues Secure Boot can cause:
- Hibernation can be broken
- NVIDIA drivers and any out-three Linux drivers should be signed too, after each update
- User-space access to RAM and I/O ports is limited
- Custom ACPI tables and methods are not supported
kexecboot of unsigned kernel isn't supported
For better security after Secure Boot activation
- UEFI must be updated regularly and protected with strong password
- Do not use default vendor keys, generate new ones
- Full disk encryption
- Enable TPM or TPM2
2022 update - Microsoft requirement for the 3rd Party Certificate to be disabled by default
Microsoft started to enforce his certificate business, so third-party certificates not in priority anymore. Funny enough, these requirements aren't publicly available. This fact went to public only 'cause Lenovo document. Check Matthew Garrett's post for more details.
TPM - Trusted Platform Module
Developed by: Trusted Computing Group
TPM is a standard (ISO/IEC 11889) for dedicated secure cryptoprocessor, which realized in form of microcontroller and developed by Trusted Computer Group - organization, created from Microsoft, Intel, AMD, IBM, and Cisco members. The hardware implementation is often called TPM too. TPM v1.2 specifications are located here, TPM v2 specs are here. The chipset can be discrete or integrated into a main board. Some software realizations can be built-in inside firmware. Mostly the software is closed source, but Intel in 2018 released TPM2 source code under BSD license.
TPM can be used for DRM protection, Windows services like Defender and Domain. TPM2 is the hardcoded requirement of Windows 11 and used for defense against firmware and ransomware attacks.
Probably the most popular usage case is controlled integrity. Not very superior in for general home usage with 1–2 machines, but makes difference in corporate environment.
Was configuration changed and when? Is firmware broken? Was the same computer authorized last week in corporate server with logs archive? Was UEFI configuration changed? And many similar cases.
For non-enterprise cases TPM can be useful with its secure storage (Microsoft Office 365 and Windows license management) and changes detection like LUKS (Linux Unified Key Setup), MS Bitlocker etc. Cold boot attacks can be used against machines which were powered off for a long time, and extracting keys from TPM storage is very easy.
What's under the hood? Several components:
- Random number generator, dedicated power source is helpful here.
- Cryptographic keys generation facilities
- Remote attestation with static hash key of hardware ID's, good for hardware and software changes detection
- Binding - data encryption with unique RSA key located in built-in storage
- Sealing - similar to binding, but with TPM state
- another built-in decryption functions
On Linux TPM2 can be accessed via
/dev/tmp0 and managed through
/dev/tpmrm0, also TPM2 is compatible only with UEFI.
The TPM version available in
Developed by: Microsoft
MS Pluton is a cryptoprocessor chip (like TPM) created by Microsoft, now available in AMD hardware. Unlike TPM, Pluton was created only by Microsoft and, being honest, many people including me don't want to use a processor created by Microsoft :) Several security & cryptography professionals says it's safe for now, but let's dig deeper (again!) and figure it out.
So, Pluton is a microprocessor with his own secure storage and hardware cryptographic functions, just like TPM. Even more, Pluton can work in TPM mode. Check this slide series for details, and not much more details available. So, Pluton is much more closed than TPM and designed for use inside the main chipset. And much more integrated with CPU, so cold boot attacks and physical attacks are much harder with enabled Pluton.
Pluton can be shipped in three main configuration:
- security processor
- TPM module
- turned off by OEM
The main concern is remote attestation: can Microsoft track online a computer with enabled Pluton? So for now this is impossible 'cause Pluton can't do it by itself, without OS.
Another red flag - the Pluton firmware updates, with full control by Microsoft. This is the critical part of hardware, and MS history is full of security failures. And remember who owns the most popular operating system and increasing PC control every time, cover it with "better security" label?