3 ms·

You've been able to do LUKS filesystems auto-unlocked by TPMs before; the new thing here is just that systemd-cryptsetup can do it.

mschuster91 6y ago
I don't get why this is a feature that people want. In case of theft / loss it doesn't offer any security benefits over no encryption.
- hlieberman 6y ago
  The main thing this is used for in the Linux world is as part of a trusted boot pathway. It allows you to use the TPM to perform measurements on the boot chain and refuse to decrypt the data on the encrypted filesystem if it fails those checks.
- vladvasiliu 6y ago
  As the sibling has said, this is usually used with SecureBoot. The system won't unlock the drives if, for example, you attempt booting an unsigned kernel image, change the boot order or otherwise tamper with the system setup. Granted, in case of theft, the computer will boot up if nothing is done to it. But in the case of a "user" computer where no services are listening, the risk is relatively low. In order to get access to the decrypted disk contents you'd have to exploit some vulnerability in Linux and / or the login manager.
  - lmilcin 6y ago
    If you can boot it up there are ways to hack it. Almost every machine has some services exposed and there are also hardware-based attacks possible.
    - Nextgrid 6y ago
      It does raise the bar though compared to a completely unencrypted drive, and given it's seamless if done properly, it's a nice way to increase security without compromising user experience at all.
    - redprince 6y ago
      The alternative is to set a PIN on the TPM. It will not unlock without it and go into lockout after a few attempts. Some people consider it more convenient to just boot the thing, take the protection against casual loss of confidentiality and accept the risk they might face from determined attackers.
    - vladvasiliu 6y ago
      Your points are true. But I don't think we're talking about absolutes here. This is a tradeoff. A "random user"[0] might be put off by having to type in a password every time they boot up their PC and forego disk encryption altogether. This approach is a net improvement over an unencrypted drive, even if it's not perfect. As usual in matters of security, threat modelling is important. Who are you and who are your defending againts? Are you some high(-enough)-profile target with potential access to interesting infrastructure or data? You may want to not rely on only this approach. As siblings have said, some kind of supplemental factor could be better. Say a challenge-response factor based on a Yubikey. Also, if the thief is determined, they may attempt to steal the laptop while it's running. You may want to look into desktops if that's the case. And not plug them into a UPS, of course. But are you just a random Joe whose threat model is that you have some photos you wouldn't like seen, maybe some personal documents, but not much more? Then you need "just enough protection". If someone steals your PC, it's likely for the PC itself and not for the data it carries. They may want to check what's on it, see if there's anything juicy. Might even try "password" or something to unlock it. But they will probably not spend too much time trying to brute force Linux (or Windows for that matter). > Almost every machine has some services exposed How often is this the case on a random user's machine? Even on my Windows machine I've only got SMB and RDP listening. Which I've manually enabled. On my Arch Linux machine, which is my actual work machine, only SSH listens. Which I've manually installed and enabled. On an ubuntu desktop 20.10 install, there's no SSH server installed. There are no daemons listening on the external interface. I guess you may attempt some attack against the DHCP client if you really want to get into that machine. I also suppose the pipe wrench exploit can still be tried. > and there are also hardware-based attacks possible Don't you think that if someone's going to invest the time and ressources to conduct such an attack against your PC you might be the kind of target who should be aware that's a possibility? Which brings us back to the point above about threat-modelling. --- [0] I realize we're talking about LUKS and Linux, so maybe the "random user" isn't all that random. But maybe it's a "mom's computer" on which someone installed Ubuntu or something.
- prussian 6y ago
  I know at least one person using bitlocker (windows) with this TPM unlock feature and lost access to his data when he had to get his laptop repaired. People need to be aware this can happen when using it and should remember to add a password key to their luks container.
  - redprince 6y ago
    The whole song and dance where Windows forces you to save the recovery key on an external medium and tells you what it's for must have completely slipped his mind. Though I'm fairly certain that Linux will forego this and just assumes you known what you're doing.
    - Arnavion 6y ago
      >Though I'm fairly certain that Linux will forego this and just assumes you known what you're doing. Yes, even the documentation for the systemd feature implies generating the recovery key is a separate optional step.
- nix23 6y ago
  The auto-unlock thing is more for Datacenters etc. If your SSD/HD explode you can safely throw them into the recycle-bin, without the fear that someone can access the data stored on.

mschuster91 6y ago

I don't get why this is a feature that people want. In case of theft / loss it doesn't offer any security benefits over no encryption.

hlieberman 6y ago
The main thing this is used for in the Linux world is as part of a trusted boot pathway. It allows you to use the TPM to perform measurements on the boot chain and refuse to decrypt the data on the encrypted filesystem if it fails those checks.
vladvasiliu 6y ago
As the sibling has said, this is usually used with SecureBoot. The system won't unlock the drives if, for example, you attempt booting an unsigned kernel image, change the boot order or otherwise tamper with the system setup. Granted, in case of theft, the computer will boot up if nothing is done to it. But in the case of a "user" computer where no services are listening, the risk is relatively low. In order to get access to the decrypted disk contents you'd have to exploit some vulnerability in Linux and / or the login manager.
- lmilcin 6y ago
  If you can boot it up there are ways to hack it. Almost every machine has some services exposed and there are also hardware-based attacks possible.
  - Nextgrid 6y ago
    It does raise the bar though compared to a completely unencrypted drive, and given it's seamless if done properly, it's a nice way to increase security without compromising user experience at all.
  - redprince 6y ago
    The alternative is to set a PIN on the TPM. It will not unlock without it and go into lockout after a few attempts. Some people consider it more convenient to just boot the thing, take the protection against casual loss of confidentiality and accept the risk they might face from determined attackers.
  - vladvasiliu 6y ago
    Your points are true. But I don't think we're talking about absolutes here. This is a tradeoff. A "random user"[0] might be put off by having to type in a password every time they boot up their PC and forego disk encryption altogether. This approach is a net improvement over an unencrypted drive, even if it's not perfect. As usual in matters of security, threat modelling is important. Who are you and who are your defending againts? Are you some high(-enough)-profile target with potential access to interesting infrastructure or data? You may want to not rely on only this approach. As siblings have said, some kind of supplemental factor could be better. Say a challenge-response factor based on a Yubikey. Also, if the thief is determined, they may attempt to steal the laptop while it's running. You may want to look into desktops if that's the case. And not plug them into a UPS, of course. But are you just a random Joe whose threat model is that you have some photos you wouldn't like seen, maybe some personal documents, but not much more? Then you need "just enough protection". If someone steals your PC, it's likely for the PC itself and not for the data it carries. They may want to check what's on it, see if there's anything juicy. Might even try "password" or something to unlock it. But they will probably not spend too much time trying to brute force Linux (or Windows for that matter). > Almost every machine has some services exposed How often is this the case on a random user's machine? Even on my Windows machine I've only got SMB and RDP listening. Which I've manually enabled. On my Arch Linux machine, which is my actual work machine, only SSH listens. Which I've manually installed and enabled. On an ubuntu desktop 20.10 install, there's no SSH server installed. There are no daemons listening on the external interface. I guess you may attempt some attack against the DHCP client if you really want to get into that machine. I also suppose the pipe wrench exploit can still be tried. > and there are also hardware-based attacks possible Don't you think that if someone's going to invest the time and ressources to conduct such an attack against your PC you might be the kind of target who should be aware that's a possibility? Which brings us back to the point above about threat-modelling. --- [0] I realize we're talking about LUKS and Linux, so maybe the "random user" isn't all that random. But maybe it's a "mom's computer" on which someone installed Ubuntu or something.
prussian 6y ago
I know at least one person using bitlocker (windows) with this TPM unlock feature and lost access to his data when he had to get his laptop repaired. People need to be aware this can happen when using it and should remember to add a password key to their luks container.
- redprince 6y ago
  The whole song and dance where Windows forces you to save the recovery key on an external medium and tells you what it's for must have completely slipped his mind. Though I'm fairly certain that Linux will forego this and just assumes you known what you're doing.
  - Arnavion 6y ago
    >Though I'm fairly certain that Linux will forego this and just assumes you known what you're doing. Yes, even the documentation for the systemd feature implies generating the recovery key is a separate optional step.
nix23 6y ago
The auto-unlock thing is more for Datacenters etc. If your SSD/HD explode you can safely throw them into the recycle-bin, without the fear that someone can access the data stored on.