Encryption Could Make You More Vulnerable 126
narramissic writes "It sounds like a headline straight out of The Onion, but security researchers from IBM Internet Security Systems, Juniper, nCipher and elsewhere are warning that the use of data encryption could make organizations vulnerable to
new risks and threats. There is potential for 'A new class of DoS attack,' says Richard Moulds, nCipher's product strategy EVP. 'If you can go in and revoke a key and then demand a ransom, it's a fantastic way of attacking a business.'"
To sum up: (Score:5, Informative)
The threats discussed are:
revoke isn't that big (Score:4, Informative)
A revoked key can usually still be used without limitations, however a revoked key should not be trusted and should be considered exposed.
Re:revoke isn't that big (Score:5, Informative)
This is hardly a new issue, its been a significant concern for at least a decade. One of the problems with dealling with it was that for many years the mere mention of Key Escrow had people screaming about black helicopters.
Key escrow is neither necessary nor desirable for communications security. You use session keys, preferably with a round of Diffie Hellman to provide perfect forward secrecy and protect against kelptographic attacks. But for storage encryption it is all a matter of how you keep the keys safe.
It isn't that difficult to do, you simply make sure that keys are backed up in multiple places and are governed by separation of duties and multi-party control. The VeriSign Certification Practices Statement provides a complete primer in how to do this properly.
I don't see the problem. (Score:3, Informative)
Secondly, there are all sorts of potential problems with encryption: how vulnerable is the PRNG used to generate the key or key pair? Can an attacker exhaust CPU resources by forcing many expensive operations? Are people protecting their private keyrings correctly? Are command-line encryption programs exposing the encryption key on the command line? Since a virtual machine manager or hypervisor can see into a virtualized machine and therefore see the internal mechanics of encryption, are VMMs at the point where they can be used in a secure environment?
I'd consider any of these to be much more serious than a corp-to-corp key management problem which, ultimately, reduces to policy decisions on how to manage keys.
ADK (Score:3, Informative)
Also, someone correct me if I'm wrong but I think revoking a key only affects future uses of the key for creating valid digital signatures. You can still decrypt data without a problem. Someone coming in and revoking keys on you is only a DoS attack in the sense that you need to take the time to issue new keys and fix whatever security breach allowed the attacker access to the old keys.
Re:Encrypting Data, not communications (Score:4, Informative)
1. Set an administrative passphrase/key.
2. Make volume header backup. (Must be stored/protected as you would a safe combination.)
3. Have end user set personal passphrase. (Creates a new volume header)
If the user passphrase is lost or stolen the volume can be recovered by restoring the "admin" volume header. No ransom payment to bad guys required. (Applying clue stick to user is optional.)
This does add the potential risk of someone stealing the "admin" header backups. Storing the headers in a locked container in the company safe or an off-site bank vault will bring this risk down to reasonable levels. (Storing them on a CD on someone's desk will not!)