4 ms·
Ah, but you essentially have the 'evil maid' problem Schnier described. So I somehow gain physical access (or otherwise gain root) I then shut the server you
by lsc 15y ago
Ah, but you essentially have the 'evil maid' problem Schnier described. So I somehow gain physical access (or otherwise gain root) I then shut the server you are on down and replace the program that accepts your encryption key with my own program that saves the key for my own use. You'd see a reboot, you'd login and input your key, and I could run off with your data.
There are several other ways to do this; but really, countering the 'evil maid' attack is quite difficult.
- Joakal 15y agoHence my second suggestion, a separate server akin to what AWS's post offered. Essentially the encryption server will get encrypted data, de-crypt it and then sends it back to production server (vice versa). It's not public facing, etc. Which means the attacker has to try to compromise the second server that's more locked down. Or are you saying evil maid attacks can breach the VM they're on?
- lsc 15y agoPretty sure there is no VM involved... there'd be no reason to virtualize your storage nodes. But yeah, you are right that if you kept the keys and did the encryption on the second server, you'd have to do the attack on the second server; but that's really just moving the problem around.