Windowshardware requirements have always
promoted confusion, and this timeis no different...
WHEN WINDOWS 8 was announced, there was a concern
that Microsoft would use Secure Boot, an optional
feature of the then-new UEFI (Universal Extensible
Firmware Interface), to restrict the installation of other
operating systems. Secure Boot only allows booting
EFI images that have been signed by a key enrolled in
the UEFI. Since almost all hardware ships with a public
signing key from Microsoft, it’s easy to see where this
concern came from. However, to help Linux distros
(or any software that needed its own bootloader) deal
with Secure Boot, Microsoft used its magic key to sign a
small program (they probably wouldn’t sign something
big and complicated) called Shim.
Shim is a first-stage bootloader used by many
distros (including Debian and Ubuntu) to launch their
own (second stage) bootloaders. Secure Boot works
by each stage checking the signature of the following
one before executing it, establishing a root of trust back
to the original signing key. So distributions can embed
their own keys into Shim, and have this distro-specific
Shim package signed by Microsoft.
Shim can then check the GRUB EFI image, signed
by the distro key, and boot can proceed. It’s possible to
sign kernel images too, as well as subsequently loaded
modules and firmware, so if you trust cryptography
and the Microsoft Signing Authority, then Secure Boot
makes it really hard for malware to be loaded anywhere
in the early boot process.
A QUESTION OF TRUST
Of course, not everyone’s going to trust Microsoft, or
indeed Secure Boot. And that’s okay, because in
2013 when Microsoft stipulated that “Windows
8 Ready” hardware should ship with Secure
Boot enabled, it also made the provision that
it should be possible to disable it,
and also that it should be possible
for users to install their own MOKs
(Machine Owner Keys) and use them
to sign whatever bootloader they
wanted, so that ultimate trust, but also
ultimate responsibility, lay with the user.
“Windows 10 Ready” hardware was subject
to similar conditions, except the requirement that
Secure Boot is mutable was reduced to a suggestion.
Still, we’ve never come across a single Windows 10
machine where Secure Boot could not be disabled. And
if you build your own systems, then you have nothing to
worry about.
The “Ready” conditions are for OEMs that ship
systems with the OS already installed. With Windows
11 upon us, it’s no longer Secure Boot clauses that are
being scrutinized, but those relating to TPM chips.
PLATFORMS, TRUSTED
PLATFORMS AND WINDOWS 11
Trusted Platform Module (TPM) chips are tiny
processors that have a small privileged memory store,
which applications can use to store keys, authentication
data, or anything that they don’t want other applications
nosing at or tampering with. Besides the minimum
hardware specifications, for a PC to officially support
Windows 1 1, it must also support TPM 2 .0. At the
moment, it’s still possible to install Windows 11 via the
official ISO if your device doesn’t meet the TPM (or other)
requirements, but Microsoft says such installations are
unsupported and may not be privy to security updates
down the line. Indeed, we have seen builds of Windows
11 running on a Pi 400, as well as a Nokia Lumia 950XL,
one of the last devices to run Windows Phone.
GIVE ME ALL YOUR TPM
TPM chips have been around for most of the past decade. TPM 2 .0 was
introduced in 2014 , and most motherboards from 2016 onwards include
one. TPM can be implemented in firmware too (so-called fTPM), at a
slight cost to security, since some new Spectre/Meltdown-type attack
could, in “theory”, be leveraged against it.
Still, fTPM is good enough for Windows 1 1’s requirements. You might
need to enable TPM via the UEFI (classic BIOS is also not supported),
where it goes by so many names that Microsoft made a friendly help
page (see https://bit.ly/lxf282-mshelp-tpm2)
TPM is fully supported on Linux and can be used to secure SSH keys
(see http://blog.habets.se/2013/11/TPM-chip-protecting-SSH-keys---
properly), unlock LUKS encrypted volumes (via systemd-cryptenroll or
Clevis) or even make Secure Boot even securer (https://threat.tevora.
com/secure-boot-tpm-2). There are separate software stacks for TPM
1.2 (TSS aka TrouSerS) and TPM 2 .0 (tpm2-tools), and there’s a nice
summary of both on the Arch Wiki page at https://wiki.archlinux.org/
title/Trusted_Platform_Module.
Tiled start
menus and
the Windows
desktop may
bring you no
joy, but look
JAN 2022 MAXIMUMPC 35
©^
MI
CR
OS
OF
T
