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.
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.
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.
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...
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
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.
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
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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?
_________________________
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.
A hacker IS a computer criminal. Why? Because that's what most people mean when they say it. Words mean whatever people understand them to mean. There is no Official Definitive Dictionary of the English Language somewhere which inscribes in stone the true definition of a word.
Language eveolves and changes. Just as the geek culture took words from "standard" English and changed their meaning, the non-geeks took one of our words and changed it's meaning. We don't own the langauge any more than they do; their definition of the word is no more incorrect than ours.
Yeah, I know. Off-topic. -1
"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.
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.
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.