Making PKI Work 53
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."
Nice to see it's green (Score:5)
--
Ok, here's the brief (Score:2)
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.
--
Homepage of the PKI program (Score:2)
Re:Nice to see it's green (Score:1)
Growing importance (Score:2)
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.
on the formidableness of obstacles (Score:1)
I believe this is goverment-ese for "it ain't gonna happen till we're damn well ready, which very well maybe never, or at least until the revolution comes."
Public Keys and the end of anonymnity (Score:1)
There's simply no reason why, eventually, any traffic should be allowed that isn't 'signed' by a known entity. Once the infrastructure is in place, routing points can be configured to 'validate' and silently drop unsigned packets.
I look forward to that day. The death of spam, and the end of anonymous porn on the 'net.
Others may disagree about it being a good thing, but the right to privacy is a different critter entirely from any presumed 'right to anonymnity'. (you have a right to be private about your affairs, there's no inherent right to be anonymous in public).
I played aorund with cracking PKI (Score:2)
code and corresponding output file [muohio.edu] (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"
Re:Unproven Security (Score:2)
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
Uh-oh, Karma must be sinking fast! (Score:1)
--
Non-meta-modded "Overrated" mods are killing Slashdot
Re:Unproven Security (Score:2)
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.
Re:Unproven Security (Score:1)
Depends on exactly what you mean. It most certainly is possible to prove that some problems will take a certain minimum number of operations to solve in the worst case. For example, it is possible to prove that the general sorting problem for N keys requires at least NlogN operations in the worst case.
On the other hand, such proofs are often for general cases. It may be that there will be domain specific knowledge that can be brought to bear to build faster algorithms for specific cases. (For example, the sorting problem where the keys are known to be integers in a given finite range can be solved in near linear time.)
Also, it's possible that technological advances such as quantum computing might allow us to build machines where the individual 'operations' are of a higher class, thus reducing the time to solve these problems.
Re:on the formidableness of obstacles (Score:2)
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.
Re:Unproven Security (Score:1)
There are real difficulties in creating a way to store, validate, and exchange keys. There appear to be insurmountable ones, ironically, in convincing those who are into crypto that anything less that "safe enough to hide from god" is even worth doing. So as long as there is a one-in-a-trillion chance of cracking a key during its useful lifetime, you subvert any attempt to get *some* use out of cryptography. You posture like an advocate, but the views you present are more suitable to those of an opponent. You say we need better crypto, but you are advocating the use of plaintext.
Finally, you top it off by stating that the best that can be said is that it hasn't been cracked yet. Well, woop-de-do. Evolution is still a theory, and you can never "prove" anything to a closed mind.
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Re:All about PKI (Score:2)
First, abolish the NSA (Score:3)
-russ
Remember that qpt is a troll (Score:2)
--
PGP (Score:2)
But some name recognition for what is admittedly successful (even if unofficial) PKI should have been given...
Re:Unproven Security (Score:1)
In addition to the comments others have already may on the question whether an algorithm needs to be proven secure to be useable, I would like to remark that the security of a PKI does not lie with just one algorithm. As long as there is at least one asymetric algorithm that has not been cracked for a given key lenght, PKIs will work.
If you select PKI components you should allways look for support for multiple asymetric algorithms. Then you only need to change the keys. Something PKIs are MUCH better at then the mathematically secure one pad ciphers.
And let me asure you, the ciphers are not the biggest weakness in PKIs. As allways, People are. And I know what I am talking about. I work as a marketing drone for a CA.
Schneier and Ellison: Ten Risks of PKI (Score:3)
--
Re:PGP (Score:2)
While I still think that PGPs 'Web Of Trust' is a neat idea, I had the opportunity to see that I does not scale well nor is useable by DAUs(1) in the wild. Except when degenerated to a hirarchical modell as in a PKI, where PKIX standards work better
PGP only works well in a tightly nit network. If there are more then two to three steps from an identity that I have verified personally to the identity that I want to trust, the trust in the diligence in the intermediate parties is lacking. And the consideration that goes into a well maintained Web is lacking with most DAUs
1: DAU: Dümmster Anzunehmender User, german from most stupid asumeable user
PKI is dead (Score:2)
Honestly, when is the last time you received encrypted email resulting from a succesful key exchange with a user out there in webland?
Re:First, abolish the NSA (Score:3)
I mean, like, "duh".
-russ
Re:PGP (Score:1)
Personaly, I like to use both the P2P flexibility of PGP and the better scalability and ease of use of a centralized PKI.
So far, I've only seen one centralized CA that's helped me to take advantage of both systems, namely thawte.
They used to provide signatures to PGP keys as one of the certificate formats; unfortunately they discontinued PGP support last december for technical reasons.
Still, having your PGP Key signed by a recogniced CA is a good way of increasing its usability, and newer versions of PGP support x.509 certificates. Have a look at my pgp key to see what can be done: Thawte X.509 certs for both addressess I currently use.
End result: if ou DO trust the centralized CA, Thawte in this case, you can immediately trust my key without having to go throug a fairly complex P2P verification. If you don't, well, you've lost nothing - it's still possigle to verify authenticity as with every other key.
Anyone know if there's a CA that can handle certificate requests for NON RSA keys (like PGP DH/DSS keys)?
Re:PGP (Score:2)
They used to provide signatures to PGP keys as one of the certificate formats; unfortunately they discontinued PGP support last december for technical reasons.
Hmmm, I wonder if one of those "technical reasons" might be that Verisign bought them and that Verisign is an X.509 champion?
Existing solutions are terrible (Score:4)
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.
Re:Nice to see it's green (Score:1)
- - - -
Since "pro" is the opposite of "con", what does that make Congress.
Re:PGP (Score:1)
Could be; From talking to their tech people, I got the impression it actually was a technical reason, namely that they switched to new/different server technology for handling signature requests and the new server doesn't do DSA Public key encryption and so can't deal with all PGP keys.
You still run into the same problem if you try to get a Certificate for a DH/DSS key signed using their cut and paste generic interface - it doesn't recognice the key format and rejects the cert request.
Might change in the future though - there's been a lot of discussion regarding this and they're seemingly interested in adding support if possible.
PKI stuff (Score:1)
Re:Unproven Security (Score:1)
first of all, "proof" in this context is a bit useless. what's it mean to be provably secure? most cryptographers agree quantum computing will make pretty much everything we've got today a waste of time (for the one trying to protect the data). heck, we even know how to do that, even if nobody's managed to do it yet...
even beyond that, this concept is a reach at best. most modern encryption techniques depend on factoring certain kinds of numbers, or other similarly time-intesive operations. they all rely on nobody being able to find a shortcut to do the math. by your arguement, no encryption method is sufficiently secure: just because nobody's found such a shortcut yet doesn't mean they won't. but it's a good enough bet for me, and loads of other people who think cryptography is important.
and even were it true that PK systems had a greater risk, your conclusion that they're therefore not worth it does not follow. PK systems have a number of other benefits beyond the strenght of their encryption, such as being able to encrypt to various distinct recipients who share no knowledge other than what you give them, being able to sign and/or encrypt data seperatly, the ability to have a repository or infrastructure for PK discovery... the list goes on. these attributes definatly make PK systems worth consideration in any "serious computing environment" in which data security is important.
Re:Unproven Security (Score:1)
Well gee nobodies invented the warp drive yet so lets stop exploring space until someone builds the USS enterprise!
Sad news from the front lines. (Score:4)
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 [ddj.com]; 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 [neohapsis.com], 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, [argosnet.com] they noted that only 2/3 of all ebiz transactions are done with encryption (and this is an *improvement*!?!).
PKI makes the problem worse; the solution is easy (Score:2)
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 [cam.ac.uk]
Re:PKI is dead (Score:2)
Worse than that, when was the last time you encountered a user out there in webland with a client certificate? How about a client certificate signed by a CA which you trust to have shown due diligence before signing (i.e. not a Thawte free email certificate)?
PKI is hard partly because that stage -- establishing identity before signing -- is intrinsically difficult and expensive.
--
Re:Ok, here's the brief (Score:2)
Several large finacial institutions I know of (including the one that pays my bills!) are in the process of implementing a PKI infastructure internally.
I thought it would interest to compare there views with those poor underpaid, underworked, underachaievers that you pay the bills ofr.
1. No-One has ever (yet) cracked PKI even by brute force or pure math, all cracks have been a result of people or poorly implemented technoligy. And for those 0.0001% of documents that need a higher level of security you can still implement another system (un-networked PCs in locked rooms, with security guards etc. etc.)
2. "Costs are high", we are looking at about $200 dollars per user/employee which counts as "cheap" in this industry.
3."Need to create a policy framework" -- yes but you need to do this for issusing pencils!
4."training" -- you certainly need a highly qualified and skilled team to implement this, but, if it is implemented in a way that requires the users/employees to do anything that requires any training then your team is simply not skilled enough!
Interestingly though all these institutions have concluded that extending the PKI infrastructure to include third partys or the general public was just to complex.
Re:I played aorund with cracking PKI (Score:2)
--
Re:I played aorund with cracking PKI (Score:1)
"// this is the most hacked, evil, bastardized thing I've ever seen. kjb"
Re:PGP (Score:1)
I beg to differ: TC TrustCenter [trustcenter.de]
They still do PGP certificate, PGP PKIs. Their PGP Root key is here [trustcenter.de]
I did say that I work for them and that this is a shameless plug, didn't I?
Re:I played aorund with cracking PKI (Score:2)
... then what you were doing was only related to PKI by its association with RSA encryption.
Public Key Infrastructure is an attempt to solve the problem of how to distribute public keys widely, in a trustworthy manner. Yes, RSA CA signatures are an important part of that, but there are many more parts to the jigsaw (e.g. directory technology such as X500) -- saying you were "cracking PKI" is just confusing (it must be, it certainly confused me).
--
Re:Existing solutions are terrible (Score:1)
The problem with an X.509 PKI is that it's a solution in search of a problem. It's created by the same people who gave us OSI (well, not exactly the same people, many have retired and a new crop has taken their place, but a lot of the OSI cheerleaders are still there and still pushing the same theories which everyone else abandoned a decade ago). X.500 doesn't work (the database guys figured this out 20-30 years ago when they abandoned heirarchical databases), but X.509 PKI is based on them. Revocation doesn't work (credit card companies figured this out 20 years ago when they dropped black-lists and went to online checks), but X.509 PKI is based on them. Global naming schemes don't work (the NADF figured this out 10-15 years ago, most other people didn't even try) but X.509 PKI is based on it. X.509 (nee OSI)'s problem is that it seems to be designed (and is still being designed) by people who have never written a line of code in their life, and couldn't engineer their way out of a wet paper bag. It's a nice theoretical concept and you can get a number of good conference papers and maybe a few PhD theses out of it, as long as you don't make the mistake of thinking it'll work in practice.
The problem with X.509 PKIs isn't export controls, or lack of interest, or provability of the algorithms, or any of the stuff other people have dragged out, it's that it doesn't really know what problem it's solving, and because it aspires to be a universal solution it runs into a huge number of very hard problems which, by themselves, can be solved or worked around, but when you have to address them all (and a universal solution by definition does have to address them all) they're probably insurmountable. Compare this to something like SPKI, which attacks just one problem (authorization) and does it very well. In contrast X.509 was designed to handle certain aspects of access control for users of an X.500 directory (which it did adequately) and has been stretched to cover things it was never intended to do while never actually being used for what it was originally designed for. The sad thing is that while SPKI runs X.509 into the ground in every way, it'll never take off because the rubes have been told that the only PKI is X.509 (even if it doesn't work and there's a good chance it'll never work).
Re:Nice to see it's green (Score:1)
Re:PKI is dead (Score:1)
Let's see... a couple of days ago?
Worse than that, when was the last time you encountered a user out there in webland with a client certificate? How about a client certificate signed by a CA which you trust to have shown due diligence before signing (i.e. not a Thawte free email certificate)?
That would probably be within the last couple of minutes...
This stuff does exist. It is being implemented. Some places you might go for information on real implementations would include:
ACES [gsa.gov] State of Washington [wa.gov] City of San Jose [sjpermits.com]
Note that they're all government. Is it possible that government will lead the charge in this field? Is the rest of the world missing the boat?
Yours,
-jbn
Re:Quantum computing will break PK in a few decade (Score:1)
Not sure this is all that true. Have you ever calculated exactly how much computing power is required to break a 1024 bit key within a person's life??
-jbn
Re:Growing importance (Score:2)
I had assumed everything was contingent on trust too.
That is, I can place some level of trust in Alice (she always seems to play a pivotal role in any crypto scheme!), but how good is my notion of any trust that Alice extends to "easy-sleazy Bob" that might affect me? Those PGP key-signing parties seem a little too ad hoc for some things.
A open, standardized system of kinds and levels of transferable trust is something I'd like to see. Certainly before I electronically transfer money to Charlie's Certifying Authority. And, BTW, I'd like verifiably existing but certifiably anonymous cash, too.
An open, zero-cost-of-entry PKI system would be nice; I can see where at this juncture everyone wants to be the lottery winner with business model that collects micropayments from each and every electronic transaction or ecommerce software installation. That desire is probably delaying the emergence of this technology, since there are probably some bright people that have already thought out a largely workable system.
Publish then. (Score:2)
--
Re:Ehh, not so hot (Score:1)
Re:Public Keys and the end of anonymnity (Score:1)
This from an AC?
Re:First, abolish the NSA (Score:1)
Ahhh. History repeats. (Score:1)
Re:PGP (Score:1)
- this seems to be very much centered on serving customers in Germany - no real procedure is outlined in the webpages (neither german nor english version) for customers outside germany to get certificates
- If I want to get certificates both for netscape-S/Mime and for PGP, I'd have to pay full price twice. I much prefer the aproach that you pay for the verification of user data and, once your data is verified and on file, can request all the (personal) certs containing this verified data without further cost.
Given that the actual cost incurred by the CA is for the verification of user data and that creation of the certificates afterwards is an automated process that shouldn't require aditional user interaction or effort, it doesn't seem to place unfair burden on the Ca either.Re:PKI is dead (Score:2)
Maybe I was assuming people would know what I understand by "out there in webland" -- I guess it wasn't made clear that I was talking about bog standard home web users, the kind who don't know the difference between "email" "the web" and "the internet".
For well defined, closed groups, PKI is a lot easier. For example, all the Lotus Notes accounts used within IBM have a keypair, and the public key is easily obtained from a corporation-wide directory.
--
Re:PGP (Score:1)
Our price modell also gives a certain (up to 50%) rebate on additional certs as well as renewal of existing cert, so the effort for identification is accounted for only once.
As for the lack of international support and the lack of english pages: please visit us again after the CeBit 2001 (~ March 22. 2001), as we will release the new web pages. It is wierd how much longer a cycle takes once you have to watch out for maintaining a certain abount of quality in your pages B-}
This comment is a marketing plug written by a marketing drone. Accept information at you own risk. B-)
Re:PGP (Score:1)
Good to know this, I'd be quite happy with this compromise; if you put it somewhere on your webpage where this information can actually be seen - even better.
please visit us again after the CeBit 2001 (~ March 22. 2001)
I might do even better - since I'll be AT Cebit, I might visit you right there.
we will release the new web pages
Including actual links for getting the free class 1 personal certs referenced elsewhere on your site and including the possibility to get Demo PGP certs I hope (use a demo signing key since a PGP signature can't/doesn't expire).
Also something I like having access to: In adition to the automatic Key generation/submission schemes for Netscape and IE, make a generic cut/paste PKCS10 CSR Interface available.