Using AD RMS with Hardware Security Modules
Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012
Active Directory Rights Management Services (AD RMS) is an information protection platform that enables documents to be shared with protection so that only authorized users are allowed to perform specific actions on them. In order to ensure that content remains protected, AD RMS utilizes cryptographic technologies that require the generation and storage of public and private keys. Key management can affect both server performance as well as potentially raise concerns about the security of the private keys involved as any loss of such keys could cause the protection benefits offered by AD RMS to be lost. While AD RMS provides strong password-based protection for its server keys, this option relies on having good operational procedures and tight management of the servers and passwords to maintain security of the keys, constrains which in some organizations might not offer enough guarantees.
One way these implications can be addressed is by the use of hardware security modules (HSMs), which are third-party products that can be used in connection with your existing AD RMS infrastructure. By offloading key management tasks and some cryptographic processing from your AD RMS servers to an HSM, you can reduce processing overhead for each AD RMS server and also ensure that any private keys it uses are not exposed or stolen if your AD RMS deployment should ever be breached or compromised administratively.
In this guide
This guide is intended to provide additional general guidance on using HSMs with AD RMS. It also contains some instructions for extending a base setup of an AD RMS test lab to include HSMs.
To make full use of the lab setup instructions for setting up and configuring HSMs with AD RMS, you will need to have first completed the following additional test lab guides:
How AD RMS Benefits From HSMs
AD RMS is an information protection platform that enables authors and publishers to define usage policies on their documents, establish who can access those documents and what operations can be performed on them. To achieve this type of document protection, the content protected by AD RMS is encrypted by supporting applications using 128-bit or 256-bit AES (Advanced Encryption Services) symmetric encryption to provide fast, strong protection.
In order to best understand how AD RMS benefits from the use of hardware security modules it helps to have a deeper understanding of how AD RMS uses AES encryption and the encryption keys required to support it.
How AD RMS Does Encryption and Uses Encryption Keys
Symmetric key encryption uses the same key to encrypt and decrypt content. But as the decryption keys for the content have to be made available to the clients that need to consume it, AD RMS uses asymmetric encryption with private/public key pairs to protect the encryption keys. All AD RMS servers, client computers, and user accounts have a public and private pair of 1,024-bit or 2,048-bit RSA–based encryption keys (depending on deployment options). AD RMS uses its private key to encrypt the content encryption symmetric key along with the rights policy data in the publishing license and the use license in each document. AD RMS also uses the private keys to digitally sign AD RMS certificates and licenses, ensuring certificates are not tampered with at the time users use them to request access to protected information.
How HSMs Help Improve Server Performance
While the symmetric encryption used by AD RMS clients to encrypt and decrypt the protected content is relatively fast and efficient, asymmetric encryption and signing are much heavier processes. Modern server CPUs provide very powerful number crunching capabilities, but in AD RMS server operations, under heavy loads, the cryptographic processing might become the factor that most limits performance.
HSMs help by offloading the cryptographic processing to a dedicated hardware unit that is capable of completing the processing of cryptographic algorithms at higher speed than most current CPUs. This enables AD RMS servers to process licensing requests with reduced CPU effort.
Note
While offloading cryptographic operations to an HSM might improve performance, the network latency between the AD RMS servers and the HSM might lead to reduced performance. Whether an HSM affects performance positively or negatively will depend on the performance of your server CPU, the speed of your HSM, the network latency and speed between the HSM and the AD RMS server and which cryptographic mode your AD RMS deployment is operating under (with those who are running under cryptographic mode 2 seeing the maximum benefit).
How HSMs Help to Ensure the Security of Private Keys
In private/public cryptography the private key component is the most critical component. In AD RMS, the private key is used to decrypt all the content protection keys, effectively allowing whoever has access to that key to obtain access to all the documents protected by that AD RMS cluster. The private key also enables the AD RMS cluster to sign licenses and certificates that will be then trusted by all its clients and servers. So access to the private key would also grant the ability to issue licenses in the name of the AD RMS cluster. This all implies that the private key of the AD RMS cluster must be safeguarded and protected in order for the AD RMS service to provide meaningful protection.
With AD RMS in the default configuration, the private keys shared by AD RMS servers within an AD RMS cluster are stored securely through the Data Protection API (DPAPI) using the Secure Storage service. When AD RMS servers are joined in an AD RMS cluster, they all share a single root cluster key, which is stored in the configuration database in encrypted form so this key is never transmitted in a way that is accessible by external third parties. Because the security of your entire AD RMS deployment depends on the security of this key it is of central importance to protect this key as much as possible. Otherwise, if a user were to obtain a copy of this key they could access all content previously published and protected without authorization and to independently issue licenses that are valid AD RMS licenses under the name of the AD RMS cluster.
Therefore, HSMs can also provide a security advantage for AD RMS server deployments by isolating direct access to private keys, which in an HSM configuration are always securely issued and stored within the hardware device itself.
HSMs provide additional protection to the private keys by performing all the cryptographic operations internally without ever releasing the private key to any user or system, including the AD RMS servers. The private key is always stored inside the HSM in a form that is logically and physically protected from unauthorized access. The HSMs even provide physical protection against tampering, by using devices that will destroy the private key when detecting an attempt to physically breach the device or tamper with its built-in security protections.
Recommendations and best practices for using HSMs with AD RMS
While HSMs can provide significant additional protection as well as enhanced performance to AD RMS servers, they have some implications for the implementation and operation of an AD RMS infrastructure. In this section, we will discuss those concerns, and provide AD RMS deployment best practices for working with HSMs within your AD RMS design.
We will first look at best practices for deploying HSMs and then look at any concerns applicable to other processes such as decommissioning either an AD RMS server or an HSM device. After that, we will take a brief look at any recommendations for operational guidance, such as those best practices that apply to the ongoing management and maintenance of HSMs within your AD RMS deployment.
Implementation guidance
This section covers implementation guidance.
Deployment
When working with an HSM and clustered AD RMS servers, the following guidance applies:
While it is possible to use a local (i.e. either PCI or USB-based) HSM on each physical server within a cluster, it is generally recommended to use a network HSM with a shared key that all servers can access for ease and efficiency. The following, however, are some circumstances where PCI-based HSMs are preferable:
A network HSM requires that the network between the AD RMS servers and the network HSM is trusted and that nobody can spoof the IP address of the AD RMS servers. If this is not possible, then a PCI-based HSM card would be a better option.
If you cannot assign static IP addresses to your AD RMS servers, then a network HSM will not be able to work and a PCI-based HSM would be your only choice.
If you have high AD RMS traffic that requires many AD RMS servers, you might need multiple network-based HSMs to accommodate the load. While it is possible to use multiple network-based HSMs to service a single AD RMS deployment, there can come a point where the ease of working with and adding network-based HSMs has to be contrasted against the optimal performance that is possible if PCI cards are used.
The first server for an AD RMS cluster must be installed with the drivers for the HSM product and the cryptographic service provider (CSP) before that server is used to create the cluster.
Each additional server for an AD RMS cluster must be installed with the drivers for the HSM product, the cryptographic service provider (CSP), and a copy of the cluster’s key space identification before that server is joined to an AD RMS cluster. Managing the key space identification details can vary depending on the specifics for each HSM vendor, For example, in Thales nCipher products, this data is referred to as the “security world” for each device. In Safenet products, you clone all HSMs to the same "Domain". Refer to the documentation from your HSM vendor for more details.
For licensing-only AD RMS clusters, no special considerations are required as the process of working with HSMs is the same as it is for certification clusters. The licensor certificate itself is signed by the root cluster, but keys are generated in the same manner as is done for a certification cluster regardless of whether an HSM is involved in the process.
When using HSMs to support AD RMS in virtualized environments, the only factor to consider is that while physical AD RMS clusters spread over physical computers can share the same security world using either local or network HSMs, virtualized clusters can only use network HSMs as virtual machines do not work with local HSM devices installed in the host computer.
Configuration
In general, there are no special configuration settings that you need to apply when configuring AD RMS to work with an HSM device. In some cases, Microsoft support personnel have seen issues when customers using Thales nCipher products have selected to set up the security worlds for their HSM using the Operator Cards for managing a specific key setting on the HSM rather than using the Module Protection setting. If this setting is used, the HSM can prompt for the card and password during the AD RMS installation and that prompt could be suppressed. If the prompt is suppressed and the AD RMS installer does not respond, the installation might time out.
Trust
When configuring trust with AD RMS there are some differences when implementing Trusted Publishing Domains (TPDs) if an HSM is involved. A TPD is utilized to provide an AD RMS cluster with the ability to issue licenses to consume content that was protected by using another AD RMS cluster. A TPD exchange basically involves the sharing of the cluster private key, along with other supporting information such as rights policy templates.
First of all, a TPD with an HSM-based key does not actually include the cluster key, but instead references a pointer to the key in the HSM. Therefore when you export or import a TPD, you might need to export or import the HSM key separately from the source server, creating a key identification (known as a “security world” in nCipher HSMs or a "domain" in Safenet HSM products) that is equivalent to the original key so the TPD will work as expected on the target server. This has advantages in scenarios where different parties need to exchange TPDs but might want to "recall" them later if the partnership ends. By deploying the TPD with an HSM it controls to another party, taking back the HSM effectively removes access to that party to all content protected with that TPD.
Another advantage of exchanging HSM-protected TPDs is that, by decoupling the exchange of the TPD from the exchange of the private key, renewing information on rights policy templates after a TPD has been shared can be done by just re-exporting and re-importing the TPD, without exporting, storing, transporting or importing the private key, making this potentially recurrent exchange a less critical operation.
This also assumes that the cluster key can be exported in the first place from the HSM. HSM vendors, however, typically allow you to move a wrapped key between HSMs of the same type (assuming you have the right to do so).
In comparison, a trusted user domain is basically an exchange of public keys and server certificates, which do not include the private key. Therefore, the export and import of a TUD, which is normally utilized to allow users to license content from RMS clusters outside of their own forest, is done in an HSM environment in exactly the same way as in a non-HSM environment.
Decommissioning
The process for decommissioning an AD RMS server where an HSM does not differ much from decommissioning in a non-HSM environment. One additional step is that you must remove the IP address (for Thales nCipher HSMs) or the certificate (for Safenet HSMs) from all your HSMs to prevent future abuse. Also, if you are replacing an existing AD RMS cluster, the process of exporting and importing the HSM key identification settings (known as "security world" for Thales products, "domain" for Safenet products) might include additional steps such as the ones described in the previous section on trust.
Important
Be sure to erase the key identification settings (i.e. "security world" for Thales products, "Domain" for Safenet products) from any decommissioned HSMs before disposing of them and destroy (or safely archive) all administrator cards.
Operations guidance
This section covers implementation guidance for management and maintenance of HSMs to support AD RMS.
Management
The primary consideration for ensuring your HSMs are able to support your AD RMS installation well is to ensure protection of your cluster key. Refer to the documentation provided with your HSM for discussions of how to implement key protection such as by using key cards or other mechanisms as per the manufacturer recommendations.
Maintenance
As far as routine maintenance of HSMs supporting an installed AD RMS cluster, the cryptographic service provider (CSP) configuration should be backed up or documented as necessary. Also test that you have a proven backup and restore capability and a backup of your security key space (for nCipher products, this is called the "security world" which includes all settings under %nfast_kmdata%\local on each server in the cluster) and place any administrator and/or operator cards in a secure location and record their passwords).
Tip
To provide additional support for recovery of your HSM-stored keys, use k of N quorum for the administrator cards, and have two full quorums worth of administrator cards (plus spares) stored at two different secure locations.
Disaster recovery
Backing up an AD RMS cluster for disaster recovery involves backing up the AD RMS configuration database and the AD RMS cluster key.
In a software-based cluster key scenario, the AD RMS database contains the cluster key, and to recover the AD RMS cluster after a failure or outage you only need the AD RMS cluster key protection password, which you also will need to add new nodes to the cluster if the old nodes are lost or destroyed.
In an HSM-based scenario you also need to be able to restore access to the HSM. If the HSM is lost, you will need to recover it from an HSM backup, which is a process that’s highly dependent on the HSM implementation. If the HSM is functional, you need to have a copy of the keys used to unlock the key space used for your AD RMS cluster in the HSM (in nCipher HSMs it’s called a "security world"). The keys can take different forms depending on the HSM and the security options required, ranging from a password to a smartcard or multiple smartcards. So, as you can see, the process of recovering access to the HSM keys themselves is also completely dependent on the HSM implementation. But the logic is common: you always need to recover the configuration database, install and configure in the new node the cryptographic provider used to access the HSM, and then provide the data necessary to unlock access to the keys used by AD RMS. For more specific information on this process, see the documentation provided with your HSM.