Commit c424c90c authored by Peter Senna Tschudin's avatar Peter Senna Tschudin

Fix typos

Fix typos of the word Mitigation. Also ran aspell and fixed other typos
such as Apertis instead of apertis and Linux instead of linux.
Signed-off-by: Peter Senna Tschudin's avatarPeter Senna Tschudin <peter.senna@collabora.com>
parent c94dacbc
......@@ -12,14 +12,14 @@ For both privacy and security reasons it is important for modern devices to
ensure that the software running on the device hasn't been tampered with. In
particular any tampering with software early in the boot sequence will be hard
to detect later while having a big amount of control over the system. To solve
this issues various vendors and consurtiums have created technologies to combat
this issues various vendors and consortiums have created technologies to combat
this, known under names as "secure boot", "highly assured boot" (NXP),
"verified boot" (Google Android/ChromeOS).
While the scope and implementation details of these technologies differs the
approach to provide a trusted boot chain tends to be similar between all of
them. This document discusses how that aspect of the various technologies works
on a high-level and how this can be introduced into apertis.
on a high-level and how this can be introduced into Apertis.
## Boot sequence
......@@ -38,7 +38,7 @@ The very first step in the boot process after power on is to get the CPU to
start executing some instructions. As the CPU cannot load instructions without
running instructions these first instructions are hardwired into the SoC
directly with the CPU is hardwired to start executing those when powers comes
on. This hardwared piece of code is often referred to as the ROM or romcode.
on. This hardwired piece of code is often referred to as the ROM or romcode.
The job of the romcode is to do very basic SoC setup and load further code to
execute. To allow the romcode to do its job, it will have access to a small
......@@ -72,7 +72,7 @@ firmware followed by a non-secure world bootloader which loads Linux. For those
interested the various images used in an ATF setup can be found
[here](https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/image-terminology.html).
Linux starting up typically is the last phase of the boot process. For linux to
Linux starting up typically is the last phase of the boot process. For Linux to
start the previous stage will have loaded a kernel image, optionally a
initramfs and optionally a devicetree into main memory. The combination of
these will load the root filesystem at which point userspace (e.g.
......@@ -86,10 +86,10 @@ more complex systems multiple CPUs (e.g. main application processors and various
co-processors) might be booted. It may even be the case that all the early
stages are done by a co-processor which takes care of loading the first code
and starting the main processor. The overall description is also valid for
system with hypervisors, essentially the hyporvisor is just another stage in
system with hypervisors, essentially the hypervisor is just another stage in
the boot sequence and will load/start the code for each of the cells it runs.
For this document we'll only look at securing the booting of the main (linux
For this document we'll only look at securing the booting of the main (Linux
running) processor without a hypervisor.
## Secure boot sequence
......@@ -104,7 +104,7 @@ Typically this is done by some signature verification mechanism.
The ROM step is normally assumed to be fully trusted as it's hard-wired
into the SoC and cannot be replaced. How the ROM is configured and how it
validates the next stage is highly device specific. Later steps can do the
verfication either by calling back into ROM code (thus re-using the same
verification either by calling back into ROM code (thus re-using the same
mechanisms as the ROM) or by pure software implementation (making it more
consistent between different devices).
......@@ -112,10 +112,10 @@ In all cases to support this, apart from device specific configuration, all
boot stages need to be appropriately signed. Luckily this is typically based on
standard mechanisms such as RSA keys and X.509 Certificates.
Once linux starts the approach has to be different as it's not feasable in
Once Linux starts the approach has to be different as it's not feasible in
most systems to fully verify all of the root filesystem at boot time as this
simply would take far too long. As such the form of protection described
thusfar only gets applied up to the point the Linux kernel starts loading.
thus far only gets applied up to the point the Linux kernel starts loading.
## Threat models
......@@ -124,7 +124,7 @@ at the related threat models. As a first step we can distinguish between
offline (device is turned off) and online attacks (device powered on).
For these considerations the assumption is made all boot steps work as
intended. As with any software security vulnarabilities can invalidate the
intended. As with any software security vulnerabilities can invalidate the
protection given. While in most cases these can be patches as issues become
known, for ROM code this is impossible without a hardware change.
......@@ -134,7 +134,7 @@ known, for ROM code this is impossible without a hardware change.
required)
* Impact: Depending on the boot stage the attacker can get full control
of the device for each following boot.
* Migation; Assuming each stage correctly validates the next boot
* Mitigation: Assuming each stage correctly validates the next boot
stage, any tampering with loaded code will be detected and
prevented (e.g. device fails to boot).
......@@ -142,36 +142,36 @@ known, for ROM code this is impossible without a hardware change.
serial) under the attackers control.
* Impact: Depending on the boot stage the attacker can get full control
of the device.
* Migation: The ROM or any stage that loads from an external source should
* Mitigation: The ROM or any stage that loads from an external source should
use the same verification as for any on device stages. However for
production use, if possible, loading software from external source
should be disabled.
* Attack: Replace or add binaries on the systems root filesystem
* Impact: Full control of the device as far as the kernel allows.
* Migration: No protection from the above mechanisms.
* Mitigation: No protection from the above mechanisms.
### online attacks
* Attack: Gain enough access to replace any of the boot stages on device storage
* Impact: Depending on the boot stage the attacker can get full control
of the device for each following boot.
* Migation; Assuming each stage correctly validates the next boot
* Mitigation: Assuming each stage correctly validates the next boot
stage, any tampering with loaded code will be detected and
prevented (e.g. device fails to boot).
* Attack: Replace or add binaries on the systems root filesystem
* Impact: Full control of the device as far as the kernel allows.
* Migration: No protection from the above mechanisms.
* Mitigation: No protection from the above mechanisms.
## Signing and signing infrastructure
To securily boot a device it is assumed all the various boot stages have some kind
To securely boot a device it is assumed all the various boot stages have some kind
of signature which can be validate by previous stages. Which by extension also
means the protection is only as strong as the signature; if an attacker can
sign code under their control with a signature that is valid (or seen as
valid) for the verifing step all protection is lost. This means that special
valid) for the verifying step all protection is lost. This means that special
care has to be taken with respect to key handling to ensure signing keys are
kept with the right amount of security depending on their intended use.
......@@ -189,7 +189,7 @@ attack vector.
For these reason it's recommendable to have at least two different sets of
signing keys, one for development usage and one for production use. Development
keys can be kept with low security or even be publically available, while
keys can be kept with low security or even be publicly available, while
production keys should *only* be used to sign final production images and
managed by a hardware security module (HSM) for secure storage. To allow the
usage of a commercially available HSMs it's recommended for the signing process
......@@ -199,18 +199,18 @@ to be able to support the
Note that in case security keys do get lost/stolen/etc it is possible for some
devices to revoke or update the valid set of keys. However this can be quite
limited e.g. on i.MX6 device one can *one-time* program up to four acceptable
keys and each of those can be flagged as revoked, but it's impossile to add
keys and each of those can be flagged as revoked, but it's impossible to add
more or replace any keys.
## Apertis secure boot integration
Integrating secure boot into apertis really exists out of two parts. The first
Integrating secure boot into Apertis really exists out of two parts. The first
part is to ensure all boot stages have the ability to verify. The second part
is to be able to sign all the boot stages as part of the apertis image building
is to be able to sign all the boot stages as part of the Apertis image building
process. While the actual implementation details of both will be
system/hardware/SoC specific the impact of this is generic for all.
As apertis images are composed out of pre-build binary packages the package
As Apertis images are composed out of pre-build binary packages the package
delivering the implementation for the various boot stages should either provide
a build which will always enforce signature verification *or* the
implementation should detect if the device is configured for secure boot and
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment