Re: [systemd-devel] systemd-cryptenroll with TPM2
On Wed, Aug 23, 2023 at 12:50 PM Aleksandar Kostadinov wrote: > > On Wed, Aug 23, 2023 at 10:49 AM Andrei Borzenkov wrote: > <...> > > > > Sure, if you allow unencrypted systems to boot in your OS then all > > > > bets are off. You shouldn't do that of course. > > > > > > > > (in my model of mind, where automatic GPT image dissection is used the > > > > image dissection policies are how this should be locked down, see > > > > systemd.image-policy(7). You can confgure that via the kernel cmdline: > > > > in systemd.image_policy=. > > > > > > > > In systemd there's the "systemd-pcrfs@.service" and > > > > "systemd-pcrmachine.service" which will measure the identity of file > > > > systems and of /etc/machine-id into PCR 15. (systemd-cryptsetup also > > > > mesures a derivate of the volume key to PCR 15). PCR 15 is supposed to > > > > be an identifier of the OS instance. > > > > > > Wait. I was looking at this PCR. But wouldn't it be set only after the > > > volume has been unlocked? This means that before a volume is unlocked, > > > it cannot protect anything? Actually it may protect in case where > > > attacker replaced the volume with another encrypted volume. But not if > > > attacker replaced with a plain volume. > > > > > > > I try to understand this threat model. > > > > System will have kernel and initrd which are measured. Initrd will be > > configured to require encrypted volume with specific UUID. So if this > > encrypted volume is not available, booting fails. What happens depends > > on the exact initrd implementation. With dracut I think it will just > > hang indefinitely. > > > > So to boot into plain volume one needs to either replace initrd which > > invalidates measurements or use explicit command line parameters to > > override root device which hopefully is measured as well and so > > invalidates the measurements too. > > When I looked previously into clevis' initrd integration, my > recollection is that it would allow booting from unencrypted volume if > volume was unencrypted (but might be wrong). And it would try to Do not confuse different layers. Clevis is a tool to automatically decrypt (LUKS) volumes. What happens if clevis did not decrypt anything is beyond the scope of clevis. > unlock only if it found an encrypted volume. i.e. if one supplied an > unencrypted root volume with the same id as the encrypted one (and one > can obtain this id without decrypting the volume as it should be in > bootloader config already), clevis would not complain that it unlocked > nothing. Thus allowing to boot an attacker controlled system with PCRs > in a state suitable to decrypt the original volume encryption key. > It depends on how exactly the root device is looked for, but yes, if UUID is used it is possible to create a filesystem with the same UUID. And initrd or UKI are not encrypted and are in ESP. > From your reaction I assume this would not be possible with > systemd-cryptenroll. Correct? It is completely unrelated to systemd-cryptenroll. As I said, it depends on what code inside initrd is doing. > I guess I have to do my homework and try it out. Although I know > little about how it works. So failing to trick it into booting with > unencrypted volume (without modifying initrd and kernel cmd) will not > be proof that it's impossible. > > Does my concern make more sense now? > Yes, it does. > > If initrd drops into the shell when the root device is missing then it > > could indeed offer the possibility to obtain a secret key. One > > possible mitigation is to extend PCR when an interactive shell is > > entered. > > I didn't think about this but it's another thing to consider. I > thought that with secure boot enabled, initrd should not fall into a > shell. But I haven't tried that. > Basically initrd should either never fall into a shell or should > cripple at least one pinned PCR to prevent such an attack vector. > > > Or do you have something different in mind? > > >
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Wed, Aug 23, 2023 at 10:49 AM Andrei Borzenkov wrote: <...> > > > Sure, if you allow unencrypted systems to boot in your OS then all > > > bets are off. You shouldn't do that of course. > > > > > > (in my model of mind, where automatic GPT image dissection is used the > > > image dissection policies are how this should be locked down, see > > > systemd.image-policy(7). You can confgure that via the kernel cmdline: > > > in systemd.image_policy=. > > > > > > In systemd there's the "systemd-pcrfs@.service" and > > > "systemd-pcrmachine.service" which will measure the identity of file > > > systems and of /etc/machine-id into PCR 15. (systemd-cryptsetup also > > > mesures a derivate of the volume key to PCR 15). PCR 15 is supposed to > > > be an identifier of the OS instance. > > > > Wait. I was looking at this PCR. But wouldn't it be set only after the > > volume has been unlocked? This means that before a volume is unlocked, > > it cannot protect anything? Actually it may protect in case where > > attacker replaced the volume with another encrypted volume. But not if > > attacker replaced with a plain volume. > > > > I try to understand this threat model. > > System will have kernel and initrd which are measured. Initrd will be > configured to require encrypted volume with specific UUID. So if this > encrypted volume is not available, booting fails. What happens depends > on the exact initrd implementation. With dracut I think it will just > hang indefinitely. > > So to boot into plain volume one needs to either replace initrd which > invalidates measurements or use explicit command line parameters to > override root device which hopefully is measured as well and so > invalidates the measurements too. When I looked previously into clevis' initrd integration, my recollection is that it would allow booting from unencrypted volume if volume was unencrypted (but might be wrong). And it would try to unlock only if it found an encrypted volume. i.e. if one supplied an unencrypted root volume with the same id as the encrypted one (and one can obtain this id without decrypting the volume as it should be in bootloader config already), clevis would not complain that it unlocked nothing. Thus allowing to boot an attacker controlled system with PCRs in a state suitable to decrypt the original volume encryption key. >From your reaction I assume this would not be possible with systemd-cryptenroll. Correct? I guess I have to do my homework and try it out. Although I know little about how it works. So failing to trick it into booting with unencrypted volume (without modifying initrd and kernel cmd) will not be proof that it's impossible. Does my concern make more sense now? > If initrd drops into the shell when the root device is missing then it > could indeed offer the possibility to obtain a secret key. One > possible mitigation is to extend PCR when an interactive shell is > entered. I didn't think about this but it's another thing to consider. I thought that with secure boot enabled, initrd should not fall into a shell. But I haven't tried that. Basically initrd should either never fall into a shell or should cripple at least one pinned PCR to prevent such an attack vector. > Or do you have something different in mind? >
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Tue, Aug 22, 2023 at 10:45 PM Aleksandar Kostadinov wrote: > > On Tue, Aug 22, 2023 at 8:10 PM Lennart Poettering > wrote: > > On Di, 22.08.23 19:16, Aleksandar Kostadinov (akost...@redhat.com) wrote: > <...> > > > If attacker replaces volume with unencrypted one, and it boots without > > > messing up the sealing PCRs, then probably attacker can query the TPM > > > and obtain the encryption key. Despite the fact that this is not (yet) > > > implemented in cryptenroll. > > > > Sure, if you allow unencrypted systems to boot in your OS then all > > bets are off. You shouldn't do that of course. > > > > (in my model of mind, where automatic GPT image dissection is used the > > image dissection policies are how this should be locked down, see > > systemd.image-policy(7). You can confgure that via the kernel cmdline: > > in systemd.image_policy=. > > > > In systemd there's the "systemd-pcrfs@.service" and > > "systemd-pcrmachine.service" which will measure the identity of file > > systems and of /etc/machine-id into PCR 15. (systemd-cryptsetup also > > mesures a derivate of the volume key to PCR 15). PCR 15 is supposed to > > be an identifier of the OS instance. > > Wait. I was looking at this PCR. But wouldn't it be set only after the > volume has been unlocked? This means that before a volume is unlocked, > it cannot protect anything? Actually it may protect in case where > attacker replaced the volume with another encrypted volume. But not if > attacker replaced with a plain volume. > I try to understand this threat model. System will have kernel and initrd which are measured. Initrd will be configured to require encrypted volume with specific UUID. So if this encrypted volume is not available, booting fails. What happens depends on the exact initrd implementation. With dracut I think it will just hang indefinitely. So to boot into plain volume one needs to either replace initrd which invalidates measurements or use explicit command line parameters to override root device which hopefully is measured as well and so invalidates the measurements too. If initrd drops into the shell when the root device is missing then it could indeed offer the possibility to obtain a secret key. One possible mitigation is to extend PCR when an interactive shell is entered. Or do you have something different in mind?
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Di, 22.08.23 22:35, Aleksandar Kostadinov (akost...@redhat.com) wrote: > On Tue, Aug 22, 2023 at 8:10 PM Lennart Poettering > wrote: > > On Di, 22.08.23 19:16, Aleksandar Kostadinov (akost...@redhat.com) wrote: > <...> > > > If attacker replaces volume with unencrypted one, and it boots without > > > messing up the sealing PCRs, then probably attacker can query the TPM > > > and obtain the encryption key. Despite the fact that this is not (yet) > > > implemented in cryptenroll. > > > > Sure, if you allow unencrypted systems to boot in your OS then all > > bets are off. You shouldn't do that of course. > > > > (in my model of mind, where automatic GPT image dissection is used the > > image dissection policies are how this should be locked down, see > > systemd.image-policy(7). You can confgure that via the kernel cmdline: > > in systemd.image_policy=. > > > > In systemd there's the "systemd-pcrfs@.service" and > > "systemd-pcrmachine.service" which will measure the identity of file > > systems and of /etc/machine-id into PCR 15. (systemd-cryptsetup also > > mesures a derivate of the volume key to PCR 15). PCR 15 is supposed to > > be an identifier of the OS instance. > > Wait. I was looking at this PCR. But wouldn't it be set only after the > volume has been unlocked? This means that before a volume is unlocked, > it cannot protect anything? Actually it may protect in case where > attacker replaced the volume with another encrypted volume. But not if > attacker replaced with a plain volume. As I said earlier: if you don't encrypt you lost anyway. This is not a scenario I care about in my view of the world. And frankly, it really doesn't make much sense to try to lock down boot but not actually encrypt the disk... > Or is it measured with the *encrypted* volume key which would actually > protect from volume replacement of any sort (I think) and would mostly > solve my concern? No, we measure the decrypted volume key (or actually, we measure the result of an HMAC of a fixed string, keyed by the volume key, since we don't want the key to show up in measurement logs in any useable way). > I mean if somehow the LVM structure including the encrypted key(s) are > measured somewhere, then such an attack should not be viable. LVM? what's LVM got to do with anything? > I guess I should test whether replacing the volume with non-encrypted > will work. If it works, then there might be an issue. If it does not > work, then sealing with PCR 15 might be what will get me going, > because replacing with an encrypted volume will definitely modify it > and block decrypting of the original key. In my view of the world you have an authenticated + measured UKI that unlocks the encrypted root fs, and simply refuses to boot if the root fs is not encrypted with a key it can acquire somehow. This should give you all the protection you need. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Tue, Aug 22, 2023 at 8:10 PM Lennart Poettering wrote: > On Di, 22.08.23 19:16, Aleksandar Kostadinov (akost...@redhat.com) wrote: <...> > > If attacker replaces volume with unencrypted one, and it boots without > > messing up the sealing PCRs, then probably attacker can query the TPM > > and obtain the encryption key. Despite the fact that this is not (yet) > > implemented in cryptenroll. > > Sure, if you allow unencrypted systems to boot in your OS then all > bets are off. You shouldn't do that of course. > > (in my model of mind, where automatic GPT image dissection is used the > image dissection policies are how this should be locked down, see > systemd.image-policy(7). You can confgure that via the kernel cmdline: > in systemd.image_policy=. > > In systemd there's the "systemd-pcrfs@.service" and > "systemd-pcrmachine.service" which will measure the identity of file > systems and of /etc/machine-id into PCR 15. (systemd-cryptsetup also > mesures a derivate of the volume key to PCR 15). PCR 15 is supposed to > be an identifier of the OS instance. Wait. I was looking at this PCR. But wouldn't it be set only after the volume has been unlocked? This means that before a volume is unlocked, it cannot protect anything? Actually it may protect in case where attacker replaced the volume with another encrypted volume. But not if attacker replaced with a plain volume. Or is it measured with the *encrypted* volume key which would actually protect from volume replacement of any sort (I think) and would mostly solve my concern? I mean if somehow the LVM structure including the encrypted key(s) are measured somewhere, then such an attack should not be viable. I guess I should test whether replacing the volume with non-encrypted will work. If it works, then there might be an issue. If it does not work, then sealing with PCR 15 might be what will get me going, because replacing with an encrypted volume will definitely modify it and block decrypting of the original key. <...> > > I didn't expect the unattended server TPM2 encryption to be such a > > muddy ground. Probably because serious use cases also involve more > > infrastructure and dedicated admins, etc. > > It is certainly my intention to make this all "just work" and "default > on", even on consumer hw. Windows does it, so we should be able to do > that as well. Much needed! ♥ > Lennart > > -- > Lennart Poettering, Berlin >
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Di, 22.08.23 19:16, Aleksandar Kostadinov (akost...@redhat.com) wrote: > > > I'm concerned though about an attacker replacing the encrypted root volume > > > with a non-encrypted one. Which may result in system booting an attacker > > > controlled environment while PCRs may be in a state that allows decryption > > > of the original root volume. > > > > > > Would anything prevent the system from booting with a replaced root > > > volume? > > > > Well, when you bind your disk to the TPM then this means you place a > > TPM-encrypted key in the LUKS header. This key has to be passed to the > > right TPM to be unlocked. This means that if an attacker just has the > > disk it's hard for them to acquire the decrypted key if it lacks the > > TPM. But it also means that if an attacker wants to replace the disk > > its very hard to forge key that is locked against that specific TPM. > > If attacker replaces volume with unencrypted one, and it boots without > messing up the sealing PCRs, then probably attacker can query the TPM > and obtain the encryption key. Despite the fact that this is not (yet) > implemented in cryptenroll. Sure, if you allow unencrypted systems to boot in your OS then all bets are off. You shouldn't do that of course. (in my model of mind, where automatic GPT image dissection is used the image dissection policies are how this should be locked down, see systemd.image-policy(7). You can confgure that via the kernel cmdline: in systemd.image_policy=. In systemd there's the "systemd-pcrfs@.service" and "systemd-pcrmachine.service" which will measure the identity of file systems and of /etc/machine-id into PCR 15. (systemd-cryptsetup also mesures a derivate of the volume key to PCR 15). PCR 15 is supposed to be an identifier of the OS instance. > > It analyzes the UEFI TPM event log (which lists all measurements made > > to PCRs), tries to recognize components in it safely. And then is > > supposed to use that to generate signed PCR policies from that, based > > on a keypair stored on the local TPM, that is itself protected by one > > of its own signed PCR policies. > > > > In the long run the way I envision this we'd have two signed PCR > > policies in place: > > > > 1. A vendor supplied one that covers the UKI and its resources (this > >already pretty much exists), i.e. PCR 11. This one is pre-computed > >at build time of the OS and hence can only cover resources known at > >that time. > > > > 2. A locally maintained one on the individual system, based on a local > >key, that covers everything inherently local that is hard to > >predict from the outside (and for good measure also covers the > >vendor supplied stuff, because why not). This would then cover PCRs > >0-7, 9, 11-13, 15, i.e. everything that is reasonably stable > >locally. > > > > Alas, as mentioned this is WIP, still. > > I didn't expect the unattended server TPM2 encryption to be such a > muddy ground. Probably because serious use cases also involve more > infrastructure and dedicated admins, etc. It is certainly my intention to make this all "just work" and "default on", even on consumer hw. Windows does it, so we should be able to do that as well. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Tue, Aug 22, 2023 at 4:16 PM Lennart Poettering wrote: > > On Mo, 21.08.23 17:40, Aleksandar Kostadinov (akost...@redhat.com) wrote: > > > Hello, > > > > This is more of a user question but I didn't find any other suitable forum > > to ask. > > > > I want to install a server that should have an encrypted root but be able > > to reboot unattended. > > > > systemd-cryptenroll with TPM2 looks like a viable option. I'm concerned > > about which PCRs to pin so that an average attacker won't be able to > > decrypt the volume having physical possession of the server. This means I'm > > not concerned about cracking the TPM chip or reading out life memory. > > > > To me it is acceptable to pin a lot of them so that adding/changing devices > > would prevent automatic decryption. Also 5 looks good about changed GPT > > partitions. > > > > I'm concerned though about an attacker replacing the encrypted root volume > > with a non-encrypted one. Which may result in system booting an attacker > > controlled environment while PCRs may be in a state that allows decryption > > of the original root volume. > > > > Would anything prevent the system from booting with a replaced root > > volume? > > Well, when you bind your disk to the TPM then this means you place a > TPM-encrypted key in the LUKS header. This key has to be passed to the > right TPM to be unlocked. This means that if an attacker just has the > disk it's hard for them to acquire the decrypted key if it lacks the > TPM. But it also means that if an attacker wants to replace the disk > its very hard to forge key that is locked against that specific TPM. If attacker replaces volume with unencrypted one, and it boots without messing up the sealing PCRs, then probably attacker can query the TPM and obtain the encryption key. Despite the fact that this is not (yet) implemented in cryptenroll. > > If it can boot in such a way, which PCRs need to be pinned to remove the > > ability to decrypt the original root volume? > > PCR pinning is a science of its own, due to the "brittleness" of > measurements, if you update firmware, boot loader, … > > So you can bind things to a bunch of PCRs, but that means you simply > cannot make changes to things anymore from that point on, and never > allow the components to update. That's quite often not what you want > in a secure system though: software has bugs after all, and *must* be > regularly updated. For my use case the idea is that sometimes I can update things while physically with the server. For simple software updates, I hope PCRs could be predicted. > I am currently working on a mechanism to deal with this brittleness, > here in this git branch: > > https://github.com/poettering/systemd/commits/pcrlock Will check it out! > It analyzes the UEFI TPM event log (which lists all measurements made > to PCRs), tries to recognize components in it safely. And then is > supposed to use that to generate signed PCR policies from that, based > on a keypair stored on the local TPM, that is itself protected by one > of its own signed PCR policies. > > In the long run the way I envision this we'd have two signed PCR > policies in place: > > 1. A vendor supplied one that covers the UKI and its resources (this >already pretty much exists), i.e. PCR 11. This one is pre-computed >at build time of the OS and hence can only cover resources known at >that time. > > 2. A locally maintained one on the individual system, based on a local >key, that covers everything inherently local that is hard to >predict from the outside (and for good measure also covers the >vendor supplied stuff, because why not). This would then cover PCRs >0-7, 9, 11-13, 15, i.e. everything that is reasonably stable >locally. > > Alas, as mentioned this is WIP, still. I didn't expect the unattended server TPM2 encryption to be such a muddy ground. Probably because serious use cases also involve more infrastructure and dedicated admins, etc. > Lennart > > -- > Lennart Poettering, Berlin
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Mo, 21.08.23 19:56, Aleksandar Kostadinov (akost...@redhat.com) wrote: > Thanks, this is what I was also considering the feasibility of. And whether > it made sense to begin with. Any idea how can this be done with systemd? > > In man I read: > > > Note that currently when enrolling a new key of one of the five > > supported types listed above, it is required to first provide a > > passphrase, a recovery key or a FIDO2 token. It's currently not > > supported to unlock a device with a TPM2/PKCS#11 key in order to > enroll > > a new TPM2/PKCS#11 key. Thus, if in future key roll-over is desired > > So I wonder if systemd already does that, or is it just an artificial > limitation? Would be wonderful if it already did so. It's just that noone implemented this. The unlocking code paths via cryptsetup and in cryptenroll are quite different, which doesn't make this trivial. But pacthes welcome. Generally, I am very much of the opinion that we shouldn't change the disk whenever PCRs change. Instead we should use signed PCR policies to accomodate for "clean" PCR changes (as mentioned in the other mail in this thread), i.e. simply sign a new PCR policy if we learn about a new "golden" PCR state we want to permit. This is much more robust and scales better. Moreover, it makes it easy to invalidate old golden states, by implicitly binding things to an nvindex counter object in the TPM at the same time. Such rollback protection is kinda crucial I am sure to guarantee security of non-interactive systems. > P.S. Also another thing I was considering was that if I did this > "extension", then I'm not sure how to then properly setup the sealing. But > maybe with the signed PCRs support it can work as PCRs don't need to be in > the expected state at configuration time. But also I want to do with as > little modifications from defaults as possible. If I have to rewrite the > whole thing, it will be hard but also I don't want to risk making mistakes > that original scripts already avoid. Neither for the literla PCR policies nor for the signed PCR policies the PCRs actailly need to be in the state we expected states when enrolling. Support for the former was recently added upstream. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Mo, 21.08.23 17:40, Aleksandar Kostadinov (akost...@redhat.com) wrote: > Hello, > > This is more of a user question but I didn't find any other suitable forum > to ask. > > I want to install a server that should have an encrypted root but be able > to reboot unattended. > > systemd-cryptenroll with TPM2 looks like a viable option. I'm concerned > about which PCRs to pin so that an average attacker won't be able to > decrypt the volume having physical possession of the server. This means I'm > not concerned about cracking the TPM chip or reading out life memory. > > To me it is acceptable to pin a lot of them so that adding/changing devices > would prevent automatic decryption. Also 5 looks good about changed GPT > partitions. > > I'm concerned though about an attacker replacing the encrypted root volume > with a non-encrypted one. Which may result in system booting an attacker > controlled environment while PCRs may be in a state that allows decryption > of the original root volume. > > Would anything prevent the system from booting with a replaced root > volume? Well, when you bind your disk to the TPM then this means you place a TPM-encrypted key in the LUKS header. This key has to be passed to the right TPM to be unlocked. This means that if an attacker just has the disk it's hard for them to acquire the decrypted key if it lacks the TPM. But it also means that if an attacker wants to replace the disk its very hard to forge key that is locked against that specific TPM. > If it can boot in such a way, which PCRs need to be pinned to remove the > ability to decrypt the original root volume? PCR pinning is a science of its own, due to the "brittleness" of measurements, if you update firmware, boot loader, … So you can bind things to a bunch of PCRs, but that means you simply cannot make changes to things anymore from that point on, and never allow the components to update. That's quite often not what you want in a secure system though: software has bugs after all, and *must* be regularly updated. I am currently working on a mechanism to deal with this brittleness, here in this git branch: https://github.com/poettering/systemd/commits/pcrlock It analyzes the UEFI TPM event log (which lists all measurements made to PCRs), tries to recognize components in it safely. And then is supposed to use that to generate signed PCR policies from that, based on a keypair stored on the local TPM, that is itself protected by one of its own signed PCR policies. In the long run the way I envision this we'd have two signed PCR policies in place: 1. A vendor supplied one that covers the UKI and its resources (this already pretty much exists), i.e. PCR 11. This one is pre-computed at build time of the OS and hence can only cover resources known at that time. 2. A locally maintained one on the individual system, based on a local key, that covers everything inherently local that is hard to predict from the outside (and for good measure also covers the vendor supplied stuff, because why not). This would then cover PCRs 0-7, 9, 11-13, 15, i.e. everything that is reasonably stable locally. Alas, as mentioned this is WIP, still. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd-cryptenroll with TPM2
Thanks, this is what I was also considering the feasibility of. And whether it made sense to begin with. Any idea how can this be done with systemd? In man I read: > Note that currently when enrolling a new key of one of the five > supported types listed above, it is required to first provide a > passphrase, a recovery key or a FIDO2 token. It's currently not > supported to unlock a device with a TPM2/PKCS#11 key in order to enroll > a new TPM2/PKCS#11 key. Thus, if in future key roll-over is desired So I wonder if systemd already does that, or is it just an artificial limitation? Would be wonderful if it already did so. P.S. Also another thing I was considering was that if I did this "extension", then I'm not sure how to then properly setup the sealing. But maybe with the signed PCRs support it can work as PCRs don't need to be in the expected state at configuration time. But also I want to do with as little modifications from defaults as possible. If I have to rewrite the whole thing, it will be hard but also I don't want to risk making mistakes that original scripts already avoid. On Mon, Aug 21, 2023 at 7:37 PM Mantas Mikulėnas wrote: > Have your initramfs *extend* a PCR after it retrieves the key from the > TPM, before it switches to (or even unlocks) the rootfs. As most PCRs > cannot be rolled back without a reboot, this would prevent the key from > being unsealed from a running system even if it manages to boot (without > causing the initramfs to fail earlier). Systemd already has some tools for > this; see "systemd-pcrphase". > > On Mon, Aug 21, 2023, 17:40 Aleksandar Kostadinov > wrote: > >> Hello, >> >> This is more of a user question but I didn't find any other suitable >> forum to ask. >> >> I want to install a server that should have an encrypted root but be able >> to reboot unattended. >> >> systemd-cryptenroll with TPM2 looks like a viable option. I'm concerned >> about which PCRs to pin so that an average attacker won't be able to >> decrypt the volume having physical possession of the server. This means I'm >> not concerned about cracking the TPM chip or reading out life memory. >> >> To me it is acceptable to pin a lot of them so that adding/changing >> devices would prevent automatic decryption. Also 5 looks good about changed >> GPT partitions. >> >> I'm concerned though about an attacker replacing the encrypted root >> volume with a non-encrypted one. Which may result in system booting an >> attacker controlled environment while PCRs may be in a state that allows >> decryption of the original root volume. >> >> Would anything prevent the system from booting with a replaced root >> volume? >> >> If it can boot in such a way, which PCRs need to be pinned to remove the >> ability to decrypt the original root volume? >> >> If there is presently no such PCR, can some custom validation be added in >> the process to take care of that? >> >> Thank you! >> >
Re: [systemd-devel] systemd-cryptenroll with TPM2
Have your initramfs *extend* a PCR after it retrieves the key from the TPM, before it switches to (or even unlocks) the rootfs. As most PCRs cannot be rolled back without a reboot, this would prevent the key from being unsealed from a running system even if it manages to boot (without causing the initramfs to fail earlier). Systemd already has some tools for this; see "systemd-pcrphase". On Mon, Aug 21, 2023, 17:40 Aleksandar Kostadinov wrote: > Hello, > > This is more of a user question but I didn't find any other suitable forum > to ask. > > I want to install a server that should have an encrypted root but be able > to reboot unattended. > > systemd-cryptenroll with TPM2 looks like a viable option. I'm concerned > about which PCRs to pin so that an average attacker won't be able to > decrypt the volume having physical possession of the server. This means I'm > not concerned about cracking the TPM chip or reading out life memory. > > To me it is acceptable to pin a lot of them so that adding/changing > devices would prevent automatic decryption. Also 5 looks good about changed > GPT partitions. > > I'm concerned though about an attacker replacing the encrypted root volume > with a non-encrypted one. Which may result in system booting an attacker > controlled environment while PCRs may be in a state that allows decryption > of the original root volume. > > Would anything prevent the system from booting with a replaced root volume? > > If it can boot in such a way, which PCRs need to be pinned to remove the > ability to decrypt the original root volume? > > If there is presently no such PCR, can some custom validation be added in > the process to take care of that? > > Thank you! >
[systemd-devel] systemd-cryptenroll with TPM2
Hello, This is more of a user question but I didn't find any other suitable forum to ask. I want to install a server that should have an encrypted root but be able to reboot unattended. systemd-cryptenroll with TPM2 looks like a viable option. I'm concerned about which PCRs to pin so that an average attacker won't be able to decrypt the volume having physical possession of the server. This means I'm not concerned about cracking the TPM chip or reading out life memory. To me it is acceptable to pin a lot of them so that adding/changing devices would prevent automatic decryption. Also 5 looks good about changed GPT partitions. I'm concerned though about an attacker replacing the encrypted root volume with a non-encrypted one. Which may result in system booting an attacker controlled environment while PCRs may be in a state that allows decryption of the original root volume. Would anything prevent the system from booting with a replaced root volume? If it can boot in such a way, which PCRs need to be pinned to remove the ability to decrypt the original root volume? If there is presently no such PCR, can some custom validation be added in the process to take care of that? Thank you!
