TPMv2 support plan for heads?

[citypw]

Hi heads maintainers,

We've been testing heads on x230 for a while and we aware of that the current version of heads doesn't support TPMv2. Do you guys have a plan for TPMv2 support or a TODO-list?

[osresearch]

TPMv2 is definitely on the list of "must have eventually". The kernel support is there, but the userspace library hasn't been updated.

One problem with many TPM2 systems is that they are implemented inside the ME. If you use the me_cleaner tool it will also eliminate the ability to use the fTPM.

[citypw]

Damn, I didn't know ME come into play. We tested it this tool on GNU/Linux. Not sure there's any different if we try to port it to heads.

@persmule , have you try tpm_pcrtool on the machine w/ ME neutralized?

[persmule]

@citypw Yes, I have confirmed tpm_pcrtool working on a coreboot-powered gigabyte's ga-b75m-d3h with a TPM2 installed on its TPM socket connected to LPC, and with ME neutralized.

[citypw]

Ok, we haven't test TPMv2 on many systems, only ga-b75M-D3H( Sandybridge/Ivybridge). When does ME have the fTPM code module? MEv11 or earlier version?

[tlaurion]

@citypw @persmule : i'm confronted with the same problem on the kgpe-d16 port i'm doing.

The kgpe-d16 supports a 19 pin TPM2 device, wrongly detected as a SLB9660:

lpc_tpm: Read reg 0xf00 returns 0x1a15d1 Found TPM SLB9660 TT 1.2 by Infineon TPM: Open

What is written on the chip is actually "SLB9665f120". From what I understand from the pc80 source, that device is not detected correctly, and as a result, the 1.2 initialization is done which doesn't work.

Here, an article and video covering the same issue on coreboot.

For coreboot to support TPM2 on a board, that board Kconfig should select TPM2. The result in heads is the following, with mismatch coming from different libraries with Measured Boot activated:

src/lib/tpm2_tlcl.c:309:10: error: conflicting types for 'tlcl_define_space' uint32_t tlcl_define_space(uint32_t space_index, size_t space_size) ^~~~~ In file included from src/lib/tpm2_tlcl_structures.h:16:0, from src/lib/tpm2_tlcl.c:11: src/include/tpm_lite/tlcl.h:65:10: note: previous declaration of 'tlcl_define_space' was here uint32_t tlcl_define_space(uint32_t index, uint32_t perm, uint32_t size); ^~~~~ make[2]: [Makefile:337: kgpe-d16/ramstage/lib/tpm2_tlcl.o] Error 1 make[2]: Waiting for unfinished jobs.... make[2]: Leaving directory '/home/user/Downloads/heads-kgpe-d16/build/coreboot-4.7' make[1]: [Makefile:231: coreboot.intermediate] Error 1 make[1]: Leaving directory '/home/user/Downloads/heads-kgpe-d16' Makefile:452: recipe for target 'all' failed make: [all] Error 2

I searched both your gists and found no recipes in regard of TPM2 activation and toolset usage. Could you share a bit on what you have done so far and accomplished?

[persmule]

@tlaurion I have once built coreboot with Heads' patch and Heads as payload (I always deploy Heads in this way, especially for boards already supported by coreboot, but not by Heads EXPLICITLY, e.g. my t430s, elitebook revolve 810 g1, as well as x200s, which has no TPM capability with its ME REMOVED, so I wrote a patch to make it optional) for my GA-B75M-D3H board (which has been supported by coreboot, and has a spare 20-1 pin TPM socket) with a TPM2 plugged in. During this test, I noticed that the user space library and tool that Heads uses to operate TPM (libtpm) is designed only for TPM1.

[tlaurion]

@persmule Thanks. For the 9665 chip, I just saw that there is a patch stuck in review. Will test it.

Edit: applying the patch makes the initialization right:

lpc_tpm: Read reg 0xf00 returns 0x1a15d1 Found TPM SLB9665 TT 2.0 by Infineon TPM: Open

@osresearch : What toolset would you want supported in heads? tpm2-tools? tpm2-software?

see #134.

[tlaurion]

@zaolin : I saw your VBOOT patches to coreboot. What would be the implications of using it in heads for boards like the x230 regarding the presence of multiple copies being kept (backup purpose) and space constraints?

[tlaurion]

I didn't make the links between ftpm deactivation following me_cleaner application. So the x230 couldn't have tpm2 support.

Is there enough interest to actually try to support IBM TSS implementation?

[tlaurion]

TrustedGrub2 related issue and submitted patches.

[tlaurion]

VBOOT TPM2 support in coreboot

[tlaurion]

@osresearch @flammit @persmule @zaolin

Even the x230 has plenty of unused space left when Intel ME footprint is reduced. It seems we could fit vboot in there.

Is there some platform that couldn't take it?

vboot support documentation in coreboot

[tlaurion]

@osresearch @kakaroto @kylerankin @persmule @zaolin : Any update TPMv2 support? @persmule @zaolin : could you point to VBOOT integration docs that would help to port current Heads implementation?

@kakaroto : Is Librem key / Nitrokey pro v2 a better way to accomplish this? Will your changes to coreboot replace TPM logic with HOTP to accomplish the same goal?

[tlaurion]

TPMv2 support should be working out of the box as of coreboot/coreboot@bce49c2

@osresearch @flammit : Maybe Heads should depend on coreboot's commit id more then releases from now on?

[kakaroto]

I don't think we have any plans for TPMv2 but that's mostly because heads didn't support TPMv2, it might change if heads starts supporting it. I don't have much knowledge on the Librem key so I'll let @kylerankin answer the rest of your question.

[kylerankin]

@tlaurion Whether the Librem key would be better than TPMv2 is hard to say but I did intend on having it be an option for devices that had no TPM at all. (That work hasn't been done yet, but then we are still waiting on Librem Key support to get merged into Heads too).

[osresearch]

I'm a little hesitant to rely on commit ids for dependencies, as opposed to releases which hopefully should have some higher level of testing/assurance/etc. Moving to 4.8.1 fixes some of our hand-hacked measured boot steps, although it does still require changes to the program_segment_loaded() function.

My understanding is that vboot requires 2x the flash space for the A/B write spaces. This would be problematic, although perhaps we can modify vboot to not do that.

My other concern with vboot is figuring out if we can incorporate hardware tokens with it for signing the images, enabling measurements and defining the PCRs that vboot would use.

[tlaurion]

@zaolin?

We have a golang tpm impl now. We support multiboot with kexec-tools.

[zaolin]

Sorry for my late reply.

First of all regarding vboot. I modified it so that people can choose between RO , RO + RW_A or RO + RW_AB.

Second coreboot already offers TPM2 support for all bus drivers (SPI, I2C, LPC).

Third the TPM software stack written in Go is located here https://github.com/systemboot/tpmtool which is used in the verifiedboot branch of https://github.com/systemboot/systemboot We added kexec binaries for amd64/arm64 with a small footprint and mutliboot/xen support (250kb per file). Maybe I need to update the binaries for patching them with @osresearch modifications.

I am not fully ready yet with the verifiedboot integration. We also solved the image loading by introducing our own FIT replacement (wuhuu standard++) including go tooling.

[tlaurion]

@zaolin :

Maybe I need to update the binaries for patching them with @osresearch modifications.

any update on this or any PoC on which collaboration could occur?

[tlaurion]

@osresearch @flammit : how would we integrate https://github.com/systemboot/systemboot/pull/70 ? https://github.com/systemboot/systemboot/tree/verifiedbooter ?

[tlaurion]

From @zaolin, measured boot was supposed to be coreboot 4.9. Will come eventually. Stay tuned for TPMv2 measured boot, since vboot is available for all platforms, and measured boot is a subfeature of it.

[tlaurion]

To follow: https://review.coreboot.org/c/coreboot/+/29547/63 TPMv2 and measured boot will be on master once that is merged. Note that all x86 platforms will be supported through car.ld

[tlaurion]

from @zaolin :

x230 does not support vboot yet
No board support makes sense: https://review.coreboot.org/c/coreboot/+/29816
There is no hw write protection
The easiest way to use vboot is the RO mode

[tlaurion]

https://github.com/osresearch/heads/issues/605

[0xb100d]

Where can I find info about the current state of tpm2 and heads?

[tlaurion]

@zaolin ?

[Tonux599]

@tlaurion

The kgpe-d16 supports a 19 pin TPM2 device, wrongly detected as a SLB9660

Asus 90-C1B0AU-00XBN0VZ is a 19 pin TPM 1.2 module compatible and tested with heads on kgpe-d16.

[lrvick]

Any updates on TPM2 support? The upstream coreboot link referenced was merged.

It looks like the support for monotonic timestamps would make stopping downgrade attacks on the OS boot partition really easy, and close the last easy class of evil-maid attack I am aware of.

[tlaurion]

Platforms supported by Heads have TPM V1 chips.

Please detail your attack scenario or the gadget you would use/create to successfully take advantage of what you advance with proper references?

TPM is used under Heads to measure firmware BIOS region, LUKS header and gpg public key and other user inserted artifacts in CBFS region. Gpg is used to sign generated /boot digest, where HOTP is used to remote attest TPM measurements to GPG USB security dongle. /boot contains HOTP and TPM counters to address your attack scenario if I read you ok.

Newer coreboot version will measure firmware parts outside of the BIOS region through Vboot+measured boot or measured boot without vboot.

Those are all in other tickets.

On July 16, 2020 11:18:46 PM UTC, "Lance R. Vick" notifications@github.com wrote:

Any updates on TPM2 support? The upstream coreboot link referenced was merged.

It looks like the support for monotonic timestamps would make stopping downgrade attacks on the OS boot partition really easy, and close the last easy class of evil-maid attack I am aware of.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/osresearch/heads/issues/287#issuecomment-659728884 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[lrvick]

Example Setup

1. System has no onboard disk or networking (airgapped)
2. System boots from read-only SD card using .iso files with matching .sig files (undocumented afaict but works today).

Example attack

1. At some point Evil maid creates copy of SD card currently being used.
2. A known kernel RNG flaw forces me to create/sign a new iso image
3. Evil maid rolls back SD card to old known vulnerable version
4. Next key generation event is done without noticing downgrade
5. Evil maid is able to use knowledge of previously patched flaw to obtain newly generated keys

Potential solutions

Android solves for these types of scenarios by having all new OS releases that patch a security flaw bump a timestamp in a monotonic counter in their secure boot enclave. Any OS that is validly signed is then checked for a timestamp. If it is older than the stored counter value, it will be prevented from booting.

See: https://android.googlesource.com/platform/external/avb/+/master/README.md#Rollback-Protection

I would like to be able to do similar in a project utilizing Heads. On my cursory research it seems TPM2 has the capability of storing user defined monotonic counters as well called "NV counters". This seems like the right tool on which Heads could potentially implement rollback protection similar to that in AVB without relying on text files on the disk which could potentially be restored to an old state.

See: https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-A-Brief-Introduction.pdf

It is possible I am fundamentally missing something Heads already does to defend against rollback attacks like this, in which case I would love to be educated! :)

On Sun, Jul 19, 2020 at 8:42 AM tlaurion notifications@github.com wrote:

Platforms supported by Heads have TPM V1 chips.

Please detail your attack scenario or the gadget you would use/create to successfully take advantage of what you advance with proper references?

TPM is used under Heads to measure firmware BIOS region, LUKS header and gpg public key and other user inserted artifacts in CBFS region. Gpg is used to sign generated /boot digest, where HOTP is used to remote attest TPM measurements to GPG USB security dongle. /boot contains HOTP and TPM counters to address your attack scenario if I read you ok.

Newer coreboot version will measure firmware parts outside of the BIOS region through Vboot+measured boot or measured boot without vboot.

Those are all in other tickets.

On July 16, 2020 11:18:46 PM UTC, "Lance R. Vick" < notifications@github.com> wrote:

Any updates on TPM2 support? The upstream coreboot link referenced was merged.

It looks like the support for monotonic timestamps would make stopping downgrade attacks on the OS boot partition really easy, and close the last easy class of evil-maid attack I am aware of.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/osresearch/heads/issues/287#issuecomment-659728884

Sent from my Android device with K-9 Mail. Please excuse my brevity.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/osresearch/heads/issues/287#issuecomment-660665553, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAQ4UH7D5DIQOO2YFLBYU3R4MH7XANCNFSM4EFOZU3A .

[tlaurion]

@lrvick The rollback counter is stored inside of /boot right now (requires state) and is optionally enforced through CONFIG_BOOT_REQ_ROLLBACK=y in board config and enforced here and here

All board configs do not force it right now. Example.

I have nothing against your idea.

[lrvick]

So there is a concept of TPM enforced rollback counters today that, if enabled, would mean that even if /boot was restored to an old state it could be detected?

And it works on existing TPM 1.2 devices?

I would be very interested to understand how this works without having knowledge of the build time of the OS and what threats it solves for.

Is there a writeup on this anywhere? Else I'll try to learn what it is doing from the code.

Also would love to know much testing has been done on hardware if any before I start bricking things :)

On Sun, Jul 19, 2020 at 5:40 PM tlaurion notifications@github.com wrote:

@lrvick https://github.com/lrvick The rollback counters are stored inside of /boot right now and is optionally enforced through CONFIG_BOOT_REQ_ROLLBACK=y in board config and enforced here https://github.com/osresearch/heads/blob/c5999d9b1204862b628a62985784c62aa75f414b/initrd/bin/kexec-select-boot#L289 and here https://github.com/osresearch/heads/blob/c5999d9b1204862b628a62985784c62aa75f414b/initrd/bin/kexec-select-boot#L69

All board configs do not force it right now. Example https://github.com/osresearch/heads/blob/9719510f395bcb54efc6b01d309184ba637e6f29/boards/x220/x220.config#L31 .

I have nothing against your idea.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/osresearch/heads/issues/287#issuecomment-660738076, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAQ4UF4HHEECZJI2Y3JEGTR4OG6HANCNFSM4EFOZU3A .

[tlaurion]

Vaultboot bas a working implementation https://github.com/hardenedvault/vaultboot/commit/4506fc26d0d9aed1e15030bbf8cd49cede6c4d49

[tlaurion]

See #1292