Freigeben über

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

  • Artikel

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.

 

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:

image

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:

image

 

  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.

image

 

  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.

Comments

  • Anonymous
    January 01, 2003
    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!

  • Anonymous
    January 01, 2003
    @Bob N: 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.

  • Anonymous
    January 01, 2003
    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!

  • Anonymous
    January 01, 2003
    Hi Vu, 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.

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    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?

  • Anonymous
    January 01, 2003
    @Brad: 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.

  • Anonymous
    October 31, 2011
    Excellent article for learners like me. Thanks for sharing.

  • Anonymous
    February 07, 2012
    Are RMS protected messages further encrypted for transport (using RPC)?

  • Anonymous
    March 15, 2012
    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?

  • Anonymous
    September 07, 2012
    Just discovered this article! Thanks Enrique, this is a really great description!

  • Anonymous
    May 26, 2013
    Hi Enrique, 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.

  • Anonymous
    November 22, 2015
    Hi. I am currently enrolled in a course in a local community college (San Antonio College)

    Am taking a course titled "Implementing Network Dir Srvcs" which would be more along the lines of configuring advanced windows server 2012 services, as titles by the text we were not required but suggested to purchase.

    The instructor is using TestOut's "Windows Server Pro: Advanced Series"

    We had been given an essay question on AD RMS, just a little "describe certain elements" piece to show we comprehended what was not being taught by the instructor...

    One part asked: explain the difference between client license and use license.

    Testout defines client license as: "issued to a user, and identifies the user as the owner of the content."

    My question is: Is TestOut using it's own terminology? I cannot find "client license" anywhere in Technet or MSDN.

    Technet and MSDN lists Publisher License and Use License.

    Also, the entire goal of the course is stated to be preparation for MCITP 740-12,
    So I am a little confused as to why we would not be using MVA material for the course, as opposed to TestOut, which preps for their lackluster certs.