Replies: 10 comments 6 replies
-
Ha, I am amused this discussion is number 42 |
Beta Was this translation helpful? Give feedback.
-
There is a try to address this in systemd/systemd#24597. Is your patch using a similar command line parameters?
Is it possible to extract the SRK from a vTPM and use it outside to generate a sealed secret? Would not this defeat the purpose of a TPM? |
Beta Was this translation helpful? Give feedback.
-
Oh, and re: using a SRK that's loaded into the TPM, I forgot to mention it also provides the ability to trivially "wipe" the system by just deleting (or recreating) the SRK loaded into the TPM NV memory. Once that is done, any secrets sealed by the wiped key are not recoverable. This is also possible of course by wiping the luks slot/token, but it makes the action a bit easier (only need to wipe a single TPM NV handle instead of possibly multiple luks slots on possibly multiple luks devices) and possibly more 'secure' as the TPM is (presumably) more trusted to make the key actually unrecoverable, as compared to possibly being able to recover the contents of a wiped luks slot/token from the physical disk. When using CreatePrimary with a hardcoded template, the only way to 'wipe' the SRK is to wipe the TPM Storage Primary Seed, which has a much more widespread result (and isn't always allowed, depending on the TPM authorization configuration). |
Beta Was this translation helpful? Give feedback.
-
So the idea was that we start out with the hardcoded template, and then if we need to make changes to it we mark that in the JSON data. For example right now we actually allow two different templates already, one with ECC and one with RSA, and the information which to pick is encoded in a JSON field. I expect we'd continue to add further fields there. For example, we probably should actually default to TPMA_OBJECT_NODA for the primary key (we currently don't, see systemd/systemd#20668). Hence we should add a boolean field "noda" or so, which if absent is assumed to be off, and then eventually turn this on by default. Hence, I think this already is extensible enough, but every option needs to encoded in C code and in the JSON file, and should be carefully considered and reviewed when added. |
Beta Was this translation helpful? Give feedback.
-
Well, the signature covers a selection of PCRs, not all. And yeah I would expect the signature stuff to be used for PCR 11, not for other PCRs for now. In fact, systemd-measure only and exclusively supports that right now. |
Beta Was this translation helpful? Give feedback.
-
hmm, persistent? you want to store the key in the nvram? why? we so far focus on never persisting anything in the tpm, but exclusively in the luks superblock. how does the private part of the SRK find its way into the TPM? or to turn this around: if the private part never leaves the TPM, how do you intend the workflow would be to acquire the public part beforehand? So, preparing disk encryption externally is very interesting to me, for the "syscfg" concept we might are working on and might have mentioned? it's supposed to be LUKS disk images that you can overlay on /etc/ atomically via overlayfs, immutably. The idea is that a central provisioning system can prepare them offline, then send them to the individual machine and only that machine can unlock them locally. For that I certainly would like some form of asymmetric preparation for the disk encryption, so that the provisioning system can format and the deployement system can unlock, but that'd be it. For that I had the idea that some tool (maybe systemd-measure?) could run on the deployment system, and output both full, signed PCR quote of the status quo and a public key that can be used to offline encrypt LUKS images. A provisioning systemd could collect these quotes+pubkeys of various systems, use them to verify they are in order, and then generate a new syscfg image encoding their newest configuration, in a way only that specific system could then unlock things. (and sooner or later we want TPM clock policy also included in that, so that you can say: "here's a syscfg for system X that can be unlocked in time window Y…Z only if it runs software V, and has booted into state W"). Anyway, it appears to me what you have in mind would be very close to what I am looking for? (maybe we should do another conf call about this? |
Beta Was this translation helpful? Give feedback.
-
yeah, we should add that. |
Beta Was this translation helpful? Give feedback.
-
So the signature JSON files are designed to actaully carry multiple signatures already. They are a JSON array for each bank, with arbitrary combinations of PCR indexes, signing public keys and policy hashes. So you can already stuff as many signatures as you want into one JSON blob. And we'll find the right one for you. (Also see systemd/systemd#25224 which makes it easier to work with multiple sections) |
Beta Was this translation helpful? Give feedback.
-
hmm, so, if you generate the primary seeds anyway, then why do you want to specify SRKs explicitly in cryptenroll? if the seed is fixed to a known value then the SRK should be easily derived from it too without booting the system up? |
Beta Was this translation helpful? Give feedback.
-
I opened a PR for this: systemd/systemd#26027 It only adds the ability to enroll to an external tpm; it doesn't include any update to specify pcr hashes or any other policy-building changes. |
Beta Was this translation helpful? Give feedback.
-
In the cloud, confidential computing (CC) instances use full disk encryption (FDE) and use the instance's vTPM to control unlocking the disk without any user input (i.e. no user pin or password).
I think this is possible using systemd-cryptenroll during provisioning of new CC instances; however there are a few minor changes I think are needed:
a) When systemd-cryptsetup recreates the SRK to use with unsealing, if the template has changed in any way (e.g. if systemd was updated and changed the hardcoded template in the new version), the resulting SRK will differ from what was used for sealing, and the unsealing will fail. What this means is any sealing done with such a transient SRK is permanently stuck with the exact template currently hardcoded, and systemd can't make any changes to it (unless new templates were versioned and the template version stored with the sealed key - not a good approach I think).
a) This requires access to the TPM that will be used for unsealing, which may not be possible if the enrollment is being done by on a provisioning system, not the actual CC instance.
I'm still working through the details (and patches) but I believe the first main step is to expand systemd-cryptenroll (and supporting tpm2-util code) to allow enrolling a tpm without actually accessing that tpm:
a) since the current approach expects only a single 'signature' file, this would mean it would need to expand to allow multiple signature files; that may be best done by allowing drop-in signature files, e.g. "tpm2-pcr-signature.json.d/foo.json"
a) alternately, or maybe additionally, the signature(s) could be provided to and/or stored with systemd-cred, and systemd-cryptsetup could access systemd-cred instead of directly reading signature json file(s)
My thinking is that this will allow a provisioning system (meaning, a system that has access to the CC instance disk image, but is not actually running from the image) to:
a) populate the vTPM primary seeds (including Storage Primary Seed)
b) generate a shared, default SRK and store it into the 'reserved' persistent handle in the vTPM
Then, the CC instance will have a fully-encrypted image that can be unsealed on first boot without any special handling. Additionally, since any PCR values that may change during upgrades would be signed (instead of the PCR values themselves enrolled), kernel upgrades would not require resealing, as long as the UKI provides an updated signature (and other sources of PCR measurements can provide updated signatures).
Does all that sound reasonable? Anything I'm missing or misunderstanding?
Beta Was this translation helpful? Give feedback.
All reactions