Windows Insider
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.
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.