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?
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?