Defining Key Management Requirements
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
RMS uses cryptographic keys to provide content protection and rights enforcement. The cryptographic keys are the fundamental pieces of information that enable the system to work seamlessly and securely. Administrators must take care to manage these keys properly to protect against data loss, system failures, and theft.
In the default configuration, RMS stores the server key pair and its associated GUID in a table that is in the configuration database. The server key pair is encrypted by the password that you select during the provisioning process.
To help secure the server key pair and its associated GUID, back up the configuration database to storage media (such as a CD), and then place the backup media in a secure location (such as in an offsite safe). The scheduling of backups depends on both how frequently you make administrative changes and the acceptable risk level for data loss due to media degradation or other media risks. Make sure to keep track of which private key password is used with the backed up configuration database. Without the appropriate password you will not be able to restore the backup to the RMS server.
If you are using SQL Server as your database server, you can use SQL Server Enterprise Manager to directly copy the value of the encrypted private key data and GUID to a secured floppy disk or to other media. Because the private key is protected, the RMS installation must be running under the same RMS service account as the backup if you restore it from secure media to an RMS installation.
If you use either a software or hardware-based CSP (Cryptographic Service Provider) to protect the private key of the server, you must manually back up the key container and key. When you use a hardware-based CSP, the security of private keys is improved by keeping private keys in hardware and never exposing them to software. Data that needs to be decrypted or signed is passed to the hardware security module, decrypted or signed, and then passed out.
Each CSP, whether hardware or software, has specific procedures for how to back-up the key securely, if you are unfamiliar with this procedure you should refer to the CSP documentation.