Security against local attack for remote FDE decryption?



  • Is there any remote FDE decryption that is resistant to an attacker that has local physical access?

    Tools like dracut-sshd need to store the private key used for the sshd server on the unencrypted boot partition, so a local attacker has the ability to become a MITM and sniff the decryption password.

    Can using a TPM to protect the sshd key foil this attack?

    Does clevis-tang have essentially the same problem? At the bottom of the tang README.md is this list of security considerations:

    1. Man-in-the-Middle
    2. Compromise the client to gain access to cJWK
    3. Compromise the server to gain access to sJWK's private key

    Problem (1) is not a concern according to this document. I assume you avoid problem (3) by running the tang server on a FDE itself or storing the key on a HSM. Problem (2) sounds impossible to protect against if the attacker is local - is that correct?

    The tang documentation stresses that the...

    client protect cJWK from prying eyes. This may include device permissions, filesystem permissions, security frameworks (such as SELinux) or even the use of hardware encryption such as a TPM

    Is the TPM option the only way to foil an attacker with physical access to the unencrypted boot partition?

    Is there any work-around that allows remote unattended FDE decryption that a local attacker cannot compromise?



  • According to this helpful blog about using TPM to auto-decrypt FDE disks, a local attacker can replace initramfs (because it resides on the unencrypted boot partition) and decrypt the disk even though the key is in TPM. I think this means all methods (dracut-sshd, clevis/tang, etc) suffer the same weakness.

    (Anyone care to point out which method they consider lowest risk?)

    The article claims there is no fool-proof way to accomplish what is being asked by this question -- yet. It lays out a couple ideas that people are working on for future iterations of the technology.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2