Note: I have recently changed roles to become part of the Information Protection Team at Microsoft (the group responsible for building AD RMS and related technologies) where I will be acting as a Sr. Program Manager. Since the team already has a blog on AD RMS I have decided to concentrate my efforts in that blog, which you can find at http://blogs.technet.com/rms. My previous blog posts have already been moved there and in the future you should go to that blog for updates and news (quite a few of them are coming!).
You can find this particular post at http://blogs.technet.com/b/rms/archive/2012/04/16/licenses-and-certificates-and-how-ad-rms-protects-and-consumes-documents.aspx.
In my last post I described the high-level AD RMS infrastructure components. I am now going to describe how AD RMS protects documents and how it is used to consume documents.
At a high level, AD RMS works along with RMS-enabled applications to allow users to create and consume protected content. Protection works by encrypting a document, creating a policy and stamping it all together, along with a certificate identifying the author and some other information in a single file. Consumption works by using the users identity certificate and the policy stamped in the document to request from the AD RMS server a license to decrypt it and use it.
Let’s dig a little bit into what certificates and licenses are for AD RMS and how they relate to each other.
In AD RMS, every entity that interacts with the system is represented by a certificate.
Each AD RMS server cluster is represented by one certificate, the Server Licensor Certificate, or SLC, which in Windows Server 2008 AD RMS and later is a self-signed certificate. The private key corresponding to this certificate is used by the server to sign many other identity certificates used in the system, and it is also used by the clients to encrypt other materials for the server to decrypt, as will be discussed later.
Client machines themselves have a Security Processor Certificate (SPC), which identifies each machine and allows the machine to encrypt other elements stored locally in the computer.
Users are identified by two certificates. One which is utilized to identify users against the AD RMS servers, and another one which is used to identify a user that has protected a piece of content.
The first one is called the Rights Account Certificate (RAC) but might also be referred by its old name the Group Identity Certificate (GIC). When a user first authenticates against the certification URL of an AD RMS cluster, the user is issued a RAC or GIC, and then it uses this certificate for any future identification needs to the system. The RAC is also used by the server to encrypt licenses being sent to the user, and by the client to sign the other user certificate mentioned above, the CLC or Client Licensor Certificate. This one is obtained from the RMS licensing pipeline during client activation, and it is used to sign the Publishing Licenses embedded into any encrypted document.
Which brings us to the Publishing Licenses: these are also certificates but are used not for identifying a user but to express rights over a document. A Publishing License is basically a list of rights, like an Access Control List, that expresses a list of subjects (normally identified by their email addresses) and their rights (View, Edit, Print, Copy, etc.). The PL is stamped into a protected document and it is encrypted with the Server Licensor Certificate’s public key (so only the server can decrypt it) and signed with the user’s Client Licensor Certificate (so everyone can view who wrote it).
Finally, there’s one more commonly used license, also in the form of a certificate: the Use License. This is a certificate expressing the rights one user (the one requesting a license) has over one document. It also contains the encryption key used to encrypt the content of the document, but more on this later.
It must be highlighted that all these certificates and licenses are not your standard X.509 certificate. An X-509 certificate basically attests one claim about one subject, but does not have the flexibility to express complex lists of rights like AD RMS needs. That is why Microsoft chose the XrML certificate standard to express all these certificates. All AD RMS certificates and licenses are in the XrML format.
To summarize, if not to clarify, you can take a look at the following diagram, which represents the relationships between all these certificates:
Don’t worry if you didn’t understand what all these certificates and licenses mean. The main point here is that you understand that all these certificates exist and that they all depend on each other. It will all become clearer as you see how they work together.
Let’s say that you are a user who wants to protect a document with AD RMS. The first thing you have to do is to get your client bootstrapped and initialized. I’m not going to cover that process in this post, let’s just assume the client is already bootstrapped at this point, and that the user already has a RAC (Rights Account Certificate) a CLC (Client Licensor Certificate) and a copy of the Server Licensor Certificate (SLC).
The user who wants to protect a document only has to click on one button (such as a Rights Policy Template in the Office menu or the Do Not Forward option in Outlook) and the application will automatically perform a series of steps in order to get the document transformed into a protected document. The series of steps are as follows:
And that’s it. From a series of certificates, an unencrypted document and a list of rights, we have created an AD RMS protected document. See how easy it was?
It is actually slightly more complicated than that, as the client also grants Owner rights to the author, and issues itself a license to consume the document without contacting the server, but that’s just details. The important part is what was described above.
Of course we now have to consume the document. For that we have a just very slightly more complicated process, which in this case involves the server.
So assume the author sent the document to an authorized recipient via whatever means they want to use. Let’s say the protected content was an email which the author sent to the intended recipients. Again let’s assume that the recipient was previously activated and initialized in the AD RMS environment so the user already has a RAC and all the other necessary elements configured.
Now that the recipient has a copy of the protected document or email, he or she clicks on it and it opens on screen with some restrictions enforced. But before that happens, the client has to work with the server to consume the document. Let’s see what they do to get that done.
And that’s all there is to it. The authorized recipient of the document can now consume the protected document in a controlled way. Again, this is slightly simplified and we have left out all the steps to get the client activated, plus we have omitted some concepts like content pre-licensing, but the main logic is there.
So now you understand how AD RMS is used to protect and consume documents and how all the keys mentioned before take part in this process.
With this now behind us, I will devote my future posts to explain how to design solutions based on AD RMS for typical and not so typical scenarios.
Excellent article for learners like me. Thanks for sharing.
Are RMS protected messages further encrypted for transport (using RPC)?
Thank you for your article!
From me escape meaning. Why do users need is two pairs of keys, RAC and CLC. Why, instead of two pairs could not use one pair?
That's a great question.
The simplest answer is that the two certificates respond to different authorities. The RAC is issued by the Certification component of AD RMS, as it is used to identify the user to the service.
The CLC is issued by the Licensing service, and is used to identify the author to other users. Keep in mind that the two might very well be coming from different RMS clusters, such as when you protect content through an AD RMS cluster that is not in your own forest. You can also block access to a CLC by limiting rights on the Publish.asmx page, preventing users from protecting content while allowing them to use a RAC to consume it.
That said, it would have been possible to do a solution where only one certificate is used and where access to publishing content is managed differently, but the current model works very well and the fact that users get two certificates should be transparent to users.
AD RMS communicates through HTTP (not RPC), and the general best practice is to use SSL for all communications, which is the default.
But even when not using HTTPS, keep in mind that the protected content is NOT tranmitted between the clients and the server, only the keys, policies and certificates are, and those are encrypted, in addiution to SSL encryption, with the users and servers public keys, so there's no risk of information disclosure there.
Enrique Saggese, thank you for your answer.
Finally I understood why we need two pairs of keys. For myself, did anologiyu with kerberos, when using the TGT and SGT for different tasks.
Write another article which will explain the process invisible to the user!
Enrique, if we are using an HSM to store the RMS server private key, will the RMS server have to access the HSM whenever it signs something, or is the key loaded when the service started and stored in some sort of cache or lockbox?
Yes. Most HSMs don't share the keys with the host, they keep them internally and only allow access to performing cryptographic operations within the confines of the HSM.
That implies that in order to sign anything with the cluster's private key, or to decrypt something protected to that key, the HSM must be reachable. This is done a few times for each licensing operation.
This implies that, if using a network HSM, you must put the device close by the AD RMS servers, and in particular connected through a low-latency link. If putting RMS servers in multiple locations, most HSM vendors allow you to share keys between different units so you can place identically configured HSMs close by each of the cluster nodes.
Hope this helps.
Just discovered this article! Thanks Enrique, this is a really great description!
Thanks for your comment, I'm glad you found this post helpful.
Please take note that earlier this year I changed jobs to become part of the AD RMS Product Group at Microsoft, and I am now blogging along with other RMS Product Team members at blogs.technet.com/.../rms. You should find both technical articles and announcements (lots of them coming!) there.
We also have a developer-focused blog for AD RMS at http://blogs.msdn.com/b/rms/.
If there are any topics you would like to see covered in the blogs, please let us know. Thanks!
In 3rd figure, step 4: How does Server know user have right or not on the document? The users's info who have rights on the document are attached in the list of rights what created by client (step 4 in 2nd figure) or in URL (step 5 in 2nd figure)? And Server validate this info with what info of requesting user?
If you're not clear with my question, please let me know by reply this comment.
Thank you so much and wait for your answer.
The server determines the user rights from the Publishing License that was embedded into the document. That is a signed (tamper-proof) policy that says who has which rights on the document. When asking for a license, the client sends a copy of the PL and the users identity (in the form of a RAC) which the server analyzes to identify which rights correspond to the user.
Hope this answers your question.
Also, be sure to check the note at the top of this article about the new blog where much more activity is ongoing.