Who ARE you?

When it comes to keeping your system safe from hackers trying to ride a Trojan horse through your defense perimeter, a Certificate Authority can make sure everybody’s exactly who they claim to be.

• By Michael Chacon
• June 01, 2001

Are you who you say you are?

Although this may seem like a simple question, it harbors an underlying complexity when you apply it to proving your identity across remote information systems. And you can’t avoid the question, because the concept of virtual identity is critical to the next step in the development of information systems as they begin to provide and use services beyond our current castle-wall, perimeter-based systems. As the relationships between organizations blur, the need to firmly establish valid remote identity for the purpose of authentication, and to apply permissions to users beyond those perimeters, will only grow.

Oh Yeah? Well, Prove It!
Beyond the technical issues, one of the reasons a virtual identity is difficult to deal with is that we have so many of them. How many accounts and passwords do you have in your own company, not to mention spread around the Internet? And take a look at the physical world. You probably have a driver’s license, library card, various credit cards and many other forms of identity validation—each tied to a particular service or privilege. Which one really represents you? Of course, they all represent you. The problem is that each one is only a portion of your identity. In addition, the identities aren’t interrelated. The perceived authority of the organization that issues the identity documents determines the level of trust. For example, a passport has a higher level of trust than a library card. However, most of these physical identification documents are easily counterfeited. Therefore, in the physical world, we generally rely upon a number of independent identification cards to create higher levels of trust.

In the virtual world, this problem is slowly being addressed through some applied technology standards. While there’s still quite a way to go toward centrally managing identity, the necessary pieces—such as Certificate Authority software, directory services to store certificates, and services that use the certificates—are falling into place. One of the core solution pieces to the problem of validated identity is a Certificate Authority, which offers these services through the implementation of standards-based technology. Strictly speaking, a CA is an entity (usually a company) that issues digital certificates to other entities, usually organizations or individual users, which verify the recipient’s identity to yet other entities—usually information systems. But, whom do you trust?

Get Validated
You’re probably most familiar with CAs provided by companies such as VeriSign, Entrust and others that are building their futures around validated identity services. This is a good business bet. The systems that these companies are building, along with your internal CA, are going to be fundamental parts of your information systems. CA servers will be as ubiquitous as DNS, DHCP, and, the grand repository of certificates, Directory Services.

The CA is the fundamental trust component of the broader security architecture known as a Public Key Infrastructure (PKI). The PKI uses the CA to create and manage certificates to validate a symbiotic set of keys—one private and the other public. The CA role as a server is to create digital certificates, not unlike the physical models I described previously. However, instead of physical documents, these digital certificates contain the user’s public key, logical identity and other information. The certificate is protected by a “hash” to create a seal verifying the integrity of the data in the certificate—thereby ensuring identity. Figure 1 is an example of a certificate—with the identifying text along with a portion of the hex display of the public digital key—from CREN laboratory (www.cren.net/ca/sample.html) in Switzerland where the World Wide Web was developed.

Figure 1. An example of a certificate—which contains the users public key, logical identity and other information—along with a portion of the hex display of the public digital key.

A Question of Trust
The trustworthiness of the resulting certificate is entirely based upon the level of trust you have for the CA that’s verifying the certificates. If Bob’s Cert Shop verifies a certificate, you may not have the same level of trust as if it were verified by Entrust. While a CA specifically refers to an organization or entity that issues certificates and verifies entities, the term is also commonly used to refer to the actual servers that create and manage the keys and certificates. They’re used in tandem to verify identity for a wide variety of services. The private key is held by the owner and is used to sign and un-encrypt data. The public key is contained in the certificate along with the owner’s unique logical identity, usually in the form of the user’s e-mail address. The public key is used to verify digitally signed messages and to encrypt data that’s sent to the owner of the private key. The public key is passed around as widely as possible or published in an accessible location. The idea is that the person who owns the certificate is the only one—providing it’s properly cared for—who can present the private key for authentication purposes.

The most common use today for these certificates and the key pairs, along with Web site authentication, is for securing e-mail communications through either digitally signing the message or encrypting the entire message. Certificates can also be used to digitally sign software updates so the user can be sure the software is really from the proper vendor rather than from a hacker trying to ride a Trojan horse through your defense perimeter. Two other uses for certificates are to enable Encrypting File System (EFS) and IPSec authentication for secure point-to-point communications.

Most companies currently rely upon commercial CAs because of the seeming complexity involved in setting up and administering them. This will change as services such as IPSec and EFS—which are based upon internal authorities that don’t have to be linked to external CAs—are more widely deployed. With the coming onslaught of these services, the CAs will be brought inside, which will build up the internal expertise in this area.

Ultimately, CAs aren’t based upon technology, they’re based upon trust. This moves the issue from the technical to the strategic arena. For example, you may want to assure external customers that you are who you claim to be, so you install a CA to generate the requisite certificates. The problem with this is that your CA verification is self-referential. A greater degree of trust is established by having a third-party organization (that the client trusts) verify that your organization is valid. This is why companies such as VeriSign should grow and flourish. You’ll also see brick-and-mortar financial institutions, which are already proficient in and have a reputation with trust, start providing CA services to other companies.

The CA Pecking Order
A standard CA system is built upon a hierarchy of servers, with each layer trusting the one above it, similar to a DNS hierarchy. When a lower-level CA issues a certificate, the recipient values its veracity because it already trusts the higher-level CA. This minimizes the number of CAs that any foreign entity needs to trust while utilizing the resources of downstream resources. The most common system is built upon a three-level hierarchy as seen in Figure 2.

Figure 2. A standard CA system is built upon a hierarchy of servers—a root CA level, a policy CA level and issuing CA level—with each layer trusting the one above it.

The first level is called the root CA, which self-referentially certifies itself. This one is usually kept offline so that it can’t be accessed through normal channels and become compromised by evil forces. If the root CA is compromised, all the CA servers downstream lose their validity and your entire security system is compromised. This is a bad thing. The second-level CA is usually used to create and administer the policies of the CA system and to provide the character of the certificates issued by the CA servers below it. The third-level CA comprises the servers that actually create and issue the certificates, which are used by the various services previously described.

This model contradicts the notion that there isn’t a pervasive PKI infrastructure in place today. Therefore you’ll have to plan for multiple “root” or top-level CAs that your organization will trust. However, you can have your second-level CAs trust these other external root CAs so you can manage the trusts throughout your organization without having all of these certificates installed independently in all of your devices.

You may have one certificate for internal uses such as EFS or local IPSec traffic—then you can use your self-referential root CA. However, you may also want to provide access to local resources to a user outside of your administrative domain. You’ll add the certificate from the CA responsible for that user and have your CA trust it. This allows your local resource to trust the foreign user. This type of scenario will become more common as we create more networks without frontiers.

With this background on CAs and trust in place, next month I’ll discuss how the CA is implemented in Windows 2000 to support the various certificate-reliant services, such as IPSec and EFS, which are part of Win2K’s overall service architecture.