3 ms·
You can turn the secure boot on/off at any time. The only effect from this is the loss of encryption keys that you might have bound to the measured values. So
by cyberax 1y ago
You can turn the secure boot on/off at any time. The only effect from this is the loss of encryption keys that you might have bound to the measured values.
So for it to be effective against the evil maid, you really need to bind the LUKS key to it. But you can do that _and_ set a strong PIN for your LUKS key.
- Terr_ 1y agoThanks, here's my current model: 1. Your data on the drive/partition is encrypted by $BIGKEY, which basically never changes because that would require redoing everything. 2. The LUKS header stores one-or-more encrypted versions of $BIGKEY, generally encrypted using a more convenient $SMALLKEY that a human could memorize. Optionally, $PIN can also be part of the encryption step. 3. Unlike $BIGKEY, the $SMALLKEY and/or $PIN can be changed over time. This changes the ciphertext of $BIGKEY and rewrites the LUKS header. 4. Optionally, secure boot is capable of storing and retrieving $SMALLKEY into system chips in such a way that most tampering ought to destroy $SMALLKEY. > So for [Secure Boot] to be effective against the evil maid, you really need to bind the LUKS key to it. If my $SMALLKEY is not stored inside the secure-boot chips, I can see how that would be inconvenient, but I'm not sure how that is safer. Is it because the route $SMALLKEY automatically travels bypasses tricks like a hardware keylogger?