Generally, you want this to be either every PCR for the code up to the point where the decryption code would take over, or at least every PCR for the code up to the point where the measured code will itself validate cryptographic signatures on further sections, up to the decryption code.
Volume encryption enters this story when you generate the encryption key and store it in the TPM with a TPM policy that essentially says "the key shall only be available if the following set of PCRs have their current values". Code that has been extended into a PCR in this way is said to be "measured" by that PCR any change to the code will result in a different value in the PCR. into yet another PCR, and so on until you get to the main operating code. That code (low-level firmware) will then extend the next stage of code, such as a bootloader or minimal decryption utility, etc. The CRTM is generally non-writable code that "extends" some critical code - usually the device's low-level firmware (BIOS/UEFI on PCs and similar devices) - into one PCR, and that code's configuration data into another PCR. The first data fed into the PCRs is done during the "Core Root of Trust Measurement" or CRTM execution. While the set of PCRs available varies somewhat, the general notion is the same in all cases: the PCRs contain a rolling hash of data that has been used by the system up to a given point in time. The encryption key (or a value used to derive it) is stored in (possibly generated in) the TPM with a policy that it can only be released if certain PCRs have their expected values. The usual approach - used by Bitlocker and other TPM-capable volume encryption schemes - is to "seal" the volume encryption key using Platform Configuration Registers (PCRs). It's possible to do this pretty securely.
0 kommentar(er)
