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

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.

EFS Issues
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 Server (KMS).

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 management solution.

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.

Breaking Down Key Initialization and Key Recovery Figure 1. A step-by-step breakdown of key initialization. Key Initialization Mailbox is configured for advanced security by KMS Administrator. 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 stored. Figure 2. The process of key recovery in .NET server. Key Recovery KMS Administrator requests key recovery from user’s mailbox. 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 from AD. 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.

Key Escrow
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.