Encryption Could Make You More Vulnerable

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.'"

Comments

To sum up:

[Actually, I do RTFA]

The threats discussed are:

1. Losing keys/passwords
2. Missing business opportunities because of the difficulty of sharing data internally (or presumably with third-parties
3. Hackers stealing your keys, deleting them, and ransoming them back to you
4. Hackers performing DOS on your authentication key-serving server./li

revoke isn't that big

[X0563511]

Revoking a key isn't going to harm a company. They can just issue a new key.

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

[Zeinfeld]

Its storage encryption keys they are talking about and nCipher makes a key management product.

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.

[jd]

First, if the revocation process is insecure and unauthenticated, then don't blame the encryption. Security is holistic and is no better than the weakest link. This isn't unique to encryption. In fact, because revocation is merely altering a user's perception of trust, it can be regarded as nothing more than a social engineering attack. Those are old-hat.

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

[Aram Fingal]

This is part of the reason for the Additional Decryption Key (ADK) functionality of PGP. Individual users within the organization can encrypt and decrypt with their own keys but there is always the additional key for backup, in the possession of the organization, to decrypt data in case users' keys are lost. I don't see how someone stealing keys is likely to cause much of a DoS situation when an organization is using ADK.

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

[rampant poodle]

TrueCrypt can protect you in both of these scenarios. After setting up the encrypted volume:

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!)