search

osresearch / safeboot

Scripts to slightly improve the security of the Linux boot process with UEFI Secure Boot and TPM support
https://safeboot.dev/
GNU General Public License v2.0
270 stars 28 forks source link

tpm2-totp as part of safeboot #67

Open osresearch opened 4 years ago

osresearch commented 4 years ago

It would eliminate a dependency if the safeboot script generated the totp code on its own, rather than using the external program.

osresearch commented 4 years ago

PCRs for TOTP should not include PCR4, since we want to generate totp codes in recovery mode as well.

osresearch commented 3 years ago

There appear to be issues with creating and importing HMAC keys using the tpm2-tools. https://github.com/tpm2-software/tpm2-tools/issues/1597 is open since 2019. The easy fix didn't work, so it will take a bit more effort to figure out how to copy the creation code from the tpm2-totp tool.

diabonas commented 3 years ago

It would eliminate a dependency if the safeboot script generated the totp code on its own, rather than using the external program.

FWIW, if this is still about the linking issue regarding libtpm2-totp, I am happy to continue the discussion we had in https://github.com/tpm2-software/tpm2-totp/pull/67#discussion_r424872340. I am sure we can find a solution that works for you, e.g. a configuration option to enable static linking on request, but I am still confused as to what your use case is.

it will take a bit more effort to figure out how to copy the creation code from the tpm2-totp tool

Generally I think duplicating coding efforts is not the best solution in most cases.

osresearch commented 3 years ago

The major motivation (which wasn't spelled out in this issue) for moving the processing of the HMAC secrets into the safeboot script is to have more flexibility in the sealing parameters. #58 added support for sealed disk keys with signed PCRs, which allows fleetwide remote updates without requiring hands on each machine to reseal for the new PCRs, as well as eliminating the need to access the per-device recovery keys (or password, in the case resealing of tpm2-totp). The flexible unsealing policy can also enable TPM counters to deal with replay attacks against older firmware versions, which I don't think the current tpm2-totp implementation protects against.

diabonas commented 3 years ago

signed PCRs

Hm, I think the easiest way to have support for this in tpm2-totp would be to allow specifying a custom policy during tpm2-totp generate (instead of calculating it automatically from the current PCR state) and allowing to pass the handle to a policy session created by tpm2_startauthsession, tpm2_policypcr, tpm2_policyauthorize, ... during tpm2-totp calculate. Would this work for you? Feel free to open an issue to keep track of this feature requet if you are interested, I think that would be a worthwhile addition.

which allows fleetwide remote updates without requiring hands on each machine to reseal for the new PCRs

Depending on your use case, it might be worth looking into using Secure Boot with custom keys: if you set that up, you can sign your kernel with the Secure Boot keys and seal the TOTP secret against PCRs 0 and 7, avoiding the need for a PCR recalculation after each kernel update: PCR 7 tracks whether Secure Boot is enabled and which keys have been used to sign the EFI binaries that have been loaded, making sure only kernels authorised by you have been used. Personally, I find this a lot easier than using PCRs 0 and 4 and having to recalculate the PCR state after each update.