Hi folks,
Although this blog normally features content updates and product announcements from the members who work with me within the Information Protection team here at Microsoft, we do occasionally have the opportunity to feature guest bloggers from AD RMS community whose expertise we think you will really enjoy and benefit from hearing.
In this case, I'm pleased to offer you Part 1 of 2 in the story on AD RMS client bootstrapping that Alexey Goldbergs of Crypto-Pro will be be presenting on our team blog. It gives a lot of great insight to what is happening at a deeper level at the AD RMS client as users access rights-protected content. (Update: if you are looking for Part 2, it's out now here at <a title=" AD RMS under the hood: Client bootstrapping (Part 2 of 2) " href="http://blogs.technet.com/b/rms/archive/2012/08/10/ad-rms-under-the-hood-client-bootstrapping.aspx">A... RMS under the hood: Client bootstrapping (Part 2 of 2) .
Though we like to pride ourselves on making AD RMS something you shouldn't have to know all the "under the hood" workings of to make great use of it, for those who enjoy knowing more of that sort of thing, Alexey can and will provide you all the intimate technical details.
Enjoy!
- Dan
Hello, Alexey here again. Today I want to start the deep diving into client bootstrapping.
Client bootstrapping occurs the first time each AD RMS user tries to protect or consume protected content (such as documents or messages) on an AD RMS client computer or device and includes three consecutive steps:
- Security Processor Certificate (SPC) creation also known as “machine activation”.
- Acquisition of a Rights Account Certificate (RAC) also known by its old name, the Group Identity Certificate (GIC).
- Client Licensor Certificate (CLC) acquisition.
Since I prefer short blog posts (sorry, Enrique J), I will describe only the first step today: machine activation. During machine activation, the AD RMS client creates an SPC and a corresponding private key. This identifies the lockbox on the AD RMS client computer or device that is correlated with the logged-on user’s profile.
As with server bootstrapping , client machine activation in AD RMS is different than in Windows RMS (v. 1.0). In Windows RMS, the client machine was connected via the Windows RMS server to an Internet activation service hosted by Microsoft. This activation service generated a unique lockbox containing private key and machine certificate, which allowed the client machine to use Windows RMS. This behavior was changed in Windows RMS Service Pack 1 (SP1). The following figure shows how it looks in AD RMS:
- The AD RMS Client generates a 1024-bit RSA public/private key pair using the client lockbox (%WinDir%System32secproc.dll). The key length and crypto algorithm are part of the AD RMS client software, so you cannot change them.
- The client encrypts the private key using the user’s password and DPAPI .
- The resulting blob is secured through RSAVault and stored in the registry.
- The client creates an SPC that includes the public key it just created, tied to hardware ID. The SPC is unique for each AD RMS user that logs on to the client computer.
- The client signs the SPC with its private key, so the SPC is a self-signed certificate of the AD RMS client.
- Finally, the AD RMS client writes the results to a file (CERT-Machine.drm) in the %LocalAppData%MicrosoftDRM folder. To ensure that the private key is kept private, the CERT-Machine.drm file (that will be shared in a future step) does not contain the AD RMS client computer’s private key.
Another difference between Windows RMS SP1 and AD RMS is that AD RMS does not require end users to have administrative privileges on their machine in order to perform the activation process.
On the next blog post I will discuss the next step: RAC/GIC acquisition.
Author:
Alexey Goldbergs, Technology Solutions Professional, Microsoft Russia
Reviewer:
Enrique Saggese, Senior Security Consultant, Security Center of Excellence