HN 표시: mTLS를 통한 원격 LUKS 디스크 암호 해독

sequenceDiagram participant Server participant Client Note over Client,Server: TRUSTED INTERNAL NETWORK Note over Server: Generate TLS CA Note over Client: Generate ephemeralTLS KEY and CERT with internaland external IPsin subjectAltName Note over Client: Generate Na and Nb,enroll Na XOR Nbon LUKS key slot Client->>Server: Register(hash(CERT), Na) Note over Server: Store sourceIP,hash(CERT)and Na with TTL Server-->>Client: CA create participant Boot@{ "type" : "database" } as Boot Partition Client->>Boot: Nb, CERT, KEY, CA Note over Client: REBOOT Note over Client,Server: PUBLIC NETWORK destroy Boot Boot-->>Client: Nb, CERT, KEY, CA Client->>Server: Unlock() over mTLS(require client cert without verifying) Note over Server: If within TTL and noprevious hit, compare certagainst hash(CERT), andstored and new sourceIPsagainst subjectAltName Server-->>Client: Na Note over Client: Unlock disk withNa XOR Nb - Internal network is trusted, e.g. VPN mesh, nodes are not. - A compromised network unlock server won't collude with an external attacker. - Attacker has full access to the public network. - Attacker has eventual access to the disk and can recover any deleted file. Any full disk encryption unlocking scheme of a remote machine without a TPM, e.g. SSH-ing into a dropbear initramfs, is vulnerable to the same attacker: someone who can read your unencrypted /boot partition and sit on your network. Against dropbear, they extract the SSH host key from the initramfs, impersonate your server, and capture the passphrase you type. This protocol doesn't strive to be stronger than that, it accepts the same threat model. An attacker with disk access + network access within the TTL window can steal the ephemeral TLS cert + key from /boot, connect to the server, and retrieve Na. The protocol just removes the human from the loop while being no worse than typing a password over SSH.