Should you trust it?

Feature

Should you trust it?

Public key infrastructure (PKI) has been hailed as the saviour for secure e-business. Kevin Townsend explains how the encryption technology works

For several years, public key infrastructure (PKI) has been seen as the key to universal secure electronic transactions. It is what will make e-business happen. But while e-commerce steadily grows, PKI has simply not taken off to the extent expected.

Why? Is PKI a white elephant? The financial markets certainly appear to have lost faith. At the time of writing, Verisign is trading at about one-third of its best in the last year; Baltimore at one-quarter; and Entrust at only a 10th of its 52-week high.

E-business at its most basic is simply an exchange of e-mails. Most people already engage in e-business through e-mail - and the majority use no encryption whatsoever. But as the value and complexity of the exchange increases, so does the need for security. This security is provided by encryption - and the standard methodology for encrypting communications is through a combination of a secret key (symmetric encryption) and public key cryptography (asymmetric encryption).

PKI is a tool for managing the key pairs that are used in public key cryptography. Any methodology that manages these key pairs can be classified as PKI. In reality, the term has specifically come to mean the use of certificate authorities to issue standard X.509 documents (digital certificates) that verify that a public key belongs to a particular person. The digital certificate becomes the electronic identity card, the proof the person you trade with really is who they claim to be.

So PKI provides trust, and it is trust that enables e-business. If the trust is not required, or some other method of obtaining trust is found, then PKI is not needed for e-business.

So far, we have discovered no viable alternative. So why is PKI struggling? In December last year, the research firm Gartner commented, "More than two years after the introduction of PKI, [we]... discovered that 80% of available products and services are still only used in pilot projects."

This actually provides the clue to the problem: PKI is too difficult. More specifically, it is perceived to be too difficult. It is a technology developed and packaged by technologists and sold as a technological product. And it is too expensive. As a result, the market has been told it needs PKI, and if it wants e-business, it will simply have to cough up. Instead, the market seems to have dug in its heels. So, far from being an e-business enabler, PKI has probably delayed the growth of universal e-business.

Rival market analyst IDC is more upbeat. Charles Kolodgy, research manager for IDC's Internet security programme, says, "PKI technology is moving from pilot testing into the real world of e-commerce. The push toward B2B e-commerce is fuelling the adoption of PKI as a business-enablement infrastructure tool for distributed authentication, authorisation, encryption and administration.

"New deployments of PKI technologies - including remote access, secure messaging, content delivery and transactional security - demonstrate the technology's transition from the test track to the production roadway," Kolodgy adds.

The real reason for this is a shift in emphasis. PKI is no longer viewed as the enabler of B2B e-business, but as the technology underpinning the applications that do the enabling. PKI is being introduced by stealth, incorporated within other products that the market understands - like virtual private networks, user authentication and secure e-mail. In the meantime, problems remain.

But PKI is not the only problem. E-business is a completely new business paradigm. So implementing PKI is merely a part of changing the whole way a business operates, from paper to bits. This is costly, complex and, in reality, probably requires the assistance of a specialist consultancy. This route is feasible for the larger company but smaller ones are likely to implement PKI in bits and pieces as part of other applications.

The danger here is that companies might find themselves with islands of PKI that cannot interoperate. As usual, although there is a de facto standard certificate in X.509, interpretations of the standard by different suppliers causes problems. The PKI Forum, an organisation comprising all the major PKI suppliers, is working towards interoperability - but it is not there yet.

The X.509 certificate is the authenticator. That means the user must have access to the certificate. The majority of certificates are currently stored within browsers - so the user only has access to the certificate when using the PC that holds the browser. Similarly, a certificate stored separately on the PC remains both limiting and insecure. Frederic Engel of ActivCard explains, "A certificate on a PC is only as strong as a static password."

And certificate theft will bring with it a new range of problems and difficulties - not least the question of who bears the liability for subsequent fraud.

For once, Europe, rather than North America, seems to be making the running. There are two more logical places to store a certificate: a mobile phone and a smartcard. Openwave Systems, developer of UP.Browser which is used by most Wap-enabled phones, is now incorporating embedded root keys within the browser, making the inclusion of a personal certificate on the user's personal mobile phone a relatively simple matter.

Smart solution

But the real solution will come when certificates are included on smartcards. There are still technological scale problems - such as the keys need to be generated on the individual cards - but it seems to be the logical answer. Cost is the inhibitor since universal smartcards will be very expensive. Governments might implement it, particularly when it becomes part of a required identity card - but this raises issues of civil liberty.

The logical answer is for the banks to issue smartcards instead of plastic credit cards. As the cost of plastic card fraud soars, the potential savings via smartcards becomes an attractive proposition. A spokesperson for the Association for Payment Clearing Services says, "There are nearly 120 million credit, debit, charge, cash machine and cheque guarantee cards in issue in the UK. The majority of these will be replaced with ones containing a chip by each bank or building society according to its own plans from spring 1999. By 2002, the vast majority of UK-issued payment cards will contain a chip."

From here, it is a short step for these smartcards to include PKI digital certificates. The banks, after all, are already in the business of trusted relationships and have a history of working together on a global scale.

In short, PKI is coming because there is no alternative. In smaller companies it will arrive by stealth, embedded within other applications. The larger companies will bite the bullet, spend the money and use large e-business consultancies to bring it in as painlessly, and as interoperably as possible.

Soapbox

Public key cryptography in e-mails

Public key cryptography involves the use of two mathematically related keys, the key pair. One is kept private by the owner and the other is made public.

The important point is that if a message is encrypted with one of the keys, it can only be decrypted by the other associated key. For example, if Bob wants to send a secure message to Alice, Bob uses Alice's public key to encrypt it, safe in the knowledge that only Alice's private key can decrypt it.

In reality, the overheads of using asymmetric encryption are so great it is generally used only to encrypt a symmetric session key - a one-time only key - that is used to encrypt the entire message. Both are sent together, so Alice first decrypts the session key with her private key, and then decrypts the message with the session key.

Note there are several issues that arise:

  • Bob must know or be able to obtain Alice's public key; and he must verify it is the correct key for the correct Alice and not some Alice impersonator

  • Bob cannot be certain only Alice can read the message. All he knows is only Alice's private key can decrypt the message

  • Bob cannot be certain that Alice even gets the message

  • Alice cannot be certain it really was Bob who sent the message (but see digital signatures box).

    PKI tries to resolve these issues.

    Digital signatures

    For secure e-mail, Bob would use Alice's public key for the message and Alice would use her private key to decrypt it. If you reverse this procedure, you get the beginnings of a digital signature. Bob encrypts something with his private key. Alice can then decrypt it with Bob's public key, proving that only Bob could have encrypted it in the first place.

    If the encrypted item is a message digest (a one-way hash of the message itself), then Bob is not merely proving his own identity, he is also "stamping" his identity on this particular message. In other words, he has digitally signed it. In theory, this also provides "non-repudiation" since Bob cannot later deny that only he was able sign it and therefore only he was able to generate the encrypted message. And it also provides "integrity" through a comparison of the hash value sent as the message digest with a hash value generated from the received message.

    Again, there are several issues that arise:

    It is not Bob, but the holder of Bob's private key, that is signing the document. So, protection of the private key becomes of paramount importance. Similarly, the ability to revoke a lost or compromised private key is essential but the difficulty here is in letting everybody know that a key has been revoked.

    PKI tries to resolve such issues. However, it cannot resolve the legal problem of non-repudiation. In the final analysis, Bob may still claim and even be able to prove that his digital signature was "stolen" prior to the generation of the message. This then becomes a legal rather than a technical issue.

    Digital certificates

    A digital certificate is an electronic document (the de facto standard is X.509) that confirms the relationship between a public key and its owner. The certificate itself is digitally signed by the issuing certificate authority (CA). The CA publishes the steps it will take to verify the relationship between the owner and the key before issuing a certificate.

    If Alice receives a message from a strange Bob supported by Bob's digital certificate, and provided she trusts the CA that issued the certificate, then she can trust the identity of Bob.

    The primary purposes of PKI is to issue and manage digital certificates; to provide ready access to public keys (usually through LDap directories); and to similarly provide ready access to certificate revocation lists.

    The identity of the CA is not important - only that the CA is trusted. Thus a company can be the CA for its own staff. Outside of the company, the inherent trust diminishes. To solve this, the company can be certified by a "higher" CA, which may in turn be certified by an even higher CA - until such time as a universally trusted CA is reached.

    What do you think?

    Is IT security being taken seriously by the rest of the company? Computer Weekly wants to hear of your experiences when tackling this issue. Please send us 150 words in response to the question: How far is your security strategy being compromised by a lack of funding or recognition from the board?

    In return, the best 50 respondents will receive a copy of Secrets and Lies, the new book by security guru Bruce Schneier, donated by The Encyclopedia of Computer Security (www.itsecurity.com).

    Please send replies to ross.bentley@rbi.co.uk. All responses will be treated in confidence.


  • Email Alerts

    Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
    By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

    This was first published in February 2001

     

    COMMENTS powered by Disqus  //  Commenting policy