The Key to the Future
It’s been a long time coming, but it’s nearly here. Key recovery in .NET server promises to improve your Public Key Infrastructure.
- By Roberta Bragg
- April 01, 2002
It’s been a long time coming, but it’s nearly here. Key recovery in .NET
server promises to improve your Public Key Infrastructure.
I’m often amused when something that was old years ago becomes new today,
like platform shoes, mid-thigh-length sweaters, Cosmopolitan drinks (thanks
to Sex and the City) and talking cows. I’m really intrigued and
somehow satisfied when something that old morphs itself into something
not just new, but somehow meant to be, like “Bikers for Babies” road trips,
which raise money for charity; Eric Burdon starting the New Animals; Meals
on Wheels; and Jimmy Carter building houses for Habitat for Humanity.
I guess it’s one of the gifts of age that we can see the continuum of
life and view its rich tapestry.
Also good are the times when technology, instead of shattering boundaries
and making me pant with the effort of learning something new, builds on
my knowledge of the successes, failures and compromises of the past. Without
any effort, climatic bubbles of understanding explode in my brain like
fireworks on the street corners of Grain Valley on New Year’s Eve.
The impending arrival of key recovery in Windows .NET Server, while no
epiphany of the spirit, is an example of one of these technological evolutions.
Note: The features I reference are based on those present
in the .NET beta product I reviewed.
The Key to Our Existence
Everyone’s seeking a way to tighten security. We all want to encrypt
our documents and e-mails to keep them confidential, use smart cards instead
of passwords, and sniffer-proof machine-to machine communications. While
using public/private key technology isn’t the only way to do these things,
it appears to offer a better chance of doing them more reliably and securely.
Please note the word “appears.” Implementing a Public Key Infrastructure
(PKI)—the sum total of keys, certificates, policies and management tools
to support the use of public/private key technologies—isn’t difficult,
but implementing it correctly requires more than the ability to click
buttons and build a network. Strong policies, procedures and best practices
are more important than technology. The repercussions of a poor implementation
are worse than no implementation at all. In fact, while PKI is perceived
to be a panacea—the “final” solution to security by some—others see it
as an evil sham, another soon-to-be-broken promise. The truth lies somewhere
in between. PKI is merely another tool that, if used correctly—as part
of a well-designed security program—can provide better security .
Even a well thought-out, implemented and managed PKI can have problems.
Each private/ public key pair is uniquely matched. If one is used to encrypt,
only the other can decrypt. If something happens to one of them, the other
is useless. While this may not make much difference in some cases (i.e.
new key pairs can be issued for VPN tunnel endpoints and data re-sent,
if necessary), it’s pretty critical in others.
Take e-mail, for example. In order to send me an encrypted e-mail, your
client uses a generated secret key to encrypt the document, then encrypts
that key with my public key and sends the encrypted key along with the
document. Because only I posses the private key, only I can decrypt the
secret encryption key and thus decrypt the e-mail. What happens if I lose
the private key or it becomes corrupt? Then I’m out of luck, unless my
private key has been securely archived and is recoverable.
Or think about EFS. Let’s say I encrypt a file on my hard disk that’s
backed up to tape. My hard drive crashes, and I lose my private key. I
can restore the encrypted file, but what about the private key? No problem
if I remembered to export a copy of my private EFS key and kept it in
a safe place or backed up the entire hard drive and not just the data.
No problem if I’m in a domain environment and an EFS recovery agent exists
(then the recovery agent can decrypt the document). In other cases, it’s
a big problem. I have a few problems with it unless it’s properly managed
within a good PKI implementation. In addition to technical issues, there
are just way too many management issues with EFS’ file recovery model.
These include the fact that so much of the file recovery model has to
be implemented with strong manual procedures so that the recovery agent
can “read” the sensitive file, and a decrypted file has to be somehow
securely returned to the owner for encryption.
An alternative, then, is to provide “key recovery.” Instead of relying
on a recovery agent to recover files, a key recovery agent recovers the
key and returns it. This makes it difficult for the recovery agent to
read the file (he doesn’t have the file and can’t open it with his key).
It isn’t possible to do this with certificate services in Windows 2000,
but it’s configurable in Windows .NET. And here’s where it gets good:
Key recovery has always been available in Exchange. This means key recovery
in .NET isn’t a brand-new Microsoft adventure, nor will it seem extraordinarily
complex to those familiar with its operation in Exchange’s Key Management
Key Management Server
Long before the release of Certificate Server in the Windows NT 4.0 Option
Pack, public/private key technology was available in Exchange Server.
Exchange’s KMS, an optional part of an Exchange organization, provides
sealing (encryption) and signing (digital signature) of e-mail messages.
Prior to Exchange 5.5 SP1, KMS operated as a standalone, proprietary key
Two key pairs are utilized, one for each use. Sealing—or e-mail message
encryption—keys are recoverable. This makes sense. If my sealing keys
are damaged or lost, how will I decrypt an e-mail you sent me? While my
public sealing key (the one you would use to encrypt an e-mail message
to me) may be available in the directory (Exchange directory prior to
Exchange 2000, Active Directory after it), my private key isn’t. My private
sealing key is stored locally, in my profile on my machine, and in the
KMS database. KMS, then, serves as an archive for keys, and only a KMS
Administrator can recover keys.
Signing keys, however, aren’t archived and thus not recoverable. This
makes sense, too. Signing keys don’t encrypt anything I want to decrypt
and read; they merely provide the technology that helps prove that a message
you received from me was really sent by me. This is possible because only
I have my private key, the key used to sign the message. If anybody else
(even a KMS Administrator) could obtain the key, then the digital signature
would be worthless; they could sign a message and pretend to be me. Signing
means the encryption (using the sender’s private key) of a hash of the
message content is attached to the message. The message may or may not
be encrypted as well (if it is, the signing keys aren’t involved in its
encryption; the public sealing key is.) The message receiver uses the
sender’s public key to decrypt the signature and obtain the hash. Then
the receiver can compute the hash of the message and compare this with
the one sent with the message. If the two hashes match, the message must
have come from the sender. The veracity of the digital signature depends
on the fact that only I can have the private key. If the private key could
be recovered, then someone else might be me.
Proprietary, non-interoperable systems can’t exist long in the enterprise.
The NT 4.0 Option Pack provides Certificate Server, which can issue standards-based
certificates. Exchange 5.5 SP1 modified the public key services of Exchange.
Instead of operating on its own, KMS integrated with Certificate Server.
Microsoft PKI v3?
No, they never called it that, but Certificate Services in Win2K is actually
the third implementation of Public Key Infrastructure from Microsoft.
As I’ve detailed, KMS, then Certificate Server, can be thought of as versions
1 and 2. Win2K Certificate Services is the third generation.
In the Exchange 2000 world, Certificate Services, Active Directory and
KMS cooperate to provide the infrastructure. Key recovery is still available.
Figure 1 illustrates key initialization. Figure 2 represents key recovery.
Key Initialization and Key Recovery
|Figure 1. A step-by-step breakdown
of key initialization.
- Mailbox is configured for advanced security by
- KMS generates activation token.
- Token is e-mailed or otherwise distributed to user.
- User/mail client generates keys and transmits public
signing key and public and private sealing keys to
KMS along with token. (User’s private keys are also
stored local in a protected store.)
- KMS validates user (is the token presented assigned
to this user?), stores private key in database, and
forwards public keys to certificate services with
request for certificate.
- CA produces certificates, returned to KMS.
- Certificates published to AD.
- KMS returns certificates to user where they’re
|Figure 2. The process of key
recovery in .NET server.
- KMS Administrator requests key recovery from user’s
- KMS generates token and sends to client.
- Client uses to submit request; no new sealing keys,
but new signing keys.
- KMS validates client, sends clients new signing
public key to CA.
- KMS retrieves original private sealing key from
its database and original public sealing key and certificate
- CA sends KMS client’s new signing certificate.
- CA publishes new signing certificate to AD.
- KMS returns original sealing private key and certificate
to client along with new signing certificate.
The KMS database stores the KMS Administrator password, user private
encryption key and certificate histories. KMS also provides management
tools. The Active Directory stores certificates, encryption preferences
(i.e. what strength encryption they support) and the Certificate Revocation
List. The Outlook client stores user private keys in protected storage,
performs all cryptography on messages, and obtains certificates from AD.
A Peek into the .NET Future
While key recovery has been available in Exchange for about six years
and users of Win2K can archive their own EFS keys using a manual process,
.NET server will soon provide centralized key archiving and recovery.
Even so, as of this writing, key archival in .NET is a still a choice
and not available on every .NET server platform. To obtain the benefits
of key recovery, you must install AD-integrated certificate services on
the .NET Enterprise server. Then you configure templates, assign a Key
Recovery Agent and configure the CA. Here’s a peek at the process:
- If you wish to provide key recovery for a particular function, you
must modify the associated certificate. Certificate templates can only
be modified when the CA resides on .NET Enterprise server.
- The modified certificate templates and Key Recovery Agent certificate
template must be added to those the CA may offer.
- A Key Recovery Agent must enroll (obtain a the recovery certificate).
The Key Recovery Agent certificate must be assigned to the CA as the
one to be used for key recovery.
When users request a certificate, a copy of the associated private key
will be archived. Should their copy of their private key be damaged or
lost, the Key Recovery Agent can recover the key and provide it to them.
How will this help? If a modified EFS certificate template is provided
and used, a lesser chance of compromise will result. Unlike the EFS Recovery
Agent, the Key Recovery Agent has no ability, for example, to read the
encrypted file; encrypted files stay encrypted and remain in the user’s
storage area. There’s no need to move them to “recovery” stations. In
a file-recovery scenario, once the encrypted file is decrypted, it must
somehow be safely moved where it’s accessible to the owner for encryption.
Key recovery isn’t the answer for every use of PKI. Some keys shouldn’t
be archived. Think for a minute about the digital signing keys discussed
in reference to Exchange. If these private keys could be recovered, there
would always be the lingering suspicion that someone could do, or had
done, just that—which would nullify the use. After all, if someone could
obtain my signing key, then that letter signed by me may not have actually
been signed by me.
Please note that these enthusiastic musings are about key archival of
the private keys that belong to employees of an organization and the recovery
of those keys to support the work of that organization should keys become
lost or damaged.
It’s not about key escrow for the specific purpose of delivering the
private keys of these employees (or some master key that could obtain
the private keys) to law enforcement. This form of key escrow, if every
encryption product did so, would give law enforcement the ability to decrypt
all encrypted communications. Some would like that; the argument goes
that it would boost crime detection and crime investigation efforts dealing
with the encrypted communications of criminals. Others say this would
give too much power to law enforcement.
Key recovery in .NET server involves archiving keys in its key database
on the organization’s CA; the very fact that such key archival is possible
means that a key escrow scheme would find easier implementation in a .NET
enterprise. It’s a scary thought.