Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

mkukri.xyz

Post reply on HN
Print view View original

131–136 of 136 posts

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#131

Post by kukrimate »

oasisaimlessly wrote: post #124
kukrimate wrote: post #109

Earlier quoted context omitted.

Because where do you store the CPU side private key after the exchange for future sessions? The secure storage is the TPM , but here you cannot obviously store the secret in the TPM, it's a chicken and egg problem. Thus your secret could only be on disk or in flash in and the attacker can just get it.

> Because where do you store the CPU side private key after the exchange for future sessions? eFuses, maybe? Or a bit of battery-backed SRAM. Lots of devices have a small amount of hardened storage for e.g. encryption keys. FPGAs supporting bitstream encryption and Atmel's ATSHA device line are examples. > CryptoAuthentication devices have full metal shields over all of the internal circuitry, so that if an attacker…

> eFuses, maybe? Or a bit of battery-backed SRAM. Lots of devices have a small amount of hardened storage for e.g. encryption keys. FPGAs supporting bitstream encryption and Atmel's ATSHA device line are examples.

To clarify, I was referring to the status quo of current discrete TPM implementations, from a bigger picture perspective, there is certainly room for improvement.

Also I am not sure the current TPM standard is compatible with that idea at all. Operating systems set up their own TPM sessions, so there would need to be secret storage only available to a specific operatings system, e.g. similar to what TPM provides, and we are back to the chicken and egg scenario.

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#133

Post by sim7c00 »

Foxboron wrote: post #44
RedShift1 wrote: post #37

Earlier quoted context omitted.

Heh I always thought that TPM was there to secure anything. If it's only meant for secure boot then I understand the poor tooling and absence of APIs to use the thing properly inside applications.

It's not meant for Secure Boot. They are two separate, but adjacent, technologies that provide their own security properties in a boot chain. This is a common misconception.

Hi Fox, i'm not aware of any other usages on the platform i'm familiar with sorry, maybe a gap in my understanding.

Afaik, if you want access to a chip like TPM, the OS will need to cooperate as such I/O access or MMIO or however it's accessed, will be privileged instructions likely.

I'd find it somewhat logical an OS or loader component starts verification, and then components upwards in the chain are well, chained together via verification, taking away the need to access the TPM after the initial modules are verified.

- Do you have any examples of how else the TPM is used? I'm very keen to learn more about it's use-cases.

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#134

Post by sim7c00 »

patmorgan23 wrote: post #48
sim7c00 wrote: post #28

Earlier quoted context omitted.

its meant for secureboot, but i suppose the rest of the platform, built usually by other ppl than ones who designed the TPM, needs to also implement it correctly. an d as this article shows, this is not an easy feat. (this attack seems silly but it's really clever tbh. good inspired idea likely based in lots of domain expertise). - if you can protect the boot-chain with secureboot, what you can do for your private ke…

TPM isn't just for secure boot. Windows utilizes it for Bitlocker full disk encryption. It's just not widely used for other applications.

Thanks, that's interesting. as commenter noted i'd say this is part of the boot-process, but you are right, it's not technically secure boot related. booting securely != secure boot that's correct :)

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#135

Post by Foxboron »

sim7c00 wrote: post #133
Foxboron wrote: post #44

Earlier quoted context omitted.

It's not meant for Secure Boot. They are two separate, but adjacent, technologies that provide their own security properties in a boot chain. This is a common misconception.

Hi Fox, i'm not aware of any other usages on the platform i'm familiar with sorry, maybe a gap in my understanding. Afaik, if you want access to a chip like TPM, the OS will need to cooperate as such I/O access or MMIO or however it's accessed, will be privileged instructions likely. I'd find it somewhat logical an OS or loader component starts verification, and then components upwards in the chain are well, chained…

> Hi Fox, i'm not aware of any other usages on the platform i'm familiar with sorry, maybe a gap in my understanding.

The TPM as a device is completely democratized and accessible by the normal user.

You can use it for platform attestation (which is this post is trying to point out might be broken in some cases), but it also works as a "discount" smartcard where you can seal data and shield keys.

Two examples here which I have written:

A file encryption utility for `age` that shields the keys in the TPM.

https://github.com/Foxboron/age-plugin-tpm

`ssh-tpm-agent` is an `ssh-agent` implementation that enables you to create TPM shielded keys and does signing operation on the TPM.

https://github.com/Foxboron/ssh-tpm-agent

Conceptually both of these tools can also use PCR policy sealing as a form of platform attestation, but I have not implemented that yet as it's a bit hard to do this in a user friendly way UX wise.

As noted by others, you can also do disk encryption. `systemd-cryptsetup` does this on Linux.

https://www.freedesktop.org/software/systemd/man/latest/syst...

> Afaik, if you want access to a chip like TPM, the OS will need to cooperate as such I/O access or MMIO or however it's accessed, will be privileged instructions likely.

Not really? `/dev/tpmrm0` is a TPM resource manager for Linux that is accessible by being part of the `tss` group.

> I'd find it somewhat logical an OS or loader component starts verification, and then components upwards in the chain are well, chained together via verification, taking away the need to access the TPM after the initial modules are verified.

This is only one of several use-cases of a TPM :)

This is also orthogonal of whether or not Secure Boot is part of the chain, depending on the operating system.

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#136

Post by sim7c00 »

Foxboron wrote: post #135
sim7c00 wrote: post #133

Earlier quoted context omitted.

Hi Fox, i'm not aware of any other usages on the platform i'm familiar with sorry, maybe a gap in my understanding. Afaik, if you want access to a chip like TPM, the OS will need to cooperate as such I/O access or MMIO or however it's accessed, will be privileged instructions likely. I'd find it somewhat logical an OS or loader component starts verification, and then components upwards in the chain are well, chained…

> Hi Fox, i'm not aware of any other usages on the platform i'm familiar with sorry, maybe a gap in my understanding. The TPM as a device is completely democratized and accessible by the normal user. You can use it for platform attestation (which is this post is trying to point out might be broken in some cases), but it also works as a "discount" smartcard where you can seal data and shield keys. Two examples here wh…

Thanks a lot for this reply Fox. this is really interesting stuff. thanks a ton!
Post reply on HN