Office 365 Message Encryption: Protect your email against the spooks

Office 365 Message Encryption: Protect your email against the spooks

The PRISM revelations have had a huge effect on the general public and on the cloud community in particular. No one likes the idea of their private communications being intercepted and analyzed, and the fact that three-letter agencies were busily tapping into various links to capture data came as an unpleasant and unwelcome surprise—especially to companies considering cloud deployments.

As a long-time consumer of cloud services, I don’t have a problem if governments want to read my email—but then again, my data is probably less interesting and less worth intercepting than data from large companies, international bodies, and the like. This might explain the efforts of cloud service providers to reassure customers and potential clients that it’s safe to hand over control of data—which is where we come to the new Office 365 Message Encryption feature, a replacement of the older Exchange Hosted Encryption (EHE) service, announced by Microsoft on November 21, 2013. The new service will be available for purchase in the first quarter of 2014, and customers who use EHE will be upgraded to use Office 365 Message Encryption at around the same time.

Office 365 Message Encryption is included in the Windows Azure Rights Management suite (RMS), so it’s free if you subscribe to Office 365 plans E3 or E4. Rights Management is available as an add-on for other Office 365 plans and costs $2 per user per month (in the United States). Azure RMS also works in a hybrid Exchange environment if messages from the on-premises mailboxes pass through Exchange Online Protection (EOP).

How Office 365 Message Encryption Works

The new Message Encryption feature works by intercepting messages as they pass through the transport pipeline and encrypting all messages that meet whatever criteria the administrator sets. Users don’t have the option to encrypt selected messages—the determination is made through transport rules, so you have to come up with a set of criteria to identify outbound messages that need to be protected. For example, all messages that have “Confidential Data” in their subject line, messages sent to a particular domain, or even messages sent to a particular user would be encrypted. Different transport rules can be created to handle different circumstances, all of which result in encrypted outbound messages.

Office 365 Message Encryption extends the “modify the message security” predicate to add the “Apply Office 365 Message Encryption” action; “Remove Office 365 Message Encryption” is also a supported action. Applying encryption is one of many actions that can be invoked by transport rules, so it can be mixed with all manner of other rule conditions and actions to perform whatever processing is required. Because encryption is incorporated into transport rules, it’s guaranteed that no message will be dispatched before it is evaluated and, if it meets the criteria set for a rule that requires encryption, it’s also guaranteed that each message is protected before dispatch.

Messages are 2048-bit encrypted using SHA-256 with the private key of the Office 365 tenant domain. Recipients have no knowledge of this key, so when they receive a message, they’ll see that it contains an encrypted attachment and instructions for viewing the content. Because all the email system has to do is transport and deliver the encrypted attachment, you can expect the solution to work for messages sent to all other major commercial and consumer email systems.

Clicking the attachment opens a browser window connected to a page on the Office 365 Message Encryption portal. Companies can customize this page with a logo and some directive text to tell end users what to do. The user will then authenticate using a Windows Live or Office 365 ID before the content is decrypted and presented in an Outlook Web App–like interface. Any reply sent back to the originator is automatically encrypted.

Deploying Office 365 Message Encryption

Overall, I like Microsoft’s approach in designing Office 365 Message Encryption. Microsoft leveraged some of its assets from Windows Azure RMS, transport rules, and OWA to assemble a solution that protects confidential messages against anyone who penetrates a mailbox or intercepts email en route. Making Office 365 Message Encryption an administrator-driven process means that users don’t get to vote whether their messages are encrypted. It also means that you avoid the key issuance and maintenance that user-centric message encryption involves, something that often works great for small groups of users but rapidly becomes a royal pain when rolled out into general use.

Despite the positive vibes, I wouldn’t rush to deploy Office 365 Message Encryption, at least not without doing some thinking first. Some work has to be done to figure out how to identify confidential messages to transport rules and then how to integrate encryption into the transport rule pipeline so that it doesn’t interfere with any other rules processing such as those that implement data loss prevention. You then have to consider user education and figure out what needs to be done to advise external correspondents on how to handle the encrypted messages they will now receive from your company. It’s also important to realize that this implementation, in terms of accessing the encrypted message content, is strictly browser-based for now and that there’s no offline client support.

More Knowledge Is Key

Like any new feature, an imperfect state of knowledge exists regarding operational issues, such as gaining access to important encrypted messages received by people who leave the company. It’s also important to consider how the use of Office 365 Message Encryption affects your Plan B—your back-out plan in case cloud services don’t work for your company. The answer here seems emphatic: If you give up your Office 365 tenant, you give up the Rights Management private key, and any messages encrypted using this key become inaccessible.

Follow Tony @12Knocksinna

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.