Unlocking public key infrastructure

Computer security has been a victim of the 'year of the ...' syndrome. First it was firewalls, then intrusion detection systems, then virtual private networks (VPNs). Now certification authorities (CAs) and public key infrastructure (PKI) are top of the security agenda. The technology behind PKI, however, is not a panacea to all online security problems.

Richard Parris, chief executive at security integrator Intercede, said: "PKI is often mentioned in the media, and by our customers, as if it is some out-of-the-box solution that is the cure to all security problems. Few seem to realise the complexities and limitations involved."

The very idea that PKI technology is a vital component in the ecommerce machine, and that ebusiness will rust and grind to a halt without it, is simply not true. Websites are happy to take your order, regardless of whether you have a certificate.

The fact is that PKI vendors desperately need ecommerce in order to flourish. Because of the explosion in ebusiness, these vendors perhaps overestimated the impact that the technology would have on the market.

Paul McDermot, managing director at Ultimaco, said: "The market for PKI systems during the past two years has not shown the growth most analysts expected. However, large corporates are beginning to move from piloting to rolling out PKIs. Recent initiatives by the UK government to accelerate ebusiness within the public sector, and the knock-on effect this will have within the private sector, will bring an immediate adoption of PKI products and services. The challenge for most organisations over the next year is going to be PKI interoperability."

There are risks in believing the hype - the most obvious being for investors in PKI companies. The actual security risks are borne by anyone who decides to use the product of a commercial PKI vendor.

Backing up this view, Parris said: "Before choosing a PKI solution, organisations need to explore other means of delivering the same level of security, such as smart cards, tokens and VPNs."

Judging value for money
Ian Walker, technical director for Europe, Middle East and Africa at Entrust Technologies, said: "For a PKI pilot, you're talking about more than £25,000. We charge for the CA software with as many RAs (registration authorities) as you like, but we charge for the number of users of the system. You need to look at what a PKI can do rather than its cost, and also at its total cost of ownership. For small companies, PKI is not practicable to implement in-house. Instead, these companies will go to trusted third parties, such as [Royal Mail subsidiary] Viacode, to provide PKI security."

If, as a PKI vendor, you can convince a company to purchase a private CA and pay you a fee for every certificate issued, you're in good shape. It's no wonder so many companies are trying to cash in on this potential market.

Commenting on its PKI charges, Jason Laroche, commercial director at Viacode, said: "You are rapidly into six figures for PKI deployment if you do it yourself in a sizeable organisation. If you outsource to us, there is a price attached to each and every certificate that we issue, once we agree a security policy with the company."

With that much money at stake, it's no surprise that almost all the literature and lobbying on the subject is produced by PKI vendors. The literature leaves a couple of basic questions unanswered, however. What good are certificates anyway and are they secure?

The weakest link
Security is a chain: it's only as strong as the weakest link. The security of any CA system is based on many links and they're not all cryptographic - people are involved.

A CA is often defined as 'trusted'. This narrow definition of cryptographic trust is very different from that used in day-to-day business. In effect, a company will trust the CA - in a similar way it would a bank - to fulfil its obligations to another company. No CAs currently have this level of trust invested in them, despite their sales blarney.

Another major risk in any CA based system is with your own private signing key. How do you protect it? You are very unlikely to own a secure computing system with physical access controls. Instead, you store your private key on a conventional computer where it's subject to attack by viruses and other malicious programs.

Even if your private key is safe on your computer, is your computer in a locked room with video surveillance, so that you know no-one but you uses it? If it's protected by a password, how hard is it to guess that password? If your key is stored on a smart card, how attack-resistant is the card (many are very weak)? If it's stored in a truly attack-resistant device, can an infected driving computer get the trustworthy device to sign something you didn't intend to sign?

Because the digital signature algorithm is designed to be unbreakable, the term 'non-repudiation' becomes important. What this means is that you are not allowed to turn your back on any certificate that has been issued to you by a registered CA. Although at present the government has not passed such a law, it will if the Ecommerce Bill gets passed as expected.

This brings up some interesting legal issues. If a third party, however unlikely this may seem, managed to use a signature issued to you to sign a particular document used for dastardly deeds, it is the owner of the certificate who is held responsible. It doesn't matter who sat at the computer, or what virus may have done the signing, you are to blame.

This is in contrast with credit cards. Under mail and telephone order rules, if you object to a line item on your credit card bill you have the right to repudiate it and say that you didn't buy something - the merchant is then required to prove that you did.

Hence, the computer holding or driving the private key needs to be secure. Long keys don't make up for an insecure system, because total security is as weak as the weakest component in the system. The same applies to the verifying computer - the one that uses the certificate. Certificate verification does not use a secret key, it uses public ones - so there are no secrets to protect.

Playing safe
If attackers can add their own public key to that list, then they can issue their own certificates in someone else's name, which will then be treated as legitimate. In fact, they can match legitimate certificates in every field, except that they would contain a rogue public key rather than the legitimate one, which is not immediately obvious.

It doesn't help to hold these root keys in 'root certificates'. Such certificates are self-signed and offer no increase in security. The only answer is to verify all certificates on a computer system that is invulnerable to penetration by hostile code or physical tampering.

The CA may be an authority on making certificates, but is it an authority on what the certificate contains? For example, an SSL server certificate contains two pieces of security information: the name of the keyholder (usually a corporate name) and the DNS name for the website you are trying to connect to.

Although there are authorities on DNS name assignments, none of the SSL CAs listed in the popular browsers - such as IE5 and Netscape Navigator - is such an authority. What this means is that the DNS name in the certificate is not necessarily true.

Another question that must be asked is whether the application that is using certificates takes the user into account.

For example, a normal user makes a decision to shop with a given SSL-protected web page based on what is displayed on that page. The certificate is not displayed and is not necessarily related to what is displayed. SSL security does not have the ability to control or even react to the content of the web page, only its DNS address.

The corporate name is not compared to anything the user sees and there are some web pages whose certificate is for a company that does web hosting, not for the company whose logo appears on the displayed page. What we get is a bit of a mess, and it's a mess that users should not be expected to sort out.

As Walker admitted: "In a sense, ecommerce does need PKI because there is probably a certificate in your web server created through a low-cost PKI. Entrust sold 35,000 server certificates in the last financial year. We assume people bought them because they are going to use them."

Two-part structure
Some CAs, in response to the fact that they are not authorities on the certificate contents, have created a two-part certification structure: a Registration Authority (RA), run by the authority on the contents, in secure communication with the CA that issues the certificates.

In a worst-case scenario the RA+CA model allows CAs to forge a certificate with the contents provided by the RA. Of course, CAs would sign a contract promising not to do so, but that does not remove the capability.

Meanwhile, the RA+CA is less secure than either the RA or the CA, no matter how strong the RA or how good the contract with the CA.

Parris argued the pros and cons of both approaches. "To keep maximum control and flexibility, it is a good idea to set up your own RA+CA and allow communications only from this central list. Maintenance and revocation of certificates, expiry limits and security policy can be set internally to ensure the most effective use is made of the system," he said.

"The downside is that the system may not be able to communicate with outside agencies because the certificate standard may be implemented differently. The alternative is to use a third party as an RA+CA, which removes the need to set up a secure office, but also removes most of the control and flexibility from the organisation. The organisation also becomes dependent on the trusted third party for this aspect of security," he added.

Certificates are a long way from being the Holy Grail of computer security. They must be used properly to achieve any kind of acceptable result. The fact is that there are so many parties involved in the process that ensuring it all runs smoothly is a nightmare. An example of this is with certificate revocation (CR).

A key's lifetime
CR is the lifetime of any one key, but how is this lifetime computed? A key has a cryptographic lifetime, as well as a theft lifetime, built into the vulnerability estimate of the subsystem storing it. From these, it is possible to compute the probability of the loss of a key as a function of time and usage. Whether or not a vendor does this computation, and even supports key revocation, is debatable.

Although CR lists (CRLs) are built into some certificate standards, many implementations avoid them because they seem to be archaic remnants of the newsprint booklets of bad cheque account numbers that used to be found at the supermarket checkout. Like those booklets, CRLs are seen as too big and too outdated to be relevant. However, if CRLs are not used, how is revocation handled?

Parry said: "The implementation of X.509 certificates varies according to the vendor supplying the certificates, and these are often incompatible. Further, none of the main certification authorities have managed to sort out a practicable method of CR yet, so this area is totally unknown."

Using certificates also requires some sort of user intervention. For example, when you establish an SSL connection with your browser, there's a visual indication that the SSL protocol worked and the link is encrypted. But unless you take the time to read the certificate that you received, you don't know who it is you are talking to.

One PKI vendor a few years ago had great success selling its PKI solution, but its customers were still unhappy. After the CA was installed and all employees had been issued with certificates, the customer turned to the PKI vendor and asked: "OK, how do we do single sign-on?" The answer was: "You don't. That requires a massive change in the underlying system software."

Single sign-on (SSO) is proposed by many PKI vendors, such as Entrust, as the killer app of PKI. Under SSO, you come into work in the morning, plug in your smart card, enter the PIN that activates it and for the rest of the day you don't have to do any more log-ins - all that is handled for you by the SSO mechanism. Of course it's attractive, as authentication is always a pain. Customers will always be interested in a technology that helps them avoid it.

Yet more problems
Unsurprisingly, Walker agreed with this scenario, but side-stepped the issue of the greater cost of enabling applications for SSO.

"You can reduce multiple passwords to a single password by using a certificate-based SSO. Entrust looks to provide the security infrastructure for the enterprise. With PKI, you have one security infrastructure to maintain for remote access, ERP and forms workflow applications," he said. "Most email packages are PKI-enabled, as are SAP, PeopleSoft, Oracle, Baan and Documentum. The added benefit is that you get SSO. You log in once to a PKI server and get authenticated for all PKI-enabled applications. It is not going to work for all applications, since an application needs to be certificate-enabled."

Unfortunately, the security value of authentication is completely defeated by SSO. Authentication is supposed to prove that the user is present at the controlling computer at the time of the test. Under SSO, when the user has to leave the room for any reason, any passing person can walk up to that user's computer and sign on somewhere via the SSO mechanism.

But let's not be cynical. Security is very difficult, both to understand and to implement. Busy system administrators and IT managers don't have the time to really get under the casing of security technologies. PKI vendors know what busy people need: a minimum impact product - a one-stop PKI shop. So that's what vendors offer. Reality still falls far short of this promise, but then business is business and PKI vendors have something to sell.