(This blog post was originally published under the personal blog of Enrique Saggese at http://blogs.technet.com/b/information_protection and has been archived here at his request.)
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.
It seems that the user's right list will be hash and signed by server's priviate key.
Too complicated and too many certificates and keys.
very usefull article Dan,thanks a lot.... 1 doubt about TUD ;could you please tell me how the recipient locate the RMS server which is in the other FOREST in a TUD environment. How the client knows that it has to contact a particular RMS server which is
located in a different forest [ as I believe the client cant open the encrypted publish license , encrypted by the author's RMS server]
Very cumbersome design.
Why don't use the RAC to sigh the PL. If so , the CLC is unuseful.
Thanks a lot.
I agree with Tony, too complicated.
I believe the last part of this paragraph is a mistake:
"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."
If "clients" had access to the private key associated with the SLC, I would assume it would be a security concern......The clients would normally use the public key of the SLC to encrypt material being sent to the server, right?
AC: good catch. The paragraph was meant to refer to thee SLC itself, with the server using the private part and the client using the public part.
Regarding the reason for the use of the CLC instead of the RAC for signing the PL you have to consider that in complex environments there may be multiple RMS clusters (e.g. two divisions of the same company), and while the RAC is issued by your own cluster
(the one in your own forest) the CLC may be issued by another RMS cluster (for example if the company wants all users across forests to use the same keys for protecting content). Thus, the certificate used to sign content must be different from the cert used
to consume content because in many cases they are issued by different environments.
Regarding the comments about it being complicated I partially agree. It is indeed very complex, but to say it is too complicated you have to assume that a) there's a design that offers the same functionality (including all the security guarantees, offline access,
offline protection and the like) with a simpler model, and b) that this complexity matters (users don't see any of it, it just works behind the scenes, and not even admins should care as all certificates are issued and managed automatically). So while the
design is complex, this is justified by the complexity of the requirements and mitigated by the fact that users and admins should not ever see any of this complexity.
For mobile devices we have created a simplified model that doesn't have RACs or CLCs, but that foregoes offline access and offline protection, which is OK in most mobile device scenarios but not for the more complex desktop scenarios.