Default Encryption Settings and Behaviors for OneNote 2013 (Office 365)

Context: Encryption for Office Products

In the beginning of password protection features for Microsoft Office products, protection was poorly implemented and nearly trivial to crack. Over the years, protections were improved. In Office 2007, the state of protection improved significantly when AES became the default cipher for encrypting documents. Since then, incremental improvements have brought us to the state of Office document protection today.

Office 365 Encryption Settings and Behavior for OneNote 2013

This post will examine the default settings and behaviors for the encryption of OneNote 2013 notebook sections when OneNote has been installed as part of Office 365 Home.

Although this Microsoft TechNet post purports to discuss Office 2013 encryption settings, it is clearly out of date. It states that the default encryption algorithm in use is AES with a 128-bit key length. However, I found this to not be the case. Let's examine more closely below.

Clear-Text Sections

The following is a screenshot of the format of a clear-text OneNote section as viewed in Notepad++.

As shown in the side-by-side comparison, it is trivial to pull the content from a clear-text section of OneNote.

Password Protect a OneNote Section

If encryption is desired for a OneNote section, right-click the tab for the section, then select "Password Protect This Section..." This will open the Password Protection dialog, which will allow you to set the initial password, then change or remove that password once the section has been protected. While this is benignly called "Password Protection," the actual action that is occurring is a little more complex. The entire section is being encrypted so that is can be stored securely in the filesystem.

Default Encryption Settings for OneNote 2013

As is clearly shown in the screenshot below and described in the TechNet article above, OneNote 2013 is using AES as the cipher algorithm for encryption OneNote sections. However, it is also clear that the key length is set to 256 bits, which is contrary to the defaults noted in the TechNet article.

Remember that the new Office document formats are based on XML, so the snippet of settings shown in the screenshot above are actually in XML format. The full string of encryption settings for the OneNote section is here (formatted with each element split out to make it slightly more readable):

<encryption xmlns="http://schemas.microsoft.com/office/2006/encryption" xmlns:p="http://schemas.microsoft.com/office/2006/keyEncryptor/password" xmlns:c="http://schemas.microsoft.com/office/2006/keyEncryptor/certificate">

<keyData saltSize="16" blockSize="16" keyBits="256" hashSize="64" cipherAlgorithm="AES" cipherChaining="ChainingModeCBC" hashAlgorithm="SHA512" saltValue="LN7TixtxYaLw+KPpE9Fu/Q=="/> <keyEncryptors>

<keyEncryptor uri="http://schemas.microsoft.com/office/2006/keyEncryptor/password">

<p:encryptedKey spinCount="100000" saltSize="16" blockSize="16" keyBits="256" hashSize="64" cipherAlgorithm="AES" cipherChaining="ChainingModeCBC" hashAlgorithm="SHA512" saltValue="Wlbbi96Vg205rxotlDJ0yQ==" encryptedVerifierHashInput="FnwLq7c4yJnWKWSlTk9p6w==" encryptedVerifierHashValue="um/vjrbuSS0l2Adr1KS0EHL8V1DAwnOrpOG3t385ah35Fg/KdZ648F/eY6I+KwJUgv8kPwZZmJdVc8vf1DLECA==" encryptedKeyValue="AJzGS4z0YDQvnNhCH6fFIQUoPZWP3BGqY9sgiajybiQ="/>

</keyEncryptor></keyEncryptors></encryption>

There are a few items to note from this string of encryption settings:

• First, the settings being employed are AES-256 in CBC mode, using SHA-512 for any hashing operations performed during the encryption. At the time of this writing, these default cipher and hash algorithms are essentially state of the art in terms of the cryptography being commonly used in the industry. Although SHA-3 is now available, it is not commonly employed yet, and SHA-512 is a very strong hashing algorithm.
• Second, there is a right way to generate encryption keys and many wrong ways to generate encryption keys. Microsoft has appeared to create a method of properly and securely generating keys with which to encrypt documents from the Office suite. Passwords are not simply hashed once then used as a key for the cipher, which would open up the document encryption to rainbow table attacks that have pre-generated hashes for passwords. Instead, passwords are combined with a salt and hashes are iterated many times over.
• All attributes which are randomly generated or result from encryption processes, such as the saltValue and encryptedKeyValue attributes, are base64-encoded for storage. Therefore, any usage of these values must be preceded by base64 decoding.

Encryption Process for Office 2013 Documents

Office 2013 documents adhere to Microsoft's ECMA-376 Document Encryption standard.

Using the encryption settings described in the XML string, we can determine that the encryption process used for this OneNote 2013 section more specifically worked as such (slightly simplified for readability):

1. The user's password was combined with a randomly generated salt of 16 bytes.
2. This (salt + password) was hashed using the algorithm specified in the hashAlgorithm attribute of the "p:encryptedKey" element under the "keyEncrypter" element. In this case, that algorithm was SHA-512.
3. This hash is then iterated over itself according to the number of times specified in the spinCount attribute, which was 100,000. This step is performed to slow down brute force attempts to find the password.
4. The hashing process in the previous step came close to generating the user's encryption key, but that hashing process generated a 512-bit output. Therefore, the hash function's final output is truncated to match the keyBits attribute's value, measured in bits. This truncated value is the user's encryption key.
5. A random array of bytes is then created that is the size specified in the keyBits attribute of the "keyData" element. This is referred to as the intermediate key and in this case it was a 256-bit key which was generated.
6. The OneNote section is then encrypted with the cipher algorithm specified in the keyData element's cipherAlgorithm attribute, which is AES in this case. The initialization vector for this encryption process is the keyData element's saltValue and the intermediate key generated in Step 5 is used as the encryption key. All blocks in the encryption process are the size specified in the keyData elements' blockSize attribute, measured in bytes.
7. Finally, after encryption has completed, the intermediate key is stored in the p:encryptedKey element's "encryptedKeyValue" attribute. To ensure it is stored safely, the intermediate key is encrypted with the cipher specified in the p:encryptedKey element's "cipherAlgorithm" attribute. This encryption process uses the user's encryption key generated in Step 4, with the keyEncrypter elements's "saltValue" attribute as the initialization vector.

Note from the process above that the user's password is not used to directly generate the key which is responsible for encrypting the OneNote section. Instead, the user's password is used to generate an encryption key which is used to encrypt a random value generated to be used as the OneNote section's encryption key.

For the curious, the encryptedVerifierHashInput and encryptedVerifierHashValue attributes are used for verifying the user's password before starting the decryption process. The encryptedVerifierHashInput value is created by generating a random value the same size as the saltSize, then encrypting it with the user's encryption key. The hash of that decrypted random value is then encrypted with the user's encryption key. To validate the user's password before decrypting, the encryptedVerifierHashInput value is decrypted and hashed, then compared to the decrypted value of the encryptedVerifierHashValue attribute.

Finally, for the observant cryptography enthusiast, you may have noticed that I keep saying "user's encryption key" for all of these various encryption functions which have occurred (other than the intermediate key, of course). This would open up this encryption scheme to a number of attacks. For each of the encryption processes which occur to create the encryptedVerifierHashInput, encryptedVerifierHashValue, and encryptedKeyValue attributes, Microsoft actually specifies different blockKey values which must be hashed one more time with the final iteration of the spinCount hashing process. This creates unique encryption keys for each of these elements.

Now, let's examine what happens when we change the password of an encrypted section.

Password Change Behavior: Salts

As we can see in the screenshot below, a new saltValue is generated when a password has been changed, which means that the user's encryption key (used to encrypt the intermediate key) is changed as well. This prevents a number of attacks, but especially attacks where a malicious actor may have found the saltValue of the keyEncryptor in the document, then generated a large number of potential keys offline based on well-known passwords and come back to decrypt the file, only to find the saltValue had changed. This is certainly secure and proper behavior.

Additionally, salt values are changed when a section is copied, meaning that two sections do not have the same key protecting the intermediate key:

Password Change Behavior: Intermediate Keys

What is not immediately obvious in examining the encryption settings is whether or not the intermediate key is changed when the password is changed. Functionally, this does not need to occur because the user's password is used to encrypt only the intermediate key, not the document itself. Therefore, when a password is changed, OneNote can simply decrypt the intermediate key with the old password and encrypt it with the new password, then keep using it for the purpose of protecting the OneNote section.

The TechNet article states that for Excel, PowerPoint, and Word, the default is to not generate a new intermediate key when a password is changed, but it makes no mention of other Office products.

In order to determine whether or not the intermediate key is changed and the section is re-encrypted after a password change, I did a password change and compared the body sections from before and after.

Before:

After:

Those of you with excellent eye sight can see that the body cipher text is completely different, indicating that a password change does indeed cause the generation of a new intermediate key and a re-encryption of the section.

Conclusion

Microsoft has clearly improved the default encryption settings and behaviors in OneNote 2013 over previous version. OneNote 2013, at least when installed through the Office 365 Home program as I have done, by default:

• Encrypts sections with AES-256
• Uses SHA-512 for hashing operations
• Iterates the hashing of the user's password 100,000 times before using it as an encryption key
• Creates a random byte array to use as the section's actual encryption key, called the intermediate key
• Only uses the user's password to create a key to encrypt the intermediate key
• Changes salt values when the section's password is changed
• Appears to change the intermediate key and re-encrypt the section when the section's password is changed

The design of encryption in OneNote 2013 clearly exceeds common industry practices for secure cryptographic implementations.

Apple in the Enterprise: Securely Connect iOS and OS X to a Windows Server 2012 VPN

Reasons for Setting Up a VPN for Your Company

While it can sometimes be difficult to get Apple and Microsoft to integrate well in the enterprise, the consumerization of technology has driven the need to explore this space. As mobile technologies are certainly going to gain even further in popularity, it is important for workers to be able to access office resources from remote locations and have a method of protecting their communications when connected to insecure Wi-Fi hotspots. For these reasons and many more, it is imperative that even small businesses have some sort of VPN technology that works across the range of devices used throughout their business.

Many VPN solutions exist, but for those companies that cannot afford a high-end Cisco or Juniper solution, a regular Windows Server 2012 installation can be used to provide VPN access into your network. Of course, there are many considerations around secure placement of a VPN solution on your network and these considerations will be discussed in another article. For now, know that putting a VPN server on your network involves exposes some internal resources to the outside world and this should only be done cautiously. Remember to always patch your servers!

Due to the limited overlap in VPN protocol support between Microsoft and Apple, we will be using L2TP as the VPN protocol in this scenario. There are three steps to complete the setup process:

1. Configure VPN on the Windows Server 2012 system using the Routing and Remote Access service. While I will be writing "Windows Server 2012" throughout this post, the same steps will work on Windows Server 2012 R2. This post assumes that the Server 2012 system being used is part of a small Active Directory domain.
2. Forward ports on the perimeter router to the Server 2012 system.
3. Configure VPN connections on OS X and iOS devices.

Configure Windows Server 2012 and Port Forwarding

Install Necessary Server Roles for VPN

• Prerequisites:
  • Windows Server 2012 or 2012R2 system which has two NICs installed and configured with static IPs,
  • Be logged onto this system with a Domain Admin account.
• Install the "Remote Access" and "Network Policy and Access Services" roles.
  • When selecting the role services for Network Policy and Access Services, only "Network Policy Server" needs to be installed.
  • When selecting the role services for Remote Access, only "DirectAccess and VPN (RAS)" needs to be installed.

Configure VPN in Routing and Remote Access

• In Server Manager, select Remote Access, right-click your server, and open the Remote Access Management Console. In that console, click "Run the Remote Access Setup Wizard."

• Choose "Deploy VPN Only," which will bring up the Routing and Remote Access window.
• Right-click the server and choose "Configure and Enable Routing and Remote Access"

• On the "Configuration" screen of the wizard, choose the first option, "Remote access (dial-up or VPN)" and click Next.
• Select the "VPN" check box on the "Remote Access screen, then click Next.
• On the next page, "VPN Connection," you must select a network interface which will receive incoming VPN traffic from the Internet. Since we are setting up this VPN server behind a NAT router, you can select either interface as long as the traffic is forwarded to that interface from the router.
  • Also, you can uncheck the box, "Enable security on the selected interface..." because this filtering is unnecessary when the server is behind a NAT router. It is certainly more secure to have Static Filters enabled to restrict this interface to only VPN traffic, but in a small business environment where this server may be sitting in the same network segment as other servers, the Static Filters might make management unnecessarily difficult. Click Next.
• If you have a DHCP server on your network, select the "Automatically" option to use that DHCP server to assign addresses to VPN clients. Click Next.
• Choose the "No, use Routing and Remote Access to authenticate connection requests" option. This will force the VPN to use the Network Policy Server which was installed alongside the VPN role to authenticate and authorize VPN connections. Click Next, then click Finish.
  • Note: If you receive an error saying that the system could not be registered as a valid remote access server within Active Directory, you must manually add the computer object as a member of the "RAS and IAS Servers" group. Membership in this group allows servers to access the remote access properties of user objects.
• Right-click the server in the Routing and Remote Access window and select "Properties."

• On the Security tab of the Properties dialog, check the option for "Allow custom IPsec policy for L2TP/IKEv2 connection" then enter a Preshared Key. This preshared key will be used by VPN clients to authenticate the VPN server. Click OK to close the dialog and apply the settings.

Configure Users and Groups for VPN Access Authorization

Since this guide is meant for a small organization with an Active Directory domain, we can use Active Directory Users and Groups to control the authentication and authorization for VPN access. To do this, simply:

• Create a new Active Directory group, called "VPNUsers" for this example, and populate it with the users that will be able to use the VPN.
• In order for this to work, all Active Directory users must have the "Control access through NPS Network Policy" option selected on the Dial-in tab of each user's properties dialog. Fortunately, this is the default option, so no work needs to be done unless changes were made to those user attributes prior to implementing this VPN.

Configure Authentication and Authorization Policies in Network Policy Server

• Back in the Routing and Remote Access window, click the "Remote Access Logging & Policies" folder under the active server. Then, right-click and select "Launch NPS."
• Right-click Network Policies and select New.
• Name the policy "L2TP," leave the rest of the defaults on this first page, then select Next.
• On the Specify Conditions page, click Add, and select Tunnel Type. In the resulting dialog, select "Layer Two Tunneling Protocol (L2TP)" and click OK.
• Still on the Specify Conditions page, click Add, and select User Groups. In the resulting dialog, select Add Groups and add the "VPNUsers" group we created in the last section. Click Next.
• Make sure this policy is set to Grant Access to the network. Click Next.
• On the Configure Authentication Methods page, make sure the only check box selected is "Microsoft Encryption Authentication version 2 (MS-CHAP-v2)." Click Next.
• On the Configure Constraints page, set the Idle Timeout to 120. Click Next.
• On the Configure Settings page, go to the Encryption section and make sure only the check box for "Strongest encryption (MPPE 128-bit)" is selected. Click Next, then click Finish.

When NPS has been configured completely, there should be a policy with the following settings:

Forward VPN Ports to Server

In order to get this VPN working, traffic needs to be able to get to the VPN server from the Internet. To do this, configure your router to forward any UDP traffic on the following ports to your VPN server:

• 500
  
• 4500
  
• 1701
  

Setup OS X and iOS Clients to Use VPN

Configure OS X to Connect to VPN

This configuration was done on OS X 10.10. There are some older versions of OS X (at least 10.6) which implemented L2TP using non-standard network ports and, therefore, will not work with this VPN solution. However, I believe all newer versions of OS X have been implemented with standard ports. You need to be able to administer your OS X installation to set this up.

1. Open System Preferences and go to the Network panel.
   
2. On the bottom left, click "+" to add a new network connection. In the resulting dialog, change the Interface to VPN. Make sure "L2TP over IPsec" is selected as the VPN Type. Change the Service Name to a descriptive name, then click Create.
   
3. Select the new VPN connection and fill in the following settings:
   
   1. Server Address should be filled in with the IP address or FQDN of your external interface.
      
   2. Account Name should be filled in with the Active Directory username you will use to connect to the VPN. Remember that this account must be a member of the "VPNUsers" group for it to be authorized to connect.
      
4. Click "Authentication Settings..." and fill in the following settings:
   
   1. Under User Authentication, "Password" should be filled in with the Active Directory account's password.
      
   2. Under Machine Authentication, the "Shared Secret" should be setup with the Shared Secret that was defined on the Security tab of the remote access server properties dialog.
      
   3. Click OK to close the dialog.
      
5. Click "Advanced..." and make sure the "Send all traffic over VPN connection" option is selected. This will ensure that all traffic is protected by the VPN's encrypted tunnel. Click OK to close this dialog.
   
6. Click Apply.
   
7. To connect, you can click "Connect" in this page or select the option to show the VPN status in the menu bar. You can then control the VPN connection from that menu bar icon.
   

Configure iOS to Connect to VPN

This configuration was performed on iOS 8, but the configuration should work on older versions of iOS as well.

1. Open Settings.
   
2. Select VPN.
   
3. Click "Add VPN Configuration..."
   
4. Select "L2TP" at the top.
   
5. Fill in the following:
   
   1. Description: a description of the connection
      
   2. Server: the FQDN or IP address of the VPN's external interface
      
   3. Account: the name of the Active Directory account that can access the VPN
      
   4. RSA SecurID: make sure this option is unselected
      
   5. Password: password of the Active Directory account
      
   6. Secret: Shared Secret configured in the remote access server properties
      
   7. Send All Traffic: make sure this option is selected.
      
6. Click Save.
   
7. To connect, simply make sure the appropriate VPN configuration is selected, then click the button near the top of the screen.