Use the Librem Key as a TPM work-alike in the absence of a TPM #493
Conversation
On machines without a TPM, we'd still like some way for the BIOS to attest that it has not been modified. With a Librem Key, we can have the BIOS use its own ROM measurement converted to a SHA256sum and truncated so it fits within an HOTP secret. Like with a TPM, a malicious BIOS with access to the correct measurements can send pre-known good measurements to the Librem Key. This approach provides one big drawback in that we have to truncate the SHA256sum to 19 characters so that it fits within the limitations of HOTP secrets. This means the possibility of collisions is much higher but again, an attacker could also capture and spoof an existing ROM's measurements if they have prior access to it, either with this approach or with a TPM.
The flash script had a minor bug that stopped SHA mode from working and also needed the flashrom output suppressed. The seal and unseal modes for the Librem Key needed 20 characters from the SHA instead of 19.
For users who want to use a TOTP QR code as a backup to a Librem Key, this will add similar support to that mode
|
Tested this on KGPE-D16 with unreliable results, since for some reason, the kgpe-d16 coreboot configuration with My insight on this is that extracting all rom for integrity attestation may not be the right solution. For example, on the kgpe-d16, we have 16MB of rom, which takes around 60 seconds to extract. I haven't tested this on the x200 yet, but will at the end of this week. What I would propose would be:
@kylerankin @flammit : any thoughts? |
|
On KGPE-D16 s3nv, from Timothy Pearson on coreboot ML |
|
I'm playing around and exploring options. Testing the following gives faster reads and consistent results, while not perfect yet. You can cherry-pick this and adapt. |
|
I updated my small PoC to extend measured modules Here is the modules present in x200 coreboot 4.9: Here are the modules present in kgpe-d16 coreboot 4.9: |
| else | ||
| # without a TPM, use the first 20 characters of the ROM SHA256sum | ||
| echo "TPM not configured, measuring ROM directly" | ||
| flash.sh -s /tmp/coreboot.rom | cut -c 1-20 | tr -d '\n' > $TOTP_SECRET |
There was a problem hiding this comment.
Why truncate the hash prematurely? Could you not get the full 120 bits of the HOTP with something like
| flash.sh -s /tmp/coreboot.rom | cut -c 1-20 | tr -d '\n' > $TOTP_SECRET | |
| secret="`flash.sh -s /tmp/coreboot.rom | xxd -r -p | base32 | cut -c 1-24 | tr -d '\n'`" |
(i.e., decode the base16 string then re-encode as base32)?
|
@kylerankin: did I dream or did the HOTP code got upgraded to permit bigger HOTP size? |
|
Confirmed for Nitrokey storage: Nitrokey/nitrokey-storage-firmware#85 Opened ticket for Nitrokey Pro: Nitrokey/nitrokey-pro-firmware#59 Sent from my Galaxy S3 using FastHub-Libre |
|
@kylerankin : Confirmed 40 bytes (320 bits) for NitroKey Pro 0.8+ here and coming to NitroKey Storage next week. So what do we do from here? |
|
Nitrokey permits firmware upgrade free of charge by sending units back to them. I guess Purism does the same? Considering this. I think we should in any case modify the actual code to take advantage of the upgraded HOTP size to 40 bytes by default, at least in this codepath, instead of trimming measurements down to 20 bytes. Or even better, check firmware version and warn accordingly of truncation to 20 bytes if <0.8. Let me know what you think. Sent from my Galaxy S3 using FastHub-Libre |
|
@MrChromebox : Firmware version difference to keep in consideration #493 (comment) |
|
@tlaurion think it will be easier if I just push a new PR for this rather than trying to take over Kyle's. This one can be closed once I do |
|
Closing this PR as we have a newer one that solves the same issue. |
On machines without a TPM, we'd still like some way for the BIOS to attest that it has not been modified. With a Librem Key, we can have the BIOS use its own ROM measurement converted to a SHA256sum and truncated so it fits within an HOTP secret. Like with a TPM, a malicious BIOS with access to the correct measurements can send pre-known good measurements to the Librem Key.
This approach provides one big drawback in that we have to truncate the SHA256sum to 20 characters so that it fits within the limitations of HOTP secrets. This means the possibility of collisions is much higher but again, an attacker could also capture and spoof an existing ROM's measurements if they have prior access to it, either with this approach or with a TPM.