posts/secure_boot.md

@@ -66,11 +66,11 @@ system, and user data is at risk from possibly any tainted userland executable.
 Nevertheless, ANSSI, the French Infosec Agency recommends in its GNU/Linux
 security guide[^linuxguide] to enable Secure Boot (R3) for all systems
 requiring medium security level (level 2 out of 4, 1 being the minimal
-requirements and 4 being for highly secure systems). Meanwhile, using a Unified
+requirements and 4 being for highly secure systems). Meanwhile, using a Unified
 Kernel Image to bundle the Linux kernel with a initramfs into a single
 executable that can be verified by Secure Boot is only recommended[^R6] for
 highly secure systems (security level 4 out of 4). No recommendation is ever
-done about using one of the aforementioned integrity features to ensure
+done about using one of the aforementioned integrity features to ensure
 operating system integrity.
 
 [^linuxguide]: no English version yet. [French version](https://www.ssi.gouv.fr/uploads/2019/02/fr_np_linux_configuration-v2.0.pdf)
@@ -84,7 +84,7 @@ level, and 45% even think that it should be a minimum requirement.
 This article is a strong push-back against ANSSI "recommendation", and it
 attempts to prove that it is not only useless but incoherent and misleading.
 
-[^poll]: [Mastodon poll](https://infosec.exchange/@x_cli/109348532363333158)
+[^poll]: [Mastodon poll](https://infosec.exchange/@x_cli/109348532363333158)
 
 ## Signature verification and default public keys
 
@@ -98,21 +98,21 @@ in the recent past (e.g. CVE-2020-10713[^CVE-2020-10713],
 CVE-2022-34301[^CVE-2022-34301], CVE-2022-34302[^CVE-2022-34302],
 CVE-2022-34303[^CVE-2022-34303].
 
-[^CVE-2020-10713]: [CVE-2020-10713](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10713)
+[^CVE-2020-10713]: [CVE-2020-10713](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10713)
 
-[^CVE-2022-34301]: [CVE-2022-34301](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34301)
+[^CVE-2022-34301]: [CVE-2022-34301](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34301)
 
-[^CVE-2022-34302]: [CVE-2022-34302](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34302)
+[^CVE-2022-34302]: [CVE-2022-34302](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34302)
 
-[^CVE-2022-34303]: [CVE-2022-34303](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34303)
+[^CVE-2022-34303]: [CVE-2022-34303](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34303)
 
 For this reason, many software still require that Secure Boot be deactivated,
 including firmware updates by some manufacturers, including
 Intel[^intelUpgrade] or Lenovo[^lenovoUpgrade].
 
-[^intelUpgrade]: [Intel UEFI Flash BIOS Update Instruction](https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/UEFI-Flash-BIOS-Update-Instructions.pdf)
+[^intelUpgrade]: [Intel UEFI Flash BIOS Update Instruction](https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/UEFI-Flash-BIOS-Update-Instructions.pdf)
 
-[^lenovoUpgrade]: [Lenovo flash BIOS with UEFI tool](https://support.lenovo.com/us/en/solutions/ht118103-flash-bios-with-uefi-tool-ideacentre-stick-300)
+[^lenovoUpgrade]: [Lenovo flash BIOS with UEFI tool](https://support.lenovo.com/us/en/solutions/ht118103-flash-bios-with-uefi-tool-ideacentre-stick-300)
 
 Grub and the kernels are not directly authorized by Microsoft, as it would
 require for each and every single version to be signed individually by
@@ -125,7 +125,7 @@ used to verify these executables is not directly under the control of
 Microsoft. These public keys are either built in Shim itself or stored in a EFI
 variable serving as a database.
 
-[^shim]: [shim source code](https://github.com/rhboot/shim)
+[^shim]: [shim source code](https://github.com/rhboot/shim)
 
 Additionally, shim public key list can be altered by any user able to prove
 "presence". This is the case of any user using the local console or using a BMC
@@ -139,17 +139,17 @@ the system believe that Secure Boot was used to bootstrap security, while
 untrusted code was ultimately run within the UEFI privileged mode.
 
 Hence, thanks to shim, just about any signed or unsigned, trusted or untrusted
-executable can be validated by proxy by Secure Boot using Microsoft keys. 
+executable can be validated by proxy by Secure Boot using Microsoft keys. 
 
 And this conclusion signs (pun intended) the second incoherence in ANSSI
 recommendations. Indeed, they recommend replacing Microsoft keys by our own set
 of keys only for highly secure security level (R4). This means that all systems
-with intermediate (2/4) and enhanced (3/4) security levels will have the false
+with intermediate (2/4) and enhanced (3/4) security levels will have the false
 sense of security of running Secure Boot while exposing themselves to attackers
 capable of proving "presence".
 
 For what it is worth, shim does provide a way secure all operations, including
-disabling verification or enrolling new keys by setting a password on shim's 
+disabling verification or enrolling new keys by setting a password on shim's 
 MOK (Machine Owner Keys) Manager[^mokpass]. However, the feature is mostly
 unused because no Linux distro enables it (it requires user interaction during
 the boot procedure) and system administrators often mistake the MOK Manager
@@ -158,10 +158,10 @@ password that is asked when running mokutil commands (including `--import` and
 `--disable-verification`), which is just a password used to confirm the will of
 the user in the MOK Manager. The author of this article failed to find a single
 tutorial or article discussing the necessity of setting a MOK Manager for a
-Secure Boot. ANSSI also failed to recommend that. Most interestingly, setting a
-MOK Manager password is recommended even for Windows administrators that have
+Secure Boot. ANSSI also failed to recommend that. Most interestingly, setting a
+MOK Manager password is recommended even for Windows administrators that have
 no intention of ever running Linux, because MOK Manager is one of
-the executables signed by the Microsoft keys.
+the executables signed by the Microsoft keys.
 
 [^mokpass]: The command is `mokutil --password`. Please consider using it.
 
@@ -169,7 +169,7 @@ the executables signed by the Microsoft keys.
 
 Since replacing the Microsoft keys and signing only authorized binaries (i.e.
 our own Unified Kernel Image and specifically not shim) is an option, why not
-do that? It just requires that the system administrators replace the Secure
+do that? It just requires that the system administrators replace the Secure
 Boot keys. The question of who controls the private key and the signature
 process is entirely up to whether the signed executable is altered or not by
 the system administrator. Distros could ship public keys and Unified Kernel
@@ -186,7 +186,7 @@ First, as mentioned earlier, the only thing that we verified is that the
 Unified Kernel Image is authentic. That kernel must then verify the operating
 system to ensure that only verified software is run. This requires
 cryptographic verification of every single executable (binaries, scripts and
-executable configuration files (because... yeah... that's a thing)) in the
+executable configuration files (because... yeah... that's a thing)) in the
 operating system. This can be achieved if we, at minimum, do the following:
 
 * use a read-only filesystem for our partitions containing executable code,
@@ -222,7 +222,7 @@ of physical access or remote access through a BMC, what is? Is there a better
 solution?
 
 Well, to the best of the author knowledge, there is one: using a TPM. Using a
-TPM will not necessarily prevent an attacker from tainting the firmware. It
+TPM will not necessarily prevent an attacker from tainting the firmware. It
 will not necessarily prevent booting untrusted and unverified executables. What
 a TPM can give us is the ability to unseal a LUKS passphrase and get access to
 user data if and only if the cryptographically verified right version of UEFI