Slashdot Mirror
Making PKI Work
Vegigami writes: "The U.S. General Accounting Office (GAO) has released this 80+ page PDF report on Information Security: Advances and Remaining Challenges to Adoption of Public Key Infrastructure Technology. Some good straight talk about what its going to take to get PKI to really work on a large scale. The obstacles seem formidable."
I find it heartening to see, on page 80, that the PDF is printed on recycled paper...
--
I don't suppose anyone will be able to get to a vast PDF (once /.ed), never mind read it, so here's a précis:
The government wants to use public key for internal use, but because PKI is an immature standard, they are as yet unable to do so, faced with lack of compatibility and standards.
Furthermore, they find that there is no proven and robust system for highest-level security, and will have to wait for one to emerge.
They also believe costs will be high, as more user validation systems are developed, associated with the cost of issuing certificates and creating keys.
There is also a need to create a policy framework - a large executive agency will 'require a substantial effort' with user privacy and general policy issues.
Finally, there is the issue of training. To implement this, a trained staff is needed. Since PKI is complex, this has important cost implications.
--
Hi!
Can be found here.
PKI is one of those really hot topics that we're all going to have to come to terms with if we really believe things like Open Source, distributed processing, trust networks and P2P. In order to be in a position to trust other people, we're going to have to be pretty sure that we know who they are, and without PKI, this gets difficult when you go really large-scale.
Consider - it's all very well deciding that I trust ESR to play with my code, or run cycles on my machine, because he's so well known, and his identity so well verifiable, that I can be pretty sure it's him doing it. But if I'm running a big distributed system, and you don't know me - how are you going to be sure it's me that's putting code on your machine? With PKI. In fact, I probably wouldn't trust an entity claiming to be ESR without third-party certification such as can be provided via PKI.
For P2P, you want to be sure who you're talking to (remember the story earlier this week about Windows shares? Well, maybe some people _want_ to allow some other people access, but need to be really sure who's there). For distributed processing, you want to make sure it _is_ SETI, and not a criminal key-cracking syndicate. For Open Source, you might want to run a trust network to decide who gets to release code.
PKI is important because trust is important, and because encryption is _hard_ to do in a scaleable, trusting way without it. Time to get learning about this, everyone.
code and corresponding output file (the log shows all bits > 16 w/ 100% accuracy cause i was using 16 bit numbers) if anyone on slash can carry this to greater accuracy I'd be quite interested. the algorithm is pretty simple, chop off all the leading bits on N where there are leading 0's in K, bitwise xor that result with K, and turn on the 1 bit cause we know its going to be odd. I experimented with 16 bit prime integers, it tends to produce about 11 100% accurate 16bit answers out of every 10,000. i found it interesting anyway...
"// this is the most hacked, evil, bastardized thing I've ever seen. kjb"
Err....
But there are no ways of mathematically demonstrating encryption to be secure.
Or rather, all such demonstrations must rely on assertions saying 'XYZ is a slow process'. Such assertions can never be proven.
There's no mathematical way of proving that new algorithms won't arise.
Jules
-- Any sufficiently advanced technology is indistinguishable from a perl script.
No currently developed public key encryption algorithm has been mathematically demonstrated to be secure.
You do know that only one private key encryption algorithm has been proven to be mathmatically secure, right? That algorithm is the "One Time Pad". That said, it is of limited use because of the problems of distributing the key, the fact that the key can only be used once, and the key is as large as the message to be encrypted. What the hell do you mean by "demonstrably secure" anyway?
Cryptographic algorthms, even private key ones, don't need to be mathmatically proven to be useful, or we basically wouldn't have cryptography. Algorithms should, however be subject to review by the best available cryptographers, and, 'we haven't managed to crack it yet' is really the best that can be done.
This is clearly unacceptable for any serious application. When highly confidential and sensitive data is transferred, it is critical that a demonstrably secure algorithm be used. All public key algorithms have failed this test, and thus do not deserve consideration in a serious computing environment.
The industry is aware of the shortcomings of cryptography, well, at least some of it is. The rest of it has no excuse anymore because the literature is out there. The industry also knows that in order to be useful, cryptography has to be usable, and so certain compromises have to be made. Public key cryptography is absolutely necessary in order for cryptography to be used on a wide scale.
While he and the GSA seem to be committed to implementing a national PKI, the fact is that this project was tied very much to then Vice-President Gore and his "e-gov" initiaves. If this project is continued by the Bush administration, I suspect it will be radically different in form, just because of that.
This may be moderated as flamebait, but Shoeboy is accurate. PKI does stand for phenylketonuria. Public Key Infrastructure is, well, somewhat silly anyway.
First, abolish the NSA. They're a leftover from the cold war, whose interests are detrimental to freedom.
-russ
Don't piss off The Angry Economist
Check the user info - everything qpt writes is a troll. Remember this before you reply or moderate.
--
Xenu loves you!
But some name recognition for what is admittedly successful (even if unofficial) PKI should have been given...
ObKarmaWhoring: if you haven't read this already then Bruce Schnier and Carl Ellison's "Ten Risks of PKI" is essential background reading: http://www.counterpane.com/pki-risks.html
--
Xenu loves you!
Honestly, when is the last time you received encrypted email resulting from a succesful key exchange with a user out there in webland?
I think half the reason you can't do encrypted e-mail (or encrypted anything else, for that matter) is that most "PKI"s are neither public, nor infrastructure.
Company A goes and spends a kagillion dollars on an Entrust solution and gets an overgrown LDAP server that only knows about its own keys. Who cares that Company B spent half a kagillion dollars on a Versign solution? Neither can communicate with the other, because they can't look up each other's public keys.
Everybody wants to push this stuff down to the end user, too. They want every Outlook, Netscape, etc, to have its own list of LDAP servers to query. LDAP is the kitchen sink of directories. It's totally overkill for the problem of "gimme a key!" Plus, why should every application writer have to maintain their own list of LDAP servers, write their own query mechanism, etc.
DNS has long had support for the essential key-distribution features. The resolver library ships on every single OS that can use the internet. The query structure and mechanism is known. The hierarchy rearranges itself flexibly. Delegation is easily achieved, both by InterNIC registration and KX records. If people would give up LDAP and move to something more flexible for key lookup, PKI's goal of being "public" and being "infrastructure" would be more attainable on a large scale.
Paco is an employee of Tovaris, Inc. who speaks his own mind and not theirs.
About 80% of the people in this field seem utterly clueless about security. And this is being charitable. Most developers I have talked to these days are astounding in their lack of knowledge about real security attacks. Some even whine about why things don't work when they try to loosen security. This is utterly mind-boggling!
Java doesn't cut it here. The simple reason why is due to the overhead in loading in all the security classes. There was an excellent and simple example of some JSSE code in Dr. Dobbs recently; try downloading and running the code with TSL turned on - you'll see what I mean.
Another sad reason is the lack of algorithm support in Java. Yes, it's a start; and yes, it has a LONG way to go to get up to speed with OpenSSL. I daresay it will take years to develop the same breadth and confidence as OpenSSL.
OpenSSL is the best thing out there, and it needs a serious rewrite. I don't wish to belittle the excellent work done by Eric, Ben, Ralph and many others. But let's be honest here. OpenSSL has evolved into a mishmash, and it's time to rewrite it. Of course, by the time that's done, then Java will probably have come up to speed. I doubt it will be as fast, but I'd like to be optimistic here.
The biggest security flaw in ebiz is conveniently overlooked. People seem to be litterly sticking their heads in the sand on this one. It was reported last summer on bugtraq , and yet, almost no one seems to be paying attention to it.
Many people are trying to implement security models using Java applets. This is a fatal mistake, and will leave you or your clients rather vulnerable.
The simple reason why is because if your browser gets hit with a rogue applet, you are screwed. Not only can a reverse-tunnel to a hostile site be set up, but under some circumstances, the applet can initiate a secure connection to (say) your bank, using your password from the cache!!!
You get NO warning that this has happened; and the bank thinks that it really was from you. Good luck disproving this one in court. And most firewalls won't protect you.
The potential for serious damage here has not been fully exploited, thank God. But it's only a matter of time. Especially when people highjack a sites' DNS server, and point it to a hostile look-alike. Ugh.
What's also scary is the number of sites using pure Java or Javascript. Javascript is even worse, and IMHO can't be fixed security-wise without a complete rewrite.
But the bottom-line is that Java and Javascript leave you vulnerable; and it's only a matter of time before this hits the fan. Sun has as big an exposure as MS (with IE and Outlook virii) - it's only a matter of time before this is exposed.
Just turn off Java. This might protect you (though I suspect that actually even this may not help).
But the products which are coming out using applets for security is of real concern. In fact, it might well seriously hinder the new move to application servers, depending on how things are done.
This is frighteningly fertile ground for exploits.
So, yes, the bottom line is that PKI has a VERY long way to go. This is surprising given that people have been working on it for eons. IMHO, the lack of progress here is the best example of how the U.S. export restrictions have hurt business.
And, if you really want to put this in perspective, take a look at InfoSec's recent study, they noted that only 2/3 of all ebiz transactions are done with encryption (and this is an *improvement*!?!).
In 90% of the applications (especially the kinds of applications that slashdotters are interested in), having a full-scale public key infrastructure and having every public key signed by a signing key would be more susceptible to attack than doing simple unauthenticated public key exchange between peers.
That's because the cost of mounting a man-in-the-middle attack on a specific public key (think of e.g. someone mounting a man-in-the-middle attack against your ssh pubkey when you ssh in to another box), greatly exceeds the payoff. There are cheaper ways to get access to your other box, starting with known exploits, followed by social engineering. Finally, physical access to your box is probably cheaper and safer for the attacker than a man-in-the-middle attack on an unauthenticated public key exchange.
Now look at the other option: what's the cost/payoff matrix for mounting an attack that steals some keys high up in the PKI hierarchy? The cost is whatever it takes to get the keys (history shows[1] that social engineering, being yourself an employee of the organization, or taking advantage of some thoughtless mistake on the part of an employee, seems like the best starting point) and the payoff is huge. You basically get carte blanche on the whole network which trust this particular PKI.
Now I am aware that there are other PKI topologies that are less hierarchical, but basically the most cost-effective solution that gives you the amount of security you need for the amount of effort that you can afford is simple straightforward unauthenticated public key exchange. The universal assumption that the only "truly secure" system is a full-scale PKI is a massive mistake perpetuated by idealistic mathematicians ignorant of the facts on the ground, and greedy PKI execs who dream of being able to extract a tax on every transaction, because they control the root keys.
There are several cheap and easy tricks you can add to unauthenticated PK exchange to make it even more expensive and dangerous for an attacker to interfere, which I would be happy to explain if anyone asks...
Regards,
Zooko
[1] "Why Cryptosystems Fail." Ross Anderson. http://www.cl.cam.ac.uk/users/rja14/wcf.html
Write up what you've done and publish. If you've advanced the art of factoring even a tiny bit, you'll be famous. Hell, put a more comprehensible description here and you might get famous.
--
Xenu loves you!