tpm_clear on Samsung Chromebook Series 3 with ARM?

[Bill Smith]

Hi -

This probably related to an unusual corner case with using Chromebooks.

I would like to experiment with the TPM device on the Samsung Chromebook Series 3 (with the Exynos 5250 ARM processor).

For example, with ChrUbuntu, I can interact with the TPM device using tpm-tools (a standard collection of utilities for working with the TPM device) - but I am having trouble taking ownership of the TPM device (which is one of the first steps required to actually work with the TPM device).

Is the TPM actually used for anything in ChromeOS at this point?

Normally, we should be able to clear the TPM device as part of an ownership transfer process.  With Linux using tpm-tools, the command to clear the TPM device should be "tpm_clear -f" - but I get a "bad physical presence" message.

In these circumstance on an x86 system with a TPM device - we would normally need to clear the TPM device in the BIOS settings.

On the Samsung Chromebook S3 with an ARM processor, it is unclear how I should go about clearing the TPM.

I have seen suggestions that changing the Chromebook from developer mode to normal mode and back to developer mode should clear the TPM device as part of the scrubbing process.  I tried this - but the TPM device remains locked down and I still can't take ownership of it.

This strikes me as something that should be taken care of as part of the full Chromebook device reset (e.g., "Powerwash") which is supposed to restore the Chromebook to its original factor state (presumably including clearing the TPM device).

However - when I tried "powerwash" - I found that I am still locked out of the TPM device.

If "powerwash" is supposed to return the Chromebook to the original factory settings - then clearing the TPM device should definitely be part of this process.

Is this a bug?

As for the next possible set of options - I can try doing a full Chrome OS recover - but I have no idea whether that would actually clear the TPM device. 

Does anyone know if the full Chrome OS recovery process will take care of clearing the TPM?

What should the process be to clear the TPM device?

Thanks.

- Bill

[Mike Frysinger]

yes, the TPM is being used.  see this document for example:

http://dev.chromium.org/developers/design-documents/tpm-usage

no, powerwashing doesn't reset the TPM.  this is by design.  the name "powerwash" used to be associated with "factory reset", but we've been moving away from that since it isn't really a factory reset.

yes, doing a USB recovery will reset the TPM.  this is really like a factory reset.

-mike

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
 

[Vadim Bendebury]

On Thu, Feb 27, 2014 at 2:23 PM, Mike Frysinger <vap...@chromium.org> wrote:
> yes, the TPM is being used. see this document for example:
> http://dev.chromium.org/developers/design-documents/tpm-usage
>
> no, powerwashing doesn't reset the TPM. this is by design. the name
> "powerwash" used to be associated with "factory reset", but we've been
> moving away from that since it isn't really a factory reset.
>
> yes, doing a USB recovery will reset the TPM. this is really like a factory
> reset.
> -mike
>
>

Well, USB recovery might "reset" the TPM (i.e. lower the
kernel/firmware version number), but it will not unlock it for use by
tmptools - the read only firmware will lock the TPM no matter what.

--vb

[Richard Barnette]

On 2/27/14, 4:32 PM, Vadim Bendebury wrote:
> On Thu, Feb 27, 2014 at 2:23 PM, Mike Frysinger <vap...@chromium.org> wrote:
>> yes, the TPM is being used. see this document for example:
>> http://dev.chromium.org/developers/design-documents/tpm-usage
>>
>> no, powerwashing doesn't reset the TPM. this is by design. the name
>> "powerwash" used to be associated with "factory reset", but we've been
>> moving away from that since it isn't really a factory reset.
>>
>> yes, doing a USB recovery will reset the TPM. this is really like a factory
>> reset.
>> -mike
>>
>>
>
> Well, USB recovery might "reset" the TPM (i.e. lower the
> kernel/firmware version number), but it will not unlock it for use by
> tmptools - the read only firmware will lock the TPM no matter what.
>

Recovery doesn't reset the rollback version. Basically, it's not
possible to decrement the rollback version (that being the point
of the feature). However, if you're installing custom bits in dev
mode, the rollback version isn't checked, so it doesn't matter.

Also worth noting: Generally, recovery will be used with a
recovery image, which installs a Chrome OS image, not a custom
image. You can use recovery to install a custom image, but the
procedure is unnecessary for the Samsung Chromebook, and arguably
cumbersome.

And another note: Switching from dev mode to verified mode will
also reset the TPM. As with recovery, the TPM will be locked before
it boots to the OS, and unowned after boot completes.

--
--jrb

[Luigi Semenzato]

On Thu, Feb 27, 2014 at 4:57 PM, Richard Barnette
<jrbar...@chromium.org> wrote:
> On 2/27/14, 4:32 PM, Vadim Bendebury wrote:
>>
>> On Thu, Feb 27, 2014 at 2:23 PM, Mike Frysinger <vap...@chromium.org>
>> wrote:
>>>
>>> yes, the TPM is being used. see this document for example:
>>> http://dev.chromium.org/developers/design-documents/tpm-usage
>>>
>>> no, powerwashing doesn't reset the TPM. this is by design. the name
>>> "powerwash" used to be associated with "factory reset", but we've been
>>> moving away from that since it isn't really a factory reset.
>>>
>>> yes, doing a USB recovery will reset the TPM. this is really like a
>>> factory
>>> reset.
>>> -mike
>>>
>>>
>>
>> Well, USB recovery might "reset" the TPM (i.e. lower the
>> kernel/firmware version number), but it will not unlock it for use by
>> tmptools - the read only firmware will lock the TPM no matter what.
>>
> Recovery doesn't reset the rollback version. Basically, it's not
> possible to decrement the rollback version (that being the point
> of the feature).

I also thought so for quite a while, but it turns out it's not true.
The firmware leaves the TPM unlocked in recovery, so the recovery
image can do anytyhing to it. (But it has to be a Google-signed
image.)

The only protection we offer is against *remote* rollback attacks. If
the device is in your hands there isn't much point in trying to
protect against it.

> However, if you're installing custom bits in dev
> mode, the rollback version isn't checked, so it doesn't matter.

The kernel version isn't checked, correct. I am not sure about the
R/W firmware version.

> Also worth noting: Generally, recovery will be used with a
> recovery image, which installs a Chrome OS image, not a custom
> image. You can use recovery to install a custom image, but the
> procedure is unnecessary for the Samsung Chromebook, and arguably
> cumbersome.

Very cumbersome, since without modifying the firmware you can only
boot a Google-signed recovery image.

> And another note: Switching from dev mode to verified mode will
> also reset the TPM. As with recovery, the TPM will be locked before
> it boots to the OS, and unowned after boot completes.

Right. The firmware clears the TPM owner on switches between verified
and developer modes. You don't even have to boot---just power on, and
the TPM owner is cleared almost immediately.

[Mike Frysinger]

On Thu, Feb 27, 2014 at 8:10 PM, Luigi Semenzato wrote:

> On Thu, Feb 27, 2014 at 4:57 PM, Richard Barnette wrote:
> > On 2/27/14, 4:32 PM, Vadim Bendebury wrote:

> >> On Thu, Feb 27, 2014 at 2:23 PM, Mike Frysinger wrote:
> >>> yes, the TPM is being used. see this document for example:
> >>> http://dev.chromium.org/developers/design-documents/tpm-usage
> >>>
> >>> no, powerwashing doesn't reset the TPM. this is by design. the name
> >>> "powerwash" used to be associated with "factory reset", but we've been
> >>> moving away from that since it isn't really a factory reset.
> >>>
> >>> yes, doing a USB recovery will reset the TPM. this is really like a
> >>> factory reset.
> >>

> >> Well, USB recovery might "reset" the TPM (i.e. lower the
> >> kernel/firmware version number), but it will not unlock it for use by
> >> tmptools - the read only firmware will lock the TPM no matter what.
> >
> > Recovery doesn't reset the rollback version. Basically, it's not
> > possible to decrement the rollback version (that being the point
> > of the feature).
>
> I also thought so for quite a while, but it turns out it's not true.
> The firmware leaves the TPM unlocked in recovery, so the recovery
> image can do anytyhing to it. (But it has to be a Google-signed
> image.)

you mean we lock the TPM when the recovery image is not Google signed
? certainly when you're in dev mode, you can boot devkey signed
recovery images.
-mike

[Randall Spangler]

But then you're not booting it in recovery mode; you're using dev mode + USB booting.  So the TPM is locked.

- Randall

[Bill Richardson]

Bah. My reply bounced. Here it is again. Apologies if you see this twice (or more...)

On Thu, Feb 27, 2014 at 8:49 PM, Bill Richardson <wfri...@google.com> wrote:

The TPM is left unlocked when booting in recovery mode specifically so we can roll it back (or anything else) if we absolutely had to. So far we haven't had to.

Nothing anywhere knows anything about which keys are "Google" keys. The reason you can use a dev-signed recovery image on a dev machine is that it has developer root and recovery keys in the RO BIOS' GBB.

You can also boot a Google-signed image in dev mode on a production system with crossystem dev_boot_usb=1, but you have to hit ctrl-U. That's normal boot though, so the TPM will be locked.

--

Art for Art's Sake

Engineering for Money

[Richard Barnette]

Hm. OK. Let me provide more detail about what I mean.

First, the page vapier@ cited looks to cover the important points
regarding TPM usage. It describes the conditions under which we
clear TPM ownership, the operation of dev and recovery modes, and
what you can and can't do with the TPM in custom OS software.
That page knows things I don't, so you should go there for answers
on those topics.

Regarding recovery specifically: As wfrichar@ noted, in recovery,
the recovery kernel from the USB device (not the firmware) is
responsible for enforcing rollback protections and locking the TPM.
However, the firmware will only boot a recovery kernel signed by
Google. Properly signed recovery kernels perform the rollback
enforcement and lock the TPM before any custom OS code has a chance
to operate. The net result is that recovery imposes the same
restrictions as the firmware does.

--
--jrb

[Luigi Semenzato]

I don't think that's true. On an unmodified (i.e. never opened)
mass-production device, the recovery image must be google-signed
whether you are in verified or developer mode.

[Darren Krahn]

If you want physical presence you'll have to modify firmware; the shipping firmware on every Chromebook will lock physical presence during boot.  If you just want TPM ownership, this is possible in dev mode:

1) Clear the TPM.  For systems without a physical dev-mode switch just use 'crossystem clear_tpm_owner_request=1; reboot'.  Otherwise, flip to verified mode and back or do a full recovery.

2) Get into VT2.  Don't login or do any steps on the GUI.  At this point the TPM is not owned and physical presence is not required to take ownership.

3) Take ownership the CrOS way. cryptohome --action=tpm_take_ownership; cryptohome --action=tpm_wait_ownership; cryptohome --action=tpm_status

4) Note the random TPM owner password and now you can use 'tpm_changeownerauth --owner' to change the password to something more memorable.

Disclaimer: I haven't tried this in a while but I think it should still work...

On Fri, Feb 28, 2014 at 6:06 PM, Darren Krahn <dkr...@google.com> wrote:

If you want physical presence you'll have to modify firmware; the shipping firmware on every Chromebook will lock physical presence during boot.  If you just want TPM ownership, this is possible in dev mode:

1) Clear the TPM.  For systems without a physical dev-mode switch just use 'crossystem clear_tpm_owner_request=1; reboot'.  Otherwise, flip to verified mode and back or do a full recovery.

2) Get into VT2.  Don't login or do any steps on the GUI.  At this point the TPM is not owned and physical presence is not required to take ownership.

3) Take ownership the CrOS way. cryptohome --action=tpm_take_ownership; cryptohome --action=tpm_wait_ownership; cryptohome --action=tpm_status

4) Note the random TPM owner password and now you can use 'tpm_changeownerauth --owner' to change the password to something more memorable.

Disclaimer: I haven't tried this in a while but I think it should still work...

[Bill Smith]

This suggestion worked for me and I now "own" my TPM ... thank you!

I did not try clearing the TPM or changing the SRK password at this point.  From the TPM usage documentation here:

    http://dev.chromium.org/developers/design-documents/tpm-usage

It appears that changing the SRK or the SRK password would render the user data on the Chromebook unusable.  Correct?

However - the documentation also says that "the SRK is unrestricted so that it can be used without the owner password".  Does this mean that the SRK password is either blank or uses the "well known" password (e.g., the twenty bytes of ones)?

Probing the TPM, I see that it has an endorsement key which should be unique to the device.  Is this used for anything?  Is there a corresponding certificate for the EK in NVRAM?

Finally - I see references to remote attestation support in Chrome OS (which requires user consent) ... is there any additional information available on this?

Thanks.

- Bill

[Darren Krahn]

Yes, changing the SRK or SRK password would cause problems.  The SRK password is blank; that is, a 'plain' password of 0 bytes.

The EK is factory provisioned and is used for remote attestation.  There is an endorsement cert in NVRAM, stored in conformance with TCG PCClient spec.  This cert may look different for different models.  When you're in the state where cryptohome is aware of the TPM password (i.e. 'cryptohome --action=tpm_status' shows a password) you can call 'cryptohome --action=tpm_attestation_get_ek' and it will dump the cert.  There is currently no further public documentation on remote attestation other than the code itself.  You may find the code here or here or here interesting.