Using systemd-cryptenroll for FDE of cloud instances

[ddstreet]

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:

1. tpm2-util uses a transient storage root key (SRK), created with CreatePrimary using a hardcoded template.
   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.
2. systemd-cryptenroll (and tpm2-util) use the current PCR values, and don't allow specifying measured values to use for enrollment.
3. systemd-cryptenroll (and tpm2-util) allows specifying a public key instead of expected PCR values, however only a single public key can be used for all combined PCR values. Since many PCRs are used to measure binaries from different sources, this makes signing a single combined PCR value difficult. For example, a distro can easily calculate the value of PCR 11 that results from a signed UKI that the distro generates, but the distro can't possibly predict what the value of (for example) PCR 0 will be.

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:

1. the SRK public key (and its persistent handle for cryptsetup to use) can be provided instead of using an internally-hardcoded template
2. expected PCR values can be specified, instead of read from current PCR values
3. multiple public keys can be provided, and matched to specific PCR(s)
   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:

1. generate the vTPM
   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
2. luks-encrypt the CC instance partitions (i.e. all except the ESP)
3. enroll the vTPM to the luks device(s) using the vTPM SRK, along with expected PCR value(s) and/or public key(s) used for signing expected PCR value(s)

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?

[ddstreet]

Ha, I am amused this discussion is number 42

[aplanas]

2. systemd-cryptenroll (and tpm2-util) use the current PCR values, and don't allow specifying measured values to use for enrollment.

There is a try to address this in systemd/systemd#24597. Is your patch using a similar command line parameters?

3. enroll the vTPM to the luks device(s) using the vTPM SRK, along with expected PCR value(s) and/or public key(s) used for signing expected PCR value(s)

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?

[ddstreet]

2. systemd-cryptenroll (and tpm2-util) use the current PCR values, and don't allow specifying measured values to use for enrollment.

There is a try to address this in systemd/systemd#24597. Is your patch using a similar command line parameters?

I hadn't landed on a specific cli param format.

I wonder if we should consider if the tpm2 configuration might get too verbose to be able to sanely satisfy on the cli; for example if we have multiple public keys associated with multiple pcrs as well as multiple pcr hashes.

Additionally, I'm pretty sure that for those cases where users do want to use specific pcr hashes (instead of signatures), they will want to be able to enroll multiple hash values, not just a single value for each pcr; with just a single pcr hash, you are locked into a single binary version for what you're measuring. For example, the hash for the currently installed binaries (firmware, kernel, sd-stub, etc) is currently enrolled; if any is updated and a new hash needs to be enrolled, it would need to either replace the current enrollment slot/token, or add a new enrollment slot/token. Adding a new slot/token for each software update might result in a lot of enrolled slots/tokens, and would require some code to go back and remove no-longer-needed enrollments (and policy to decide when they aren't needed). Replacing the current enrollment slot/token would mean if the system failed on reboot (e.g. due to a bug in the new binaries) the system would be unrecoverable. Being able to provide a list of hashes into the enrollment should address that, although there could be other ways of approaching it.

My point is that the systemd-cryptenroll cli parameter format could possibly get extremely verbose, and maybe we should restrict it to only simple/basic cases, and have a different way to provide configuration for more complex cases (e.g. a json file?)

However, as I said I hadn't got to the point of specific format yet, so maybe extending the cli parameter format is the best approach; I don't have strong feelings (yet).

3. enroll the vTPM to the luks device(s) using the vTPM SRK, along with expected PCR value(s) and/or public key(s) used for signing expected PCR value(s)

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?

The SRK is just a public/private key pair, and only the public part can be extracted from the vTPM. And yes, you can seal (i.e. encrypt) a secret with only the public part; but as with all asymmetric encryption, you need the private part to unseal (i.e. decrypt) the secret. At least, that's my understanding; corrections are welcome :-)

[poettering]

Additionally, I'm pretty sure that for those cases where users do want to use specific pcr hashes (instead of signatures), they will want to be able to enroll multiple hash values, not just a single value for each pcr; with just a single pcr hash, you are locked into a single binary version for what you're measuring.

So, I dont follow here. I mean, to me enrolling a hash means "only this very version. full stop." And enrolling a pubkey means "any version this key has signed". So one is to pinpoint one and the other to pin many versions. Thus I see no real usecase for pinning multiple hashes, because if you do that you might as well just sign them all and then enroll the pubkey instead. Which scales much much better. You could even immediately throw away the private key then, if you never intend to add more hashes.

Or with other words: if you want to enroll multiple hashes you are doing it wrong: enroll a public key instead.

[ddstreet]

Additionally, I'm pretty sure that for those cases where users do want to use specific pcr hashes (instead of signatures), they will want to be able to enroll multiple hash values, not just a single value for each pcr; with just a single pcr hash, you are locked into a single binary version for what you're measuring.

So, I dont follow here. I mean, to me enrolling a hash means "only this very version. full stop." And enrolling a pubkey means "any version this key has signed". So one is to pinpoint one and the other to pin many versions. Thus I see no real usecase for pinning multiple hashes, because if you do that you might as well just sign them all and then enroll the pubkey instead. Which scales much much better. You could even immediately throw away the private key then, if you never intend to add more hashes.

Or with other words: if you want to enroll multiple hashes you are doing it wrong: enroll a public key instead.

That's fine as a policy decision from the systemd side (i.e. we simply don't allow a list of hashes, for multiple possible hashes just enroll a pubkey and provide a signature file for all hashes). My thoughts were around the cmdline api, and restricting each pcr to a single hash certainly simplifies the parameter format.

[ddstreet]

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).

[poettering]

   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).

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.

[poettering]

3. systemd-cryptenroll (and tpm2-util) allows specifying a public key instead of expected PCR values, however only a single public key can be used for all combined PCR values. Since many PCRs are used to measure binaries from different sources, this makes signing a single combined PCR value difficult. For example, a distro can easily calculate the value of PCR 11 that results from a signed UKI that the distro generates, but the distro can't possibly predict what the value of (for example) PCR 0 will be.

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.

[poettering]

1. the SRK public key (and its persistent handle for cryptsetup to use) can be provided instead of using an internally-hardcoded template

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?

[ddstreet]

1. the SRK public key (and its persistent handle for cryptsetup to use) can be provided instead of using an internally-hardcoded template

hmm, persistent? you want to store the key in the nvram? why?

not systemd; the 'shared' SRK is stored in the vTPM persistent section in the handle designated in the "TCG TPM v2.0 Provisioning Guidance" doc section 7.8; specifically, it recommends handle 0x81000001.

we so far focus on never persisting anything in the tpm, but exclusively in the luks superblock.

right, and for this case (of using a persistent key instead of using a template to generate a primary key) we would just add a field to the luks header token indicating which handle has the key that we should use for unsealing.

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?

Yes, the same idea, I think. A provisioning system would:

• generate the vTPM, which includes generating its seeds and any initial keys, including the 'shared' (or default) SRK.
• extract the public part of the SRK.
• encrypt the instance's disk partitions (all except the ESP) as luks devices.
• systemd-cryptenroll the luks devices, using the SRK for sealing.

I think I differ from your description around the deployment system; the provisioning system should be able to 'know' all the values it needs to perform the luks enrollment with the new vTPM. Specifically:

• the SRK just created and added to the new vTPM should be used for sealing (which can be done on the provisioning system, without directly using the vTPM) and unsealing (on first boot by the new instance)
• the authorization policy isn't - or at least, shouldn't be - specific to the vTPM, so all its values should be known to the provisioning system.

(maybe we should do another conf call about this?

sure, I'll set one up

[poettering]

• expected PCR values can be specified, instead of read from current PCR values

yeah, we should add that.

[poettering]

3. multiple public keys can be provided, and matched to specific PCR(s)
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)

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)

[ddstreet]

3. multiple public keys can be provided, and matched to specific PCR(s)
   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)

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)

The issue is that the signatures will likely come from different sources, e.g. the distro providing the UKI will provide the signature file for PCR 11, while a firmware provider would have to be who provides the signature file for PCR 0. It's certainly possible for some 3rd party to combine multiple signature files to the single one that systemd expects, but that's kind of adding unnecessary work, when systemd could just read multiple signature files.

[poettering]

1. generate the vTPM
   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

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?

[ddstreet]

1. generate the vTPM
   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

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?

To avoid adding specific requirements to the vTPM generation. Otherwise, the provisioning system would have to change to use the exact same template as systemd inside the target system. The provisioning system may have its own templates it uses for key generation, it may not be possible/allowed to alter the provisioning templates, the provisioning systems might be doing vTPM provisioning for other instance types, the vTPM generation may be done entirely separately from the instance encryption, etc. In short, systemd shouldn't add unnecessary requirements for a specific template onto all vTPM provisioning systems; the TCG issued guidance to TPM provisioners to store a shared SRK, and if systemd had a mechanism to use it, that would avoid TPM provisioners to have to change.

[ddstreet]

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.