What's the point of automatic on-boot decrypting LUKS volumes?

3 points by q2dg 2 years ago | 4 comments

Hello. You know that a "disadvantage" of wanting to have a LUKS volume decrypted at system startup is that a passphrase must be provided interactively. Since this is somewhat cumbersome, there are many methods that allow this passphrase to be indicated non-interactively using some type of keystore (systemd-cryptenroll, Tang/Clevis, etc). My question is: what is the point of having an encrypted disk, then, if it will be automatically decrypted when the system boots? A thief who steals my laptop with this automatic configuration would not have any impediments to accessing it! I'm missing some point here. Thank you so much

yokaze 2 years ago |

Well, first off, while you can configure it that way, I don't think that is the primary use-case. The primary one is adding a "something you have" factor to the "something you know" factor.

If you have servers in a controlled surveilled environment, you might be less worried about someone carrying a whole machine away, and you might be more concerned with someone just pulling a disk out and intentionally or unintentionally leaking the data. If someone can infiltrate your DC and take out a 4u server, then you have bigger problems to worry about.

q2dg 2 years ago | |

Ah, I see the point: the use case is not the robbery of a computer but the robbery of an encrypted disk alone. If it's extracted from its hardware key escrow environment (a TPM, for instance) then won't be able to boot. Aha! Thanks a lot!!

cobbaut 2 years ago |

If it boots, then you (or the thief) needs to provide credentials. When not booted, the disk is encrypted so the thief cannot overwrite the /etc/shadow file.

q2dg 2 years ago | |

Yes, that's was the reason of my question: there are several mechanisms to not need to provide credentials anyway (interactively). But @yokaze has pointed to a situation where this has sense. Thanks!