There are (sometimes quite complex) processes to set up the original TPM values (I've skipped some of the more low-level steps in the process for simplicity) and to allow (hopefully authorised) changes to the layers for upgrading or security patching, for example. The process continues until all the layers involved in the process have been measured and the hashes' results have been stored. In this case, the resulting hash is combined with the previous hash (which was stored in the PCR slot) and then also stored in a PCR slot. These can be thought of as pieces of memory that can be read later on - either by the TPM for its purposes or by entities external to the TPM - but that cannot be changed once they have been written. These pieces of memory are integrity protected from the time of their initially being written. This provides assurances that once a value is written to a PCR by the TPM, it can be considered constant for the lifetime of the system until power off or reboot.Īfter measuring the BIOS/EFI layer, the next layer (firmware) is measured. The hash that's produced is then stored in one of several Platform Configuration Register (PCR) "slots" in the TPM.
This measurement involves checking the binary instructions to be carried out by this layer and creating a cryptographic hash of the binary image. In both cases (trusted boot and the measured boot), the basic flow starts with the TPM performing a measurement of the BIOS/EFI layer. Alternative roots of trust, such as hardware security modules (HSMs), might also be used, but I will use TPMs, the most common example in this context, in my example. Once the system starts to boot, the TPM is triggered and starts its work.
#Nathan zipster review how to
I'll concentrate on the bottom four layers (at a rather simple level of abstraction): CPU/management engine BIOS/EFI firmware and hypervisor, but I'll also consider a layer just above the CPU/management engine, which interposes a Trusted Platform Module (TPM) and some instructions for how to perform one of the two processes ( measured boot and trusted boot). This description is arguably over-simplified, but (as I noted above) I'm not interested in the specifics but in what I'm trying to achieve. In order to understand what measured boot and trusted boot aim to achieve, look at the Linux virtualisation stack: the components you run if you want to use virtual machines (VMs) on a Linux machine.
#Nathan zipster review free
0 kommentar(er)
