Third-party certification authority support for encrypting file system

This article describes how Microsoft Windows 2000 supports third-party Certification Authorities (CAs) that issue Encrypting File System (EFS) certificates and EFS Recovery Agent certificates.

Overview

This article is divided into the following two sections:

• A brief explanation of EFS and its use of the public key infrastructure.
• The way in which a third-party CA is permitted to issue certificates for use by EFS for both file encryption and recovery.

EFS overview and the public key infrastructure

EFS is the solution in Windows 2000 for encrypting files on NTFS file system volumes. EFS uses the Crypto Architecture feature and Public Key Infrastructure feature in Windows 2000.

Certificate enrollment

During an encryption operation, EFS uses your current EFS certificate. If one is not available, EFS searches your personal store for an appropriate certificate. If EFS cannot locate a current certificate, it enrolls you for an EFS certificate. An online Windows 2000 CA that supports the EFS template can issue an EFS certificate. A self-signed certificate is generated by EFS if it cannot enroll for a certificate with an online Windows 2000 CA or if you are not using a domain account.

After EFS chooses a certificate, you cannot change it through the system user interface. Additionally, EFS does not automatically switch certificates when a better one becomes available (such as when EFS uses its own self-signed certificate and you enroll for an EFS certificate from an online Windows 2000 CA).

There are two ways to change the certificate that EFS uses:

• To set the new certificate for EFS, use the SetUserFileEncryptionKey API, which is documented by Microsoft Developer Network (MSDN). EFS starts using the new certificate immediately.
• Change the hash of the certificate that is stored in the following registry key to the Thumbprint field in the new certificate:
  HKEY_CURRENT_USER\Software\Microsoft\Windows NT\Current Version\EFS\CurrentKeys
  
  Value: CertificateHash
  Type: REG_BINARY
  Data: Thumbprint of the new certificate

EFS expects the keys for the EFS certificate to be stored in Microsoft Rivest-Shamir-Adelman Base (RSABase) Crypto Service Provider (CSP). The Key Info attribute on the certificate should point to this CSP. EFS looks in the MY certificate store, which contains certificates and private keys.

File data encryption and decryption

EFS uses a randomly-generated symmetric key to encrypt file data. A new key is generated for each file that is encrypted. The data encryption algorithm that is used is DESX (a stronger version of Data Encryption Standard). No other algorithms can be configured.

The symmetric encrypting key is then encrypted by using the public key derived from your EFS certificate. The resulting encrypted data, your display name, and a hash of the certificate is stored in a named stream in the file that contains EFS metadata. When EFS decrypts a file, it uses your private key to decrypt the symmetric encrypting key. EFS then uses the symmetric key to decrypt the data.

To encrypt a file on a network server, EFS loads your profile on the network if you have roaming profiles. If you do not have roaming profiles, EFS expects to find your certificate and keys on the server and tries to generate a profile there.

When an EFS file is copied over a network, it is decrypted and sent over the network in clear text. To protect your files while they are in transit on your network, use IP Security.

EFS certificate renewal

When the EFS certificate expires, EFS performs renewal by enrolling for a new certificate with a new key pair. EFS, itself, does not renew the current certificate when it expires.

If you renew the EFS certificate and archive the old certificate before it expires, EFS continues to use the old certificate until it expires. EFS then goes through the same process for enrollment to find a new certificate in the store or to acquire a new one if it cannot find a valid certificate. While looking for a new certificate to use, EFS can fetch a certificate that is different from the one that you acquired through renewal, if there is more than one EFS certificate in the store.

After EFS starts to use a new certificate, if it handles a file that was previously encrypted with a different certificate, EFS regenerates the metadata to use the new certificate.

Revocation checking

EFS does not perform any revocation checking.

EFS Recovery Agent

You can use EFS Recovery Agents to decrypt an encrypted file if the user who encrypted the file leaves your company. You can enroll for EFS Recovery Agent certificates using the EFS Recovery template on Windows 2000 CAs.

You can set EFS Recovery Agent certificates in global domain policy for all users on the domain. You can also set these certificates for all the users on the local computer in local computer policy. If both policies are present, the global policy takes precedence.

To open the Add Recovery Agent Wizard, click Group Policy, click Public Key Policies, and then click Encrypted Data Recovery Agents. This wizard helps you designate Recovery Agent certificates. You can click Browse Folders, and then click the certificate file to directly import it as the Recovery Agent certificate. The certificate is imported with the Recovery Agent notation User unknown. This occurs for any third-party CA certificate that you designate as a Recovery Agent certificate.

If you publish the certificate in the directory for a user (which occurs if you enroll against an online Windows 2000 CA for the EFS Recovery Agent certificate for the user), you can use the wizard to directly import the user as a recovery agent. Browse through the directory and select the user who you want to designate as the recovery agent.

During file encryption, the symmetric encrypting key is also encrypted to the recovery agent's public key, and the information is stored in the named stream containing EFS metadata. To recover an encrypted file, EFS uses the recovery agent's private key to decrypt the symmetric encrypting key, which EFS then uses to decrypt the data.

Rules for third-party CA for creating and using valid EFS and EFS Recovery Agent certificates

EFS certificates

The rules for forming the certificate are:

• The Key Usage extension in the certificate must contain Key Encipherment and Data Encipherment.
• The Enhanced Key Usage extension in the certificate must contain the Encrypting File System (1.3.6.1.4.1.311.10.3.4) identifier.
• During usage, you must store the keys in the Microsoft RSABase CSP.
• The Key Info property on the certificate must point to this key.

To contain the right KeyUsage and EnhancedKeyUsage values, you may have to customize the third-party certification authorities to issue certificates that contain the correct values.

There are two ways to enroll for the EFS certificates using third-party products:

• The third-party CA may provide an enrollment that is independent of Microsoft Crypto Architecture. In that case, the third party must export the certificate, and the private key that is associated with the certificate, into a file that can be imported into your profile by using the Certificate Manager MMC snap-in. The keys are imported into the Microsoft RSABase CSP and the Key Info property is set to this CSP.
• The third-party CA may provide a Web-based enrollment procedure that uses the Microsoft XEnroll control for Microsoft clients to enroll for certificates. Using this method of enrollment, the keys are stored automatically in the Microsoft RSABase CSP and the Key Info property is set.

After you enroll for a certificate, or after you renew a certificate, you must inform EFS about the change if it has used any certificate previously. You have to set up a call to SetUserFileEncryptionKey that points at the new certificate. If the certificate is created before any EFS operation, you do not have to set up a call SetUserFileEncryptionKey. EFS finds the new certificate in your personal certificate store and sets it as the default certificate.

EFS recovery certificates

The rules for forming the certificate are:

• Key Usage = Key Encipherment
• EKU = File Recovery(1.3.6.1.4.1.311.10.3.4.1)

As stated in the "EFS Certificate" section, the third-party CA may provide Microsoft clients with Web enrollment pages to enroll for the certificates, or the third-party CA may export the certificate and the associated private key into a file that can be imported into a Microsoft client.

After it is created, the certificate can be imported by using the Recovery Agent Wizard.

During file recovery, both the file recovery certificate and the private key must be imported into the system that is used to recover the files according to the following guidelines:

• Keys must be stored in the Microsoft RSABase CSP.
• The Key Info property on the certificate must point to this key in the RSABase CSP. The provider name should be "Microsoft Base Cryptographic Provider v1.0."

You can use Certificate Import in the Certificate MMC snap-in to import the certificate and private key. IMPORTANT: The rules that are outlined in this article were validated by Microsoft by configuring a leading, third-party certification authority product to issue EFS and EFS Recovery Agent certificates. The EFS test team tested encryption and recovery by using these certificates.