Slashdot Mirror
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.'"
I'd call it 'differently vulnerable' rather than 'more vulnerable'--all things come with inherent risks, and the risks of any particular action must be weighed against the rewards thereof.
Encryption is necessary for many businesses, and if such attacks are truly a worry, they should be addressed in the same manner as any other risk.
In Xanadu did Kubla Khan
A stately pleasure dome decree
The threats discussed are:
Your ad here. Ask me how!
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.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
This sounds more like a problem in the encryption SYSTEM. Its kind of like saying "Encryption makes you weaker because your more likely to use passwords. Which can be brute forced!"
So basically, -1 troll/offtopic is really slashdots way of saying "I hate that you thought of something before me."
5) Buy our stuff!
Really, I've never seen a setup where stealing ONE (or a few) keys could result in a situation where a whole enterprise gets shut down for ransom.
More likely, consider the situation where only two guys have the password to the domain name registrar's account, they get laid off, and a year later some one realizes the company domain expires in two days. Before anyone figures out how to renew it, it's in the hands of a pr0n site. There's your missing/lost key scenario, happens all the time.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
Traditionally, you store the data in one place and the key in another. You may even encrypt the key with a smaller key, called a password, that is stored in someone's head.
If someone tricks the key-checking mechanism into thinking a key is revoked, that's not a huge problem: All a revoked key means is that you may not be able to TRUST the key or the data it protects anymore. It doesn't mean you can't get at the data.
This is no worse than if a burglar broke into the building storing your paper forms. You can no longer automatically trust that those forms weren't tampered with. You have to either re-authenticate each of them or accept the fact that they may have been altered.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
A friend taught me this years ago:
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Maybe I'm just being silly or showing my old-school mentality, but I think it's important to try to identify these types of potential "gotchas" before I click setup.exe.
If your attacker can get a hold of your key and alter it, your system is already compromised... thus it is incorrect to claim that encryption can lead to MORE vulnerability because without it you are as good as dead.
Encryption is making things harder for those that want to penetrate your business, but use it with care. Too much will do more harm than benefit. Set up boundaries in your systems and encrypt the communication. That's the reasonable way to do things.
Encryption of hard disks may be useful on laptops, but is relatively useless on stationary computers and servers, and will probably only add to the performance overhead. Just be sure that all hard disks are erased before the computers are retired and you have been saving yourself a lot of trouble.
If someone stores data encrypted anyway and the key is lost - well - tough luck unless you have a good policy where backup keys are stored in a safe place.
Only a few businesses will benefit from extreme levels of encryption, and those are mostly working in the military area. In these cases it may be better to just call it a day and consider all data where the key is missing or manhandled as compromised.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
The problem comes in when people can't remember the encryption password. Either they lock themselves out of the laptop or they do something brilliant like write the password on a post-it and tape it to the laptop case.
No matter what strategy you have, your own customers will find a way to mess it up.
psmylie's dictionary: Godzillion (noun) Any number large enough to destroy Tokyo
This is like saying that using locks on your car can leave you vulnerable. Sure, they keep casual thieves out and the newer systems keep go a long way towards preventing someone from hotwiring your car.
BUT, a mischevious person could put epoxy in all the keyholes, essentially revoking your keys and causing a denial-of-service.
Which is better, a small risk of being locked out of your data/car, or the larger risk of theft and/or misuse of your data/car due to lack of security?
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Whenever I leave my apartment, I'm always worried about losing my house keys and getting locked out. So I guess I should just never lock the door, since that makes me vulnerable to a DoS (can't get in) if I misplace my keys? Of course, this is a bad analogy as door locks aren't very secure; anyway this definition of 'vulnerability' is a bit strange :) :D
Considering this warning comes from a bunch of security companies, maybe this is some new trend of disclaimers, like anti-virus vendors warning that their product can only reduce but not eliminate attacks - in case a customer is stupid and tries to blame the encryption vendor for losing their keys, they can say 'I told you so' and point to these articles
The use of door locks and deadbolts could make organizations vulnerable to new risks and threats, a panel of security experts warned Monday.
Many organizations are locking their doors to relieve concerns over material theft or loss - for example, U.S. break and enter statutes do not apply to unlocked doors.
However, experts from IBM Internet Security Systems, Juniper, nCipher and elsewhere said that locking doors also brings new risks, in particular via attacks - deliberate or accidental - on the key management infrastructure.
The change comes particularly with the shift from leaving doors open, as was common in the 1800's, to locking doors and securing buildings with perimeter fences - often in response to regulatory demands - said Richard Moulds, nCipher's product strategy EVP.
"Lot of organizations are new to door locks," he added. "Their only exposure to it has been with padlocks on remote sites, but that's something very few staff have to deal with, and infrequently. When you shift to locking your entire building, right down to the individual executive offices, if you lose the key you trash your access - it's a self-inflicted denial-of-service attack.
"Organizations experienced with door locks are standing back and saying this is potentially a nightmare. It is potentially bringing your business to a grinding halt."
Locking doors is also as big an interest for the bad guys as the good guys, warned Anton Grashion, European security strategist for Juniper. "As soon as you let the cat out of the bag, they'll be using it too," he said. "For example, it looks like a great opportunity to start attacking key infrastructures, as a little bit of epoxy in the keyhole, and whammo, your building is inaccessible."
"It's a new class of DoS attack," agreed Moulds. "If you can go in and damage a lock and then demand a 'protection money' so that it doesn't happen again, it's a fantastic way of attacking a business."
Another risk is that over-zealous use of door locking will damage an organization's ability to legitimately share and use critical business facilities, noted Joshua Corman, principal security strategist for IBM ISS.
"One fear I have is that we're all going to hide and lock up all of our assets such as pens, paper and coffee makers, but companies are asset-driven, so we take tactical decision and stifle ability to collaborate," he said.
"Sometimes, the result of implementing security technology is actually a net increase in risk," added Richard Reiner, chief security and technology officer at Telus Security Solutions.
Slashdot - the place where you can look like a genius by restating the obvious
That seemed a little strident considering the topic. My apologies for shouting.
I'm not sure what point they're trying to make in the article other than churn up some FUD. If I encrypt a file on my computer with a password or key and then lose my key, I cannot easily decrypt that file. So poor management of my key could make me vulnerable to loss of data -- but that's not the same level of risk as theft of data (which may be worse than losing it.)
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.
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.
I don't understand how Hugh, er... "3 of 5" can assist with this, but resistance is futile.
Confucius say: "Man who associates with smarter men than himself is smarter than the men he associates with."
+1 Cromulent!
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!)
I agree, but I would go so far as to say you are less vulnerable with encryption.
The highest level of attack that the article mentions is DOS by which attackers steal your keys and ransom them back to you. Indeed, this would be a bad day for the IT department and the affected departments of the company could lose days or even a week of productivity, which is damaging indeed.
Compare this to the risks of not running encryption. A similarly motivated and skilled attacker as discussed above could easily grab things like log ins just by monitoring your traffic. Once he finds that login with the proper credentials, not only can he execute a DOS as outlined above, but he can also potentially steal all of your client information, your internal financial information and implant rootkits on all your servers so as to be able to come back for more later. One of the best ways to lose your entire customer base is to tell them that they have to cancel their credit cards because you got their numbers stolen.
This kind of stuff has killed companies. No thanks, I'll keep my ssh and ssl.
weirdest thing I ever saw: scientology advertising on slashdot.
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.
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
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.
If you or your friend had played enough Oblivion you'd recognize the inherent weakness in this idea: one of the three can frame the other two as a vampire, claim to be a vampire hunter, safely dispatch them in the open and then possess all 3 keys.
http://www.uesp.net/wiki/Oblivion:A_Brotherhood_Betrayed