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.'"
It's not so much 'more vulnerable' (Score:5, Insightful)
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.
Re:It's not so much 'more vulnerable' (Score:5, Insightful)
We all know headlines exist solely to generate traffic...
Re: (Score:2)
And Slashdot isn't helping any by front-paging people from these magazine sites to submit their own content, complete with misleading headlines and writeups.
Re: (Score:3, Funny)
Just a q.
--mike
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:3, Insightful)
And as to encrypted email, you can always send it again.
Making people fear encryption because of this verges on sociopathic. BTW, BACK UPI YOUR DATA DAMMIT
-mcgrew (not the security guy)
Re: (Score:2)
The point is the keys should be backed up too. Naturally you should have proper procedures to control the use of keys that are revoked.
If the keys and data are backed up, I don't see a rogue revoke/delete causing a huge unrecoverable problem.
There are bigger problems to worry about.
Re: (Score:2)
Obligatory analogy: Someone stole your car keys, and he happens to be in cahoots with all the locksmiths in town. He didn't steal your car, but if you want to drive it, you had better pony up.
It's a plausible scenario but unlikely; you can probably make as much or more money with less risk by simply stealing proprietary data and selling it.
Re: (Score:2)
Revocation is putting the key/cert on a "List of keys/certs that are no longer valid". The use of public revocation lists is usually optional in sane products (even in IE it's a configurable option), in a nonfascist country.
Say someone somehow revokes your pgp keys. Maybe OTHER people might no longer trust your keys when they see the revocation, but you can still decrypt your data. Even if the keys are corrupted or deleted, as long as you hav
Re: (Score:2)
I'll bow to superior expertise gracefully.
Re: (Score:3, Insightful)
I agree, but... (Score:3, Insightful)
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
Value of data (Score:2)
Re: (Score:2)
To sum up: (Score:5, Informative)
The threats discussed are:
Re:To sum up: (Score:5, Funny)
Mission option for every security discussion (Score:5, Insightful)
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.
Re:Mission option for every security discussion (Score:5, Funny)
Still trying to explain that web site you "accidentally" visited, eh?
[badum-ching]
Re: (Score:2)
Honest,
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Hmmm....I think you need to do more. Why not give the hard drive to a sexually confused, pr0n addicted teen for a few weeks first. Not only will the repeated writing of shemale goat pr0n videos wipe the hard drive well, no worker could be paid enough to find out what is "u
Re: (Score:1)
In which case, if encryption makes you more vulnerable to hackers, then surely no encryption makes you safer. By the same reasoning we should get rid of every kind of security. Why lock doors since you may lose the key? What if someone else gets your keys, breaks in and changes your locks? So we should all stop locking things away since that actually makes them less safe.
No passwords to forget/steal/target != safe.
Re: (Score:2)
And yes, I never lock my house or my car, and I have yet to have one thing stolen from me in all these years.
Remember, people who really want to get at your stuff will do so no matter how smart you think your security is. Locks are just for keeping honest people away.
Wrong (Score:2)
Re: (Score:1)
If you got nothing to hide, you got nothing to fear.
And if you have got something to hide (as the targets of this article do), lock it up!!
You would feel safe knowing that the bank you keep all your money at just left it's vault unlocked? Or the government databases that hold all of your personal information were freely available to all?
Just because somebody wants to commit crime doesn't mean you should put absolutely no obstacles in their way and make it easier for them.
Re: (Score:1)
Re: (Score:3, Funny)
Re: (Score:2)
This was specifically about Johannesburg
Re: (Score:1)
Really? What's your address?
Re: (Score:2)
No kidding. I've had my car broken into 3 times now. Every single time they just smashed the window to get in. Funny thing is that I am pretty sure that one of those times I had left the door unlocked. If hadn't lost my car stereo and had to pay for a new window, it might be funny. F'ing meth addicts....
-matthew
Re: (Score:2, Insightful)
There are hundreds and thousands of case's where security has stopped crimminals in their tracks. Most people cant get past a $30 lock.
~Dan
Re: (Score:1)
- Welcome to computers.
2. Missing business opportunities because of the difficulty of sharing data internally (or presumably with third-parties.
- Welcome to businesses where people have to use computers.
3. Hackers stealing your keys, deleting them, and ransoming them back to you
- Or they could just grab chunks of the data like always, and sell it to the highest bidder, without you ever knowing. Ransom is dumb, because it gets the authorities on your tail and
Re: (Score:1)
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: (Score:3, Insightful)
Re: (Score:2)
Still, if you're worried, the simple solution is to buy a security product from one of the commercial sponsors of this report. Then, when you lose your key, you will be able to pay a hacker some money to recover your data using the back-door that the NSA forced them to incorporate into their pr
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.
mod parent up! (Score:3, Insightful)
Re: (Score:1)
I believe the revocation threat is against keys used to interact with other organisations, if you gain access to the revocation certs for public keys used to perform eg inter-bank transactions, once those revocation certificates are issued to whichever authority is controlling the key infrastructure (normally only done in the case of a compromised key) then the required level of trust is no longer present, leading to failed transactions whilst we race around trying to inform everyone the revocation is false
Re: (Score:2)
But how exactly would an attacker revoke a key in the first place? CRLs are supposed to be signed by the CA who issued the certificates in the first place. Are they suggesting that it's somehow easy to hack a certificate authority to revoke these keys? We're talking about a worse-than-usele
Re: (Score:1)
Re: (Score:2)
But I am unaware of any mechanism to produce a "revocation certificate" or how or why you would issue one in advance of a certificate being revoked. Without the signature of
Hmm (Score:5, Insightful)
Re: (Score:1)
It's sort of backward logic to say it's bad because CAN be forced.
Revoked keys do not (normally) your data hold hostage.
Though in my experiance, the password cracking is more of a problem.
Users really do need education on stronger passwords that are still usable, which they will promptly forget or write on the bottom of their keyboards therefore pulling the PS
Re:Hmm (Score:5, Insightful)
Its like Mom always said; never write something down without expecting someone else to eventually read it. If its dangerous or hurtful information it should be destroyed. If its really important keep it in the only place its really safe your head.
Business are keeping more and more customer information. Information is leaked all the time stored encrypted or not. Encryption is likely to give an often false impression of security. People may think they are safely storing facts that will only be available to them and their organization and customers might end up really unhappy if they discover they were wrong about that some time.
Re: (Score:1)
Re: (Score:2)
Beats the alternative (Score:2)
that sounds a bit better than going in and just taking whatever is valuable wholesale with nothing to stop you such as... encryption?
Re: (Score:2)
Re: (Score:2)
Just another story of... (Score:2)
Revoking a key may be a red herring (Score:3, Insightful)
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.
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: (Score:2)
You can do much, much better than that: your system is not resilient to having one of the 3 parties providing wrong information intentionally, for example.
Distributed secret algorithms is a very well studied area of cryptography.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2, Funny)
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_B [uesp.net]
revoke isn't that new (Score:2)
False certificate revocation is an obvious point of attack on certificate infrastructure, and has been ever since CRLs were proposed. Loss of encryption key is a new risk? Yes, to researchers who have been asleep since, oh, 1466 when Leon Battista Alberti developed key crypto.
It's not that we shouldn't pay attention to these risks and incorporate them into our security metrics. Of course we should. But it's not news.
So the point is? (Score:2, Insightful)
Game over ... (Score:3, Insightful)
There is always a risk (Score:3, Insightful)
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.
Users are always the weakest link (Score:5, Insightful)
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.
Re: (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 af
Re: (Score:2)
However, anyone should know that you don't tape your password to the device that it goes to. That's like locking your front door and leaving the key in the lock so you don't have to bother looking for it when you get home.
We do tell people not to do that, when we set them up with a laptop and encryption. I also tell them to have the password in
Re: (Score:2)
Voicemail is a bad idea, because voicemail is notoriously easy to crack.
Re: (Score:2)
Re: (Score:3, Insightful)
People not remembering their encryption password is by far the lesser of two evils, though. I'd rather have the data be totally inaccessible than be accessed by the wrong people.
Not new or groundbreaking (Score:4, Insightful)
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?
Re: (Score:2)
Which means that sometimes it makes a lot of sense not to encrypt. People lose and forget passwords all the time. Even if you have a system for managing the keys, it can still be screwed up accidentally or deliberately. Much of the time, keeping the data intact is more important than keeping it secure. Co
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.
By encrypting streams (Score:2)
Re: (Score:2)
Of course, the usual analogy: You have a bunch of file cabinets. You could buy one heavy duty, fireproof vault with a X-08 lock on it to store the contents of the one cabinet th
Keeping doors unlocked is better? (Score:3, Insightful)
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
Duh..... (Score:1)
Now, I am more vulnerable to being locked out if my wife leaves the house and I forgot my keys, or if the lock breaks. So just because the slogan, "American express, I can't get into my home without it" is no longer true, should I not use it?
Security is an art. No one way is right, nor perfect. It is all acceptable risk. Personally, I have a feeling all IDS systems will migrate to host based systems because the majority of the traffic will be
Let's extend this to other common security devices (Score:5, Funny)
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.
FUD, a way of life for the "journalists" (Score:1)
They are CINNAMON BUNS, DAMMIT! (Score:2, Funny)
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.
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.
Encrypting Data, not communications (Score:1)
What the article is talking about has nothing to do with web servers or the internet, it has to do with confidential data stored on private/internal file servers and database servers. It also has to do with data that "walks" out of the corporation on laptops and PDAs.
When you encrypt this data with a key and you lose the key, you LOSE the data... period. You NEED the key to recover the data... THAT is the risk they are talking about. Now extend that risk from losing the key, to someone stealing it and
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!)
Re: (Score:2)
Cryptovirology (Score:1)
Don't Install Sprinklers In Your Building! (Score:2)
Not new (Score:2)
Gpcode-AI [viruslist.com] is one example.
Backups (Score:1)
_Offspring_ could make you more vunlurable. (Score:1)
stretching, stretching, stretching... (Score:2)
What???
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.
What I do... (Score:1)
Including this message.
If it's not Consolidated Lint it's just fuzz!
Re: (Score:1)
Are you making an offer, one that he might take you up one?
Re: (Score:2)
This Just In! (Score:2)
Re: (Score:2)
'Hey Billybob, watch this!'"
Re: (Score:2)