Hi Chris,
I'm not sure whether this is the issue. As mentioned in my query, when I
extended PCR0, it's value got changed as expected.
On a reboot, the changed value of PCR0 got retained and the value of PCRs
1-5 got modified.
Are the PCRs 0-6 interlinked?
This device is quite new to me and the reason for the above behavior is not
clear to me.
Thanks and Regards,
Pritha.
On 6 March 2017 at 18:25, Chris Hawkins <[email protected]> wrote:
> Pritha,
>
> What I believe you are observing is that the PCRs are being reset on boot,
> but are being extended as expected by the BIOS/UEFI (PCRs 0-7) and the OS
> (PCRs 8-15). It's rare to find a platform that can enable and activate a
> TPM but it's not configured to extend PCRs on boot. GRUB is also TPM aware,
> and will also extend PCRs. Because your boot environment rarely changes,
> the extended PCR values will generally be identical after every boot.
> Update a BIOS revision, and you'll see these change. Not many other things
> will affect a change. These unchanging values may imply that the PCRs are
> never being reset, but they almost certainly are. They are just being
> extended by measurement of the same, unchanging things, on every boot.
>
>
> On Mar 6, 2017 12:19 AM, "Pritha Ganguly" <[email protected]>
> wrote:
>
> Hi Tadd,
>
> Actually I wanted to use TPM for secure boot feature.
> I'm not able to understand how the lower PCRs can be used for the same if
> they are not getting reset to their default values.
> Here's what I have understood about how to use the PCRs for secure boot.
> Please correct me if I'm wrong.
>
> For example at the bootloader stage, I want to allow only trusted kernel
> image to boot the system. These are the steps that can be followed (
> Reference : https://www.sec.in.tum.de/assets/Backup/Studentenworks/finis
> hed/lorenz2012.pdf page 41-44) :-
>
> *Initialization step :*
>
> 1. The hash of the kernel image is stored in memory - *hash(kernel_old)*.
> 2. A 20 byte random number - a *secret* is generated by the TPM and it's
> stored in the NVRAM which is write and password protected.
> 3. *X = hash(hash(kernel_old) || secret) *is calculated
> *.*
> 4. PCR 1 is extended with
> * X.*
> 5. Now *X* is sealed with PCR1 and the sealed blob is stored in memory
>
> *.*
> *Verification step *(after system reboot at bootloader stage)
>
> *:*
> 1. The *secret* is read from the NVRAM location by giving the password.
> 2. The hash of the kernel image to be loaded is generated -
> *hash(kernel_new)* and as in step 3 of the initialization step, *X' =*
> *hash(hash(kernel_new)||
> secret)* is calculated
> *.*
> 3. PCR 1 is extended with
> * X'.*
> 3. If the PCR configurations match then only the sealed blob obtained in
> step 5 of initialization step i.e *X* can be unsealed.
> 4. If unsealing is possible, then *X *is obtained.
> 5. If* X == X'*, then only the *kernel image is allowed to load*
> *and boot else the boot process halts.*
> Now my query is, if I've already extended PCR 1 during initialization step
> and it fails to reset to it's default value on reboot, how can I use PCR1
> for unseal operation in the verification stage?
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> TrouSerS-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/trousers-users
>
>
>
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
TrouSerS-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/trousers-users
