PKI: Who Do You Trust?

by Jacqueline Emigh

PKI makes end-to-end security an easier proposition, but mismanagement can create liabilities that leave managers wondering about the integrity of its 'web of trust.'

PKI (public key infrastructure) offers the advantage of rolling together multiple security functions into a single technology In implementing PKI, though, administrators must abide by rock solid security policies to prevent abuses ranging from stolen cryptographic keys to forged digital signatures.

Basically, PKI is meant to provide an end-to-end infrastructure for security functions that include authentication; confidentiality; integrity; and non-repudiation. The security protocol supports single sign-on, digital signatures, and digital time stamping, as well.

PKI can also be used in conjunction with other security approaches. These include S-MIME e-mail; SSL-secured Web sessions; LDAP-secured storage, and IPSec. "In VPNs, IPSec can be secured using PKI components," notes Uday O. Ali Pabrai, chairman and CEO of Ecfirst.com, a security and application solutions provider.

Big banks have been deploying PKI for at least six or seven years now, to help secure online transactions. The US Department of Defense has gotten into the act through CAC (Common Access Card), a initiative for issuing PKI smart cards to military personnel. Other major PKI users include the health care, insurance, and telecom industries.

Meanwhile, though, PKI has come under strong attack, due to the security holes it can engender unless properly deployed. Criticisms revolve around key distribution, management, and storage, as well as real world implementation of PKI's underlying "Web of trust."

PKI uses two different kinds of keys: a public key, ideally stored in an electronic vault; and a private key, generally stored on either the end user's PC or a separate smart card. Data encrypted using the public key can only be decrypted with a complementary private key, for instance.

PKI's key management system is optional, involving both a Certificate Authority (required) and a Registration Authority (optional). The Certificate Authority (CA) issues digital certificates by using a digital signature algorithm which binds the identity of a user or a system to a public key. CAs are also responsible for distributing digital certificates; for scheduling expiration dates; and for revoking certificates when necessary.

"The CA is the most critical component of PKI. A lot of time and effort is expended in trying to understand the requirements of a CA. Should I host my CA, or outsource my CA?" Pabrai observes. Organizations deciding to host their own CAs can use a product such as RSA Security's KeyOn.

Organizations that decide to outsource can either use the services of a commercial CA such as VeriSign, Nortel Entrust, or GTE CyberTrust, or a "trusted" third-party such as a government agency.

Some observers, though, take issue with the notion of "trust" as it applies to CAs. "'Who do we trust, and for what?' There's a risk from an imprecise use of the word 'trust,'" charge Bruce Schneier, CTO of Counterpane Internet Security Inc., and Carl M. Ellison, senior security architect for Intel Corp., in a paper posted on Counterpane's Web site.

"A CA is often defined as 'trusted.' In the cryptographic literature, this only means that it handles its own private keys well. This doesn't mean you can necessarily trust a certificate from that CA for a particular purpose: making a micropayment or signing a million-dollar purchase order. Who gave the CA the authority to grant such authorizations? Who made it trusted?" they ask.

"The whole concept of a PKI is based on trust," writes another observer, in a message posted on the BugTraq forum. "You trust the issuing CA. If you have no faith in the issuing CA then you cannot trust any of the certificates that they have issued, or the organizations to which they were issued. This is not the fault of the organizations, but of the CA itself," he adds.

"While risking the wrath of many, I'll venture to say that unless public, governmental organizations.act as Root CA's and issue certificates to an organization that specifically (prohibit) them from acting as a subordinate CA to other organizations, or to individuals, we won't see much trust in CAs for the foreseeable future."

The RA, where one exists, is supposed to authenticate users' IDs - making sure users "are who they say they are" - as well as to submit certificate requests to the CA.

According to Pabrai, the State of Iowa is now considering a "smart card" driver's license implementation that might revolve around a combined CA/RA model. "The smart cards will hold a digital certificate that will be issued from the State of Iowa. So you can go to (a) Web site and access very sensitive information about yourself stored on (the) state's servers," says Pabrai, who delivered a talk on PKI at the Spring Internet World conference in Los Angeles.

Some, though, oppose the combined CA/RA model. "The RA+CA model is categorically less secure than a system with a CA at the authority's desk. The RA+CA model allows some entity (the CA) that is not an authority on the contents to forge a certificate with the contents. Of course, the CA would sign a contract promising not to do so, but that does not remove the capability," say Schneier and Ellsion.

Internal implementations can be tricky too.. Organizations need to weigh issues such as "Where will you store keys, (and) what will you do if the system crashes?" Pabrai points out.

"One of the biggest risks in any CA-based system is with your own private signing key. How do you protect it? you almost certainly don't own a secure computing system with physical access controls, TEMPEST shielding, "air wall" network security; and other protections; you store your private key on a conventional computer. There, it's subject to attack by viruses and other malicious programs. Even if your private key is in a locked room, with video surveillance, so that you know no one but you ever 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?" insist Schneier and Ellison.

Key distribution policies can be problematic, as well. Pabrai advocates distributing multiple key pairs. An individual end user might receive one private key for encryption, and another for digital signing. That way, when an employee leaves, the organization might hold on to the encryption key, for reading documents the employee previously wrote, while retiring the signing key, so as to prevent future "signing abuses."

PKI technology is complex enough that organizations definitely need to look before they leap. "PKI is handy, but it's not for everyone," according to Vic Wheatman, a Gartner Group analyst. In one report, Gartner spells out how to tell whether an organization is ready for either full inhouse or outsourced PKI deployment, or phased implementation.

Criteria cited by Gartner include level of inhouse expertise; willingness to commit inhouse resources; track record of security budget; types of transactions; sensitivity of transactions; type of industry; and existing information security infrastructure.

As elements of an information security infrastructure, the analysts point to security policies and business continuity plans, as well as to intrusion detection (ID) and firewall and antivirus detection.

For organizations without extensive security infrastructures, "the first priority is to put in place basic policies and infrastructure," according to the report. Over the short term, at least, organizations may be able to get away with either digital certificates without PKI (such as SSL in Web browsers) or symmetric encryption (such as MACs).

» See All Articles by Columnist Jacqueline Emigh

This article was originally published on Friday Jun 7th 2002