U2F to verfiy TPM

[nickik]

Hallo.

Not sure if I should put this into Github Issues, its a question about feature idea/feature request.

I have seen in a talk [1] that you can use Yubikey GPG smartcard is used to verify the signature on the running code.

The Yubikey also supports the U2F protocol and it has the attribute to only sign the challange if the origin is correct. For the primary use-case of U2F the origin refers to the url of the website you are trying to log into but for the heads usecase this could be the TPM state.

This would be an alternative to the TOTP idea presented by Matthew Garrett at 33C3 [2].

I'm not an expert on these things, but I am replacing all web logins 2-factor with U2F when possible, so I thought why have the same usability on a lower level.

Thank you for all your work.

[1] https://www.youtube.com/watch?v=0UtTGwO73TA

[2] https://www.youtube.com/watch?v=ykG8TGZcfT8

[osresearch]

I'm not familiar with the u2f protocol, although I'm not certain how the u2f token would be able to identify the TPM signature. In the TOTP case, the "secret" is pre-shared between the TPM and the user's phone. Being able to unseal with secret from the TPM is what is being verified without having to reveal the secret. Is there an equivalent shared secret?

[nothingmuch]

U2F would allow the computer to authenticate the user, but compared to TOTP it is a regression as far as the user's ability to authenticate the computer due to introduction of replay/spoofing attacks if used in a similar manner. The phishing protection features in U2F are not really a safe way to authenticate heads' boot state.

Upon registration the token is given an AppID and optional TLS Channel ID (which in one scenario is the unsealed TOTP secret, and in the other it'd a static AppID, perhaps the hash of the ROM?), and the token responds with a public key and a tag (which in the case of the yubikey is a MAC'ed nonce, and both it and the key are derived from the AppID and the device secret).

To authenticate, the server (heads) sends back the nonce and a challenge, the yubikey will only sign challenges accompanied by the MAC'ed nonce.

The challenge is signed with an increment counter, so the signature can't be used as part of a deterministic PCR measurement sequence.

Edit to add: https://github.com/cornelinux/yubikey-luks uses OTP based challenge response which lacks U2F's replay protection, that could be useful for PCR measurement - tying unsealing of the secret to possession of a token

I don't see how this really adds much, and since U2F doesn't define the AppID/ChannelID as secret, this might present a relative risk as it will be revealed to potentially malicious U2F devices, and would then allow spoofing of the state that in TOTP is hashed along with a time function. A malicious U2F device could clone the AppID and ellicit a signature from the token, and furthermore the protocol is really just implementing TOFU from the server's point of view.

https://developers.yubico.com/U2F/Protocol_details/Overview.html https://developers.yubico.com/U2F/Protocol_details/Key_generation.html

[nickik]

I can see some of the weaknesses. The primary benefit of U2F would be that it is very user friendly and and that more and more devices will be capable of it, potentially increasing the amount of usage.

Thank you for your answer.

[tlaurion]

@nickik @nothingmuch Next steps?

[nothingmuch]

As I understand it the TOTP functionality is for authenticating the host boot state to the user to avoid giving the LUKS keys to a compromised machine, and I don't see how that's achievable with U2F without divulging information that would make it possible to spoof host (and therefore providing very little mitigation of the evil maid threat model).

That said, I just learned that FIDO2/CTAP2 is a thing. I will try to make time to look into it and see if perhaps it makes it possible for a a token to authenticate the host in a way that is robust to MITM between the TPM and the security token. However, from a cursory glance it appears the requirements/goals haven't changed from U2F/CTAP1, so I'm not very optimistic,

[tlaurion]

The problem here is the same that would require usb device without a TPM to attest of a prior state.

Some small corrections to encourage debate and solution findings:

• Heads modified earlier versions of coreboot to modify ROM stage (which is executed prior to ramstage and kernel loading and usb module loading) to measure itself (no way to run code to init TPM to do those measurements prior of that stage) and use PCRs to store those volatile measurements as a base for further validations.
• Those PCRs values are then used to produce a TOTP code following internal measurements, that were sealed in the form of a QR code to be synced with a remote device, in this case a phone which scanned the Qr code which now relies on the same seed and time to produce TOTP that changed every 30 seconds.
• hotp-verification uses the same TPM measurements to communicate with supported devices, replacing/conplementing TOTP remote attestation with a detached phone by providing visual attestation in a simple form: green or red led.
• TPM is also used to release NVRAM sealed LUKS key if PCRs measurements match, if LUKS header sealed matches, and if Disk Unlock Key passphrase provided to boot default boot entry matches what was used to seal secret.

Now.

• Relying on USB devices to seal earlier stages (measure ROM stages) has limitations.
• LIBREM_KEY as an opened PR to be used without a TPM. This has limitations, since it implies TOCTU. There is no guarantee that what was executed to arrive at the time of measurement would not compromise measurements. That PR relies on flashrom to dump the complete ROM image from SPI. It could be compromised. It could rely on CBFS to dump parts individually, I made a PR in that. Same problem, CBFS could be compromised.

So the lesson here is : the soonest you can do those measurements (ROM stage, TPM toolset ran in cache, without ram initialized, without kernel nor usb modules nor anything else) the more you can trust the measurements of no hardware implant were put there.

On March 12, 2020 4:27:43 PM UTC, Yuval Kogman notifications@github.com wrote:

As I understand it the TOTP functionality is for authenticating the host boot state to the user to avoid giving the LUKS keys to a compromised machine, and I don't see how that's achievable with U2F without divulging information that would make it possible to spoof host (and therefore providing very little mitigation of the evil maid threat model).

That said, I just learned that FIDO2/CTAP2 is a thing. I will try to make time to look into it and see if perhaps it makes it possible for a a token to authenticate the host in a way that is robust to MITM between the TPM and the security token. However, from a cursory glance it appears the requirements/goals haven't changed from U2F/CTAP1, so I'm not very optimistic,

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/osresearch/heads/issues/292#issuecomment-598282679 -- Sent from /e/ Mail