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.'"
Other way to protect data: Split the data (Score:5, Interesting)
Say you have a secret. Divide the secret into 3 parts and find 3 people to hold the key. Each person holds 2 parts of the key. If any one person is unavailable, the key can still be used, but no one person can use the key alone.
This same system can work with larger numbers too. My friend used a "3 of 5" approach, which required 3 people out of 5 to use the key.
In a way, this is like RAID-5 but more general.
You can apply this to keys, to the raw unencrypted data, or to encrypted data, depending on your security needs.
Re:Users are always the weakest link (Score:3, Interesting)
Then it is your job to either educate those users or to architect the system in such a way that those weaknesses are designed out of the system. The problem is not in the users, it is in the security guidelines you are issuing and your expectations of adherence to those guidelines.
Often, to respond to requirements like those you mention, we use things like: 1qAz@wSx
followed by 3eDc$rFv ... when the first one expires after 90 days (and what is the specific and measurable basis in computer security for why the password is forced to expire, especially so rapidly???)
As one can't use the last 4 passwords, you'll find these conveniently rotate...
The problem here is that the folks in charge of security either don't understand or don't care that the "bestest, most strongest, most frequently changed" password system isn't the one with the most complicated and longest password requirements. Security is rooted in passwords that are the hardest to guess OR access. If you are forcing rotation too frequently, or forcing really complicated rules (no dictionary words, must include symbols, etc.), then you will find users will simply resort to patterns or post-it notes, and your security has been defeated. Personally, the password requirements to my e-mail system at work are now so complicated that I have run through dozens of combinations to have them all fail. The ONLY solutions I have found that work are patterns on the keyboard (which IMHO, are less secure than many of the other passwords I tried to use)
I will repeat: This is NOT a user problem, it is an administrative rules and security architecture problem. If you really require security beyond passwords people can remember and type easily (and are willing to do), then you need a security system that goes beyond passwords - e.g. go buy a ThinkPad with an integrated Fingerprint reader.
Key Management should be part of PKI (Score:1, Interesting)
Just like a lock on a door, if properly implemented, in PKI keys can be replaced. Every organization that is serious about implementing a PKI should be just as serious about about key management as it is a massively important component.
http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf [nist.gov]
"Revoked" key doesn't equal "Destroyed" key (Score:5, Interesting)
As several others have pointed out, a 'revoked' key in no way keeps you from getting at your data. In the same way that a bank can 'revoke' a credit card, the actual card itself doesn't disappear... it's just not trusted to do anything. Unlike the credit card system, most any security software that checks key revocation lists can easily be told to ignore the fact that the key is revoked. The bits needed to perform the encryption or decryption still exist -- you just get a warning that someone says you should not trust it... but that's not the same thing as saying you can not trust it.
What that really means is you just need a good key management scheme. Whereas most people would just use a single private key, in a corporate environment you've got the problem of project-related work that might be encrypted by an employee still belongs to the company. If an employee quits, is terminated, gets run over by the beer truck, etc. etc. then the company would like to have a way to get the data that they rightfully own. This is what "key escrow" systems are for. But escrowed keys would ideally be kept in a very safe place. Of course the fact that an escrowed key exists at all allows the individual to repudiate the contents of the encrypted file -- someone else could have altered it. The solution to that conundrum is to create a "signing" key which does not encrypt and which is not escrowed, and an encryption key which is not used for signing, but which is escrowed.
So back to the FUD... I suppose all these companies have an interest in creating the fear, getting the average IT person to decide to look into it, realize what they're missing, then realize that they probably need to hire a professional security business to help build a proper key distribution and escrow system.
Huh? (Score:3, Interesting)
TFA is so much bafflegab, there's no place to get a hold of it.
Revoking a certificate would result in some inconvenience, but it couldn't provide the means to hold anything for ransom.
In a corporate environment, an encrypted file on a laptop is almost certainly duplicated somewhere—usually in clear on a server. And if I just created or modified a file and haven't yet backed it up, I had to use the password to do it, so I'm unlikely to forget it over lunch.
Add to that the fact that all the mainstream encryption products come with key management systems to help avoid even that small risk, TFA suggests that either the "experts" aren't really experts or the reporter didn't understand them.