How Microsoft Information Protection (AIP) protects data

Most of these blog posts are created from questions I receive from customers and participants in my Information Protection workshops, and this is no different. There are always questions on how data is protected, what kind of encryption is used, if Microsoft can read the data and so on, so I wanted to try to clarify some of these things here. This is intended for those of you who are new to AIP and encryption, and for deep dives into cryptography there are way better sources out there.


Microsoft have some great documentations on this, but I have been told they may be a little hard to find and for some, difficult to follow. Many who are considering AIP are not security and encryption experts, but still might want to know a little bit about how this all works.

Microsoft gives this useful description of the protection part in AIP:
Azure Information Protection enables IT Administrators to protect a company's confidential files with Rights Management, which allows them to:

-          Use RSA 2048-bit keys for public key cryptography and SHA-256 for signing operations.
-          Encrypt the files to a specific set of recipients both inside and outside their organization
-          Apply specific set of rights to restrict the usability of the file
-          Decrypt content based on the user’s identity and authorization in the rights policy

But we will elaborate on this here. So, let’s get started on the technical stuff. We’ll start with the basics, which in our case means we start with a short explanation of what encryption is in this case. When we encrypt data, we use an algorithm to scramble (encrypt) data and then use a key to “unlock” the then unreadable data.

Since many people ask me about this: The information you protect is never sent to Azure as you protect it or as someone is trying to decrypt it. If you have decided to store your content in Azure, that is one thing, but in the protection (and read) process, only the keys are moving back and forth between your systems and Azure.

What kind of protection (encryption) is being used you ask?

The short answer (may be enough for many of you):


There are three cryptographic controls involved in AIP/RMS protection:
  • Algorithm: AES - Key length: 128 bits and 256 bits. AES is used for Content protection.
  • Algorithm: RSA - Key length: 2048 bits. RSA is used for protecting the Key itself.
  • SHA-256 is used for certificate signing

A little longer answer (for those of you who want to know a little more):

Info: If you are content with the short answer, feel free to jump down to the next one: How it works
As mentioned over, there are three cryptographic controls involved in AIP/RMS protection: 


Number 1: Algorithm: AES - Key length: 128 bits and 256 bits. AES is used for Content protection

    When a user protects content, a random AES key is created. This key is used to encrypt/decrypt the content by using AES symmetric encryption algorithm and the key lengths are 128 bits and 256 bits. And to answer the question you might be asking yourself right now: AES? Is it safe? Why 128-bits? Isn’t it safer with 256? And you are not alone thinking this. Since AES comes with three standard key sizes (128, 192 and 256 bits) a lot of people think that 128-bits must be weak and that is very wrong. AES 128-bit protection is actually considered logically unbreakable with any kind of technology we know of (now and in the foreseeable future). 256 bits is used by the Azure Information Protection client for generic protection and native protection when the file has a .ppdf file name extension or is a protected text or image file (such as .ptxt or .pjpg). One single AES key is generated for each document or email that is protected by Azure RMS/AIP. (The content key) This key becomes a persistent part of the protected content.

    Number 2: Algorithm: RSA - Key length: 2048 bits. RSA is used for protecting the Key itself.

    Okay, RSA 2048 bit sounds a lot more secure than AES 128 bit right? It is so much bigger. Well, this is an easy mistake to make. The two numbers here are not really comparable. It is not like RSA 2048 is 20 times more secure than AES 128. Actually RSA 2048 is often seen as being equivalent to AES 128 and in reality, as we develop more and more sophisticated computers (quantum computers) RSA 2048 will be less and less secure and must increase more and more, while AES 128 bit might never be easy to crack no matter what. 

    So, we use an AES key (mostly 128 bit) to protect our content and this key is also protected, and to do this (protect the AES key that is) we are using RSA 2048 (in most cases.)

          Number 3:   SHA-256 is used for certificate signing

    Azure Information Protection uses certificates (like the RAC (Rights Account Certificate)) and the certificate signing is protected by SHA(Secure Hash Algorithm)-256. This is not something very RMS spesific, and many of you have probably seen this in other certificates, or when you have created self signed ones etc. SHA-256 is a part of the SHA-2 family designed by the NSA. It is now considered the industry-standard signature hash algorithm for code signing certificates. SHA-256 provides stronger security and has replaced SHA-1 as the recommended algorithm.

    How it works 


    So, we should now have an understanding of the parts involved in AIP protection. A couple of keys and some certificate signing. But what happens when you protect content? What happens when someone wants to read protected content? I have tried to explain the process here, and as you can see there are quite a few steps from protecting to consuming content.

    P.Winther

    That's it for this time. There are many great sources of information about this out there, but I have tried to gather some into one blog post. Feel free to comment if this is useful for you.

    Comments

    Popular posts from this blog

    Using Do not Forward or Encrypt Only as the results of a Sensitivity Label