Is The Public Key Infrastructure Outdated?

dchat writes: "Roger Clarke, Visiting Fellow, Faculty of Engineering and Information Technology at the Australian National University claims that the "Conventional, hierarchical PKI, built around the ISO standard X.509, has been, and will continue to be, a substantial failure", and then he goes on to explain why. I'd be interested in the views of Slashdot users, as my organisation is contemplating considerable investment in X.500 and PKI (including X.509)." Lots to read here.

Re:Considerable investment?

That would be hella-stupid, unless you have people on staff who are *extremely* qualified at implementing cryptography. 4000 bit keys are useless if you make a moronic mistake implementing the key system. If you need security, use PGP, GPG, SSH, or some other reliable, already implemented open protocal.

It's in the implementation..

I think that the author of this paper get's it about 1/2 right - especially when he says that the current "standard" way of implementing the Registration Agent process is flawed - it is - most companies that offer Certificates do so with a great deal of show about the fact that you can now sign your e-mail, but with very little education and thought in the overall security chain process. What is worse, is that most Major PKI vendors don't have real Certificate Policies - instead, they publish Certification Practice Statements that wrap all of the various certificate type up in one bundle, without explaining in clear, consise language what the reasonable trust expectation would be out of any given certificate - thus leaving the certificate purchaser a very fake sense of security. So, that said - I would have to disagree with the Article Author, when he says that we need to abandon X.509 based PKI's - I would say the exact opposite - we need to adopt them, but with a carefull eye to standards compliance, and with large amounts of user education. There needs to be some common criteria established that allows consumers to rate the various PKI's currently offered, and decide which ones actually can provide the trust levels that are required in their particular circumstances.

Re:Considerable investment?

What do you mean by 512 bit version of des? Did you just screw with the key generation scheme for each round? Is that really that much more secure? Encrypting data twice with des does not give you much more security. That's why there's 3Des but not 2des. I'm not convinced that what you do is significantly more secure. esp if you messed with the S-boxes and stuff. Using a proprietary system has glaring disadvantages, such as umm... not having anyone being able to decrypt or encrypt data unless you send him/her your homebrewed system. So if they intercept this transmission, there goes your security through obscurity. If data you're sending is within a private organization, it usually makes more sense to use private key systems. Plus, public key systems are slow. Implementing 3k-4k bit keys would be stupid since there isn't a need for it. And of course, as mentioned somewhere else, the article talks about key deployment and models of trust, not cipher strength.

Re:hierarchical PKI is doomed..

these new methods you propose are no better. if you could have gotten access to someone's PKI private key you can get access to all their individualized authentication keys. this means you can impersonate them at least everywhere they've been before.

also, there's the issue of accountability. with PKI you can use post offices, biometrics, chips etc. what do you do with individualized systems when you want to do a first transaction between a person and a website? you can't use 'reputation' without some universal identifier that would make these individualized systems useless if it worked. so what's left, credit card or social security numbers? how do you transmit to be used in a crypto-system you haven't yet established (because you're going to use these numbers as keys for the system). they can be intercepted, and if you don't use these numbers what have you got left? there has got to be some global protocol for the initial communication, and everyone needs a public key. the only advantage of PKI over a credit card or soc # is that you don't care if people intercept your PKI public key!

Good Enough?

The author is saying that complete trustworthyness is unobtainable.

Duh!

There is no magic pixie dust that you can sprinkle on e-commerce (or anything else, for that matter) to make it "secure". You'll have a hard enough time just defining what "secure" really means for a given application.

The real question is, "is it good enough?". You are the only one who can answer that. Is what you are buying appropriate for your application?

One very big red flag is your comment that you are contemplating a "considerable investment". Sounds like somebody is trying to sell you a trainload of snake oil. The basics of PKI are not that complicated.

Personally, I'll trust a CA when they agree to be liable for consequential damages, ie, "We agree to pay any damages you've suffered caused by your reliance on our certificates". I'm not holding my breath.

--

hierarchical PKI is doomed..

I've been working in security/authentication/PKI related areas for close to 15 years. The paper is entirely correct that a hierarchical PKI is doomed to failure because it implies a One True Root which everyone trusts.

I believe that what eventually will to evolve is a whole bunch of little problem-domain-specific public-key infrastructures, some of which will use x.509 certificate formats, some of which won't. pgp, ssh, secure dns, etc, all "do their own thing" and provide a public key infrastructure to attempt to solve the piece of the problem they care about without getting tangled into the morass of hierarchical PKI which caused Privacy Enhanced Mail (PEM) to sink without a trace..

An informed, yet biased reply

I work writing code for one of the major players in the PKI space. Without mentioning any names, or making any plugs, I would advise you to think longand hard about what you are trying to accomplished with PKI and why. A lot of the existing products on the market are more interested in domination of the market, and less on being the transparent (if elaborate) infrastructure PKI was designed to be. PKI should be as dependable and transparent as any of the other internet "specs" when done right. Of course, history has shown that nothing is ever that simple, just look at the wars being fought over Java or the ones over HTML (which have died down to some extent.) PKI works well for those who are willing to suffer the pains of being an early adopter. Micro$oft and Netscape browsers don't parse certs the same. (Sadly, I have to admit that M$ is ahead in this area.) The major vendors often have interperated the specs just differently enough to make interoptability a major problem. My advice is to find a product which fits your present needs, and seems to offer the flexibility to expand into the future. The flexibility is going to require a willingness to play nicely with others and to intergrate with existing apps. Stay away from total end-to-end solutions. You are not looking for a "structure" but an "infra-structure". For all the complexity, PKI is likely to become much more wide spread due simply to the demand being placed on the internet by cooperations. IPSec and smart cards are becoming a reality, and the best way to manage those is PKI. The other benefit here is that with physical smart cards, private key theft is nearly impossible. (The only exploits I know of involve physical access, and LOTS of equipment beyond the reach of the average skript kiddie) As PKI becomes more widely deployed, it's providers will be force to become more standardized or get out of the game. Just like with the Web, early adopters had a lot of headaches with different browsers HTML parsers, image formats, etc... but these days those issues have mostly been dealt with, and the early adopters now have a stronger business because of longer term involvement in the medium.

You're right - the world needs SPKI.

Yes, the whole hierarchical X.509 approach was doomed from the start and needs to die. What the world really needs is the Simple Public Key Infrastructure, SPKI [std.com]. This provides a way to generate certificates which transfer trust between keys in various sorts of highly flexible, controllable ways. Read the SPKI docs and you'll be converted to our religion; your whole view of naming, and of the role of a PKI, will change.

SPKI is the public key infrastructure that can actually achieve what it promises, because it doesn't have a root certificate that only God could properly hold. It's the ideas of PGP's Web of Trust taken to their logical conclusion. And it is simple, and neat, and easy to understand. Everyone interested in the problems with PKI should look into it.
--

Bunk.

The paper is really hugely inflammatory.

Either Clarke generalizes problems to all deployments of PKI, or he blames PKI for wider 'security is just plain hard' problems.

Here's some examples:

• In 3.2 he describes a long list of proposed requirements to prove identity. This is interesting, but avoids the plain fact that proving identity is not only a problem for PKI. Besides, many corporate implementations of PKI issue building-access badges to users with similar proof-of-identity requirements. Is it too much to ask to issue a smartcard at the same time? No, institutions do this today.
• He claims that PKI implies one trusted root. Wrong. Look in your browser for about 30. You can decide to trust or not trust each of them. You can add new ones.
• He claims that conventional PKI has a string of restrictions which are basically choices made by the implementor of a particular PKI deployment. Out of this list, I have only ever seen 3:
  1. "a certificate that expressly claims to 'bind' the key to a person" - this depends on how well the RA authenticates the user. An intrinsic problem with any organization issuing credentials - not just PKI.
  2. little or no choice as to who will issue the token - This is understandable, since the PKI group in an organization will typcially have determined the most appropriate security class of tokens for the deplyoment.
  3. Little or no choice in the organisation from which the individual acquires a certificate - again, up to the individual deployment.
  All of the other items are plain not true. And any organization who does keygen on behalf of a user is plain dumb.
• In 4, he claims that it's possible to steal keys by breaking into a server. Again, that's up to the deployment. We recommend that keys are stored on hardware tokens. Plain and simple. Most devices do not provide for a facility to remove a key from a hardware token.
• "Private keys are susceptible to a vast array of risks, both of capture, and of invocation without the authority of, or even knowledge of, the consumer/citizen. - bunk. Plus, the rest of the paragraph doesn't really support this sentence anyway.
• In 5, he says that the Name Space has to be well managed and requires cooperation of different entities. Not true. Thawte and Verisign did not have to cooperate before because they had different roots. This is a point he doesn't seem to understand at all.
• dot, dot, dot ...

There are many ways to set up a PKI. You can set up a PKI with any or all of the problems Clarke cites. That would be the wrong way

With a little more work, his paper could have been a very constructive HOWTO, to inform the reader how to set up a good PKI. However, he just rants on about problems, none of which are unique to PKI, without providing the solutions, most of which are well known.

His paper should be titled "Pitfalls to avoid when setting up a PKI".

PKI is dead. Long live SPKI.

The PKI movement has been riddled by ita own complexity ever since its beginning.

The problem with PKI is that it depends on a common trusted root, and a global namespace. It is also hampered by crude certificate revocation methods.

There is a movement towards a simpler PKI, SPKI, which addresses all those isues. Of course, there will be need for co-operation between about the both approaches.

See Carl Ellison's page [std.com] for more great info, especially a thorough comparison of approaches [std.com].