Licenses and Certificates, and how AD RMS protects and consumes documents

First published on CloudBlogs on Apr, 16 2012

(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.

AD RMS Certificates and Licenses

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.

How AD RMS protects and consumes documents

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:

1. The client creates a random symmetric encryption key (128 bits as of this writing). Let’s call that the Content Key.
2. The client takes the body of the document it wants to protect and encrypts it with the Content Key by using the AES protocol. It ends up with an encrypted object with is an AES-128 encrypted version of the original document, and it still has the Content Key used to encrypt it.
3. The client has a local copy of the Server Licensor Certificate with its public key. It uses this public key to encrypt the Content Key. Which means that this encrypted Content Key will only be readable by the server whose SLC was used.
4. The client then creates a list of rights expressing who can do what on the document. This list depends on the action the user performed to protect the document. For example if the user clicked on the Do Not Forward button in Outlook, the list will include all the intended recipients of the email, and for each the rights will include View but not Copy or Print. The logic is slightly different if the document is protected with a Rights Policy Template as the list of rights will be replaced with a reference to a predefined list in the server, but the process is more or less the same.
5. After creating a list of rights, the client will take this list and express it in XrML. Then the client takes the encrypted Content Key (encrypted with the SLC), the public part of its own CLC and the list of rights created before, encrypts them with the Server Licensor Certificate's public key along with some other information (such as the URL of the Licensing URL that should be used to acquire a license to consume the document) and builds what we call the Publishing License with them. This PL is then encrypted with the Server Licensor Certificate's public key, so only the server will be able to decrypt it. The client also takes the private key from the user’s Client Licensor Certificate and signs the encrypted object.
6. Finally,all this is embedded to the original content encrypted with the Content Key to create a protected document. The content key is also stored encrypted with the CLCs public key, so the author can also decrypt the content without having to acquire a license.

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.

1. It all starts with the client taking the encrypted document and extracting the signed and encrypted publishing license, the encrypted content key and the author’s CLC and sending it to the server indicated in the document as part of a request for a Use License. Notice how the content of the document is NOT sent to the server, even in encrypted form.
2. As part of the request for a license the client also sends to the server the public part of its own RAC, the user’s identifier.
3. We mentioned before that the author had encrypted the document with a symmetric content key, and that it encrypted that content key with the server’s SLC public key. Since the server has the private part corresponding to that SLC, the server can use that to decrypt the encrypted content key and obtain the original, unencrypted version of the content key. This content key is good to decrypt the body of the encrypted document, but since the server does not have the body of the document, nor it cares about it, that’s not where it all ends.
4. The server then extracts the Publishing License from the client’s request and evaluates it against the requesting user’s identity. If the server decides that the user doesn’t have rights to the document, then it declines the request at this point. If the user does indeed have rights to consume this document, then the server proceeds with the next step.
5. After determining that the user does have rights to the document, the server takes the information from the Publishing License (the list of rights) to create a specific list of the rights the requesting user has on the document. The list will look like “user X has Read rights”. The server also takes the decrypted content key and encrypts it with the users RAC public key. The requesting user will now be the only one that will be able to decrypt this content key. The server takes these two things together (the re-encrypted content key and the list of rights for the user) and uses them to build a use license, which is sent to the user as a response to the users request.
6. At the client, the encrypted content key is extracted from the Use License and decrypted by using the users RAC private key. It must be noted that the user never sees the decrypted content key, and it is only the client application, under the protected environment of the RMS Client’s lockbox, that ever gets a copy of the key.
7. The client application, with the decrypted content key decrypts the body of the document and uses the rights information from the use license to display the document on the user’s screen while enforcing restrictions according to the policy that has been defined.

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.