On Thu, 22 Feb 2001, Ray Dillinger wrote:
If your application can read and write an encrypted drive without specifically providing the keys, then a trojan on your system can read and write an encrypted drive without specifically providing the keys.
I think it is not sensible to include trojans in the threat model, here. After all, it does not matter how deliciously secure your application seems to be if you assume there can be a keyboard sniffer there, somewhere.
These workarounds can only work by "hiding" key management from the application, and thus from the user - which means key management gets done badly if at all. Good crypto can't be tacked on - it has to be designed in.
Why is this? To me it seems that key management at the system level is far more likely to be securely implemented than the personal blend of a given app coder.
Another problem with an encrypted drive is that an encrypted drive is infrastructure that someone is likely to not have in place when they first discover a real need to encrypt.
The same does go for encrypt capable applications as well, only there's considerably more hassle in trying to setup many of those in a row than in simply relying on an encrypted backing store.
Applications that write to (and more importantly, which read from) the encrypted drive should themselves be crypto-aware and do proper key management.
Could you elaborate a bit on why system level key management isn't enough?
I'm afraid I might be missing something here...
Sampo Syreeni