Hello Folks,

The RMS team is excited to share with you the General Availability (GA) versions of our Android, iOS and OS X SDK 4.0!  The new and powerful SDK 4.0 adds new features and capabilities that provide you all the control and flexibility that you need to build the most amazing apps using Microsoft Rights Management services.

 So, What’s new in SDK v4.0?

• AD RMS support – IT admins can use RMS enabled applications on mobile devices with the new AD RMS server’s mobile device extensions. 
  NOTE: If you receive an error, you haven’t registered on Microsoft Connect. To register: go to www.connect.microsoft.com, sign in with your Microsoft Account > Directory> Search for Rights Management Services > Join.
• Offline Consumption - end-users can access RMS protected data offline.
• Segregated Authentication - developers can use their own authentication library for Azure RMS and AD RMS (or use the recommended Active Directory Auth Library).
• Segregated UI - developers can build their user interface to protect and consume RMS protected documents.
• Re-designed API - developers can now enjoy simple and transparent encryption and decryption API, which provides consistent RMS behaviors and user experience, in minimum efforts.

We will also be building UI libraries for all platforms so that you can focus on your app functionality.  Download the Android UI library and sample app here https://github.com/AzureAD/rms-sdk-ui-for-android. We will update you when the UI libraries become available for more platforms

 Developer documentation with easy get-started process and sample apps for the following operating systems:

• Google Android
• Apple iOS
• Mac OS X

Windows RT and Windows Phone SDK are going to be in Preview 2 in the next few days.

 Also, here are some direct links for downloading our new SDKs:

• SDK 4.0 for Android: http://www.microsoft.com/en-ie/download/details.aspx?id=43673
• SDK 4.0 for iOS: http://www.microsoft.com/en-us/download/details.aspx?id=43674
• SDK 4.0 for OS X: http://www.microsoft.com/en-za/download/details.aspx?id=43675

For information on the Windows Client version, see our blog post on the RMS SDK 2.1.

Orientation, Support and Feedback

We are ready and able to help with your applications and implementation questions as well as eager to receive your feedback – Ask the RMS Info Protection Team. See the Community resources topic in our devices SDK for details. 

Enjoy!

Dan.

 Note: RMS SDK 4.0 supersedes RMS SDK 3.0. RMS SDK 3.0 is deprecated starting now.Going forward, please use the RMS SDK 4.0 version of Rights Management Services.

Hello Folks,

Three months ago we released to the world SDK 4.0, the most advanced SDK that we ever built in RMS team. Since then, we have seen many amazing 3rd party apps released to the stores. We were delighted to see how developers love our SDK and find it easy to work with. It only motivates us to keep improving our SDKs and to the integration with the latest features of Azure RMS and AD RMS services.

Today, The RMS team is happy to share with you the General Availability (GA) of SDK 4.1 for Android, iOS and OS X!

The updated SDK 4.1 introduces one important feature that required us to change the public API. We made sure that developers of existing apps will find it easy to integrate with SDK 4.1 very quickly, and we updated our documentation accordingly.

So, what’s new SDK 4.1?

• Accessing new (unknown) AD RMS service URLs and enabling document tracking require user confirmation. The new user consent callback API in SDK 4.1 provides the app developers a simple way to show the user consent UI in their apps, in the right context.
• iOS 8.0 and OS X 10.10 Yosemite are now supported in SDK 4.1. It is critical to update existing SDK 4.0 apps to support those platforms.
• Few bug fixes and performance improvements from SDK 4.0 which are highly recommended.

Download SDK 4.1

• SDK 4.1 for Android: http://www.microsoft.com/en-ie/download/details.aspx?id=43673
• SDK 4.1 for iOS: http://www.microsoft.com/en-us/download/details.aspx?id=43674
• SDK 4.1 for OS X: http://www.microsoft.com/en-za/download/details.aspx?id=43675

UI Library and Sample app for SDK 4.1

We have also updated our UI libraries and sample app for iOS and Android in our GitHub account, so you can get started quickly with SDK 4.1 and re-use the new built-in consent UI in your apps:

• UI Library and Sample app for Android: https://github.com/AzureAD/rms-sdk-ui-for-android
• UI Library and Sample app for iOS: https://github.com/AzureAD/rms-sdk-ui-for-ios

SDK 4.1 Documentation

Our updated Developer documentation offers an easy get-started guide and sample code for our dear developers for the following platforms:

• Google Android
• Apple iOS
• Mac OS X

Support and Feedback

We are ready and able to help with your applications and implementation questions as well as eager to receive your feedback – Ask the RMS Info Protection Team. See the Community
resources topic in our devices SDK for details. 

Enjoy!

Dan for the RMS team

Hey Folks,

Check out the great work by Will Gries in this blog post.

Here’s a brief excerpt …

File Classification Infrastructure (FCI) is a built-in feature on Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 that helps IT admins to manage their organization’s data on file servers by providing automatic classification processes. Using rules which are constructed with regular expressions, PowerShell, and/or .NET or native modules, FCI can identify sensitive files and perform actions such as encrypting Microsoft Office documents with Rights Management Services (RMS), expiring files that have passed a defined date limit, or other custom action (defined through a script/program).

A recent update has added a section about enabling the script to work with Azure RMS in addition to RMS on-prem.

Bruce Perler
on behalf of Dan Plastina and the RMS Team

Hi Everyone, 

This blog is the first step in our bringing AES256 encryption to PFILE. Kevin will fill you in on the details. A future IT focused blog will explain this offer to our customers.

Hello! My name is Kevin Dawkins. I am a developer on the RMS team. For some time now, partners and customers have been requesting that we move to AES-256 symmetric key based encryption. Starting with our next release, expected in March, we will be making AES-256 symmetric key based encryption the standard way to protect files!

Overview for IT Pros 

To ensure compatibility and the ability to consume files protected against AES256, please make sure you have updated your apps recently. The consumption functionality was added to our October 2014 released SDK, so any apps built after that date will be able to consume AES 256 protected files. If your customers are running apps built with our SDK before October 2014, this update will break their application. They will not be able to consume p-files (which includes PPDF, PTXT, and all .pfile). We have let our partners know. 

When you are ready to start protecting files with AES-256 bit encryption in your organization, please ensure that you deploy our new RMS sharing app from the upcoming release. Similarly, other ISV applications on Windows that use RMS SDK 2.1 also need to be updated to leverage the new encryption standard.

However, for all mobile RMS enabled applications using Azure RMS, production support will happen automatically when we update the Azure RMS service in the next release. As of now, mobile devices are all able to consume AES 256 protected content.

Once again, if your users haven’t updated their application to at least the version shipped in October 2014, then they will not be able to open AES-256 bit protected files created by the new applications in the coming milestones.

Office, however, is still using AES-128 bit encryption. We are working with them for updating the Office infrastructure, but we have no timeline to report yet.

Developer Details 

With this release, no additional code is required to use AES 256 based encryption assuming you build against the updated SDK. You should seriously consider updating your app with the new SDK for the additional security benefits of AES-256.

This change has prompted a redesign of how we manage and expose encryption options to programmers using our API. Starting with this release, we will expose the following three encryption packages:

• IPC_ENCRYPTION_PACKAGE_AES256_CBC4K (** Which is also the new default **)
• IPC_ENCRYPTION_PACKAGE _AES128_CBC4K
• IPC_ENCRYPTION_PACKAGE _AES128_ECB (Deprecated Algorithms*)

The encryption packages can be used in conjunction with our new License Property flag IPC_LI_PREFERRED_ENCRYPTION_PACKAGE.

One important point to note is that we will no longer be exposing the IPC_LI_DEPRECATED_ENCRYPTION_ALGORITHMS flag in our API. This means that future apps will no longer compile if they reference this flag, but apps already built will continue to work since we will honor the flag privately in the API code. Getting the benefit of the old deprecated encryption algorithms flag can still be achieved simply by changing two flags. See the sample code below.

Here is some sample code that demonstrates how to use the new license property.

Protect Files with AES 256 CBC4K:

hr = IpcCreateLicenseFromTemplateID(pcTil->aTi[0].wszID, 0, NULL, &pLicenseHandle);

// No change in code here, AES 256 CBC4K is default.

Protect Files with AES-128 CBC4K:

hr = IpcCreateLicenseFromTemplateID(pcTil->aTi[0].wszID, 0, NULL, &pLicenseHandle);

DWORD dwEncryptionMode = IPC_ENCRYPTION_PACKAGE_AES128_CBC4K;

hr = IpcSetLicenseProperty(pLicenseHandle, false, IPC_LI_PREFERRED_ENCRYPTION_PACKAGE, &dwEncryptionMode);

Protect Files with AES-128 ECB:

This sample also shows the new way of using “Deprecated Algorithms.”

hr = IpcCreateLicenseFromTemplateID(pcTil->aTi[0].wszID, 0, NULL, &pLicenseHandle);

DWORD dwEncryptionMode = IPC_ENCRYPTION_PACKAGE_AES128_ECB;

// The deprecated algorithm package

hr = IpcSetLicenseProperty(pLicenseHandle, false, IPC_LI_PREFERRED_ENCRYPTION_PACKAGE, &dwEncryptionMode);

Support for consumption of AES 256 protected files has existed since the October 2014 release. If anyone is running applications built with a version of the SDK from before October
2014, this update will break their application. Please make sure that customers of the application you are building, are either using an updated SDK, or are willing to immediately update to the most recent version of your application.

Hi Everyone,

This post is a bit overdue and, you’ll want to know about the following updates to the RMS SDK 2.1 (MSIPC). As of April, these additions have been made to the SDK. For further details see the Release Notes topic for the SDK on MSDN.

• Document tracking is now possible through a set of new APIs. For more information, see Tracking Content.
• Encryption type – We now support API level control for selection of the encryption package. For more information, see Working with encryption.
• Note – We will no longer be exposing the IPC_LI_DEPRECATED_ENCRYPTION_ALGORITHMS flag in our API. This means that future apps will no longer compile if they reference this flag, but apps already built will continue to work since we will honor the flag privately in the API code. Getting the benefit of the old deprecated encryption algorithms flag can still be achieved simply by changing a flag. For more information, see Working with encryption.
• Server Mode Applications, those using an API mode value of IPC_API_MODE_SERVER, no longer require an application manifest. You can test your application against a production RMS server and are not required to obtain a production license when switching to production environment. For more information on server mode applications, see Application types.
• Logging is now implemented through both file and Event Tracing for Windows methods.
• If you’re running on a Windows 7 SP1 machine, see the note following under “Important developer notes”.

Please let us know of any thoughts or feedback you may have through the comments section below.

Thank you,
Bruce on behalf of Dan

Hello,

We’ve heard a request for a simple code example for reading a PFILE protected PDF file so, here’s a code snippet (below) that accomplishes the basic option. In order to preserve and enforce the protected document’s rights the app will need to get the license key then check the rights of the current user before decryption the file. 

NOTE: Only use the RMS_AWARE flag only if you are going to properly enforce the rights.  

       // get the license and key

       PCWSTR wszInputFilePath = …;      // input file path

       PIPC_BUFFER pvLicense = NULL;

       IPC_KEY_HANDLE hKey = NULL;

       hr = IpcfGetSerializedLicenseFromFile(wszInputFilePath, &pvLicense);

       hr = IpcGetKey(pvLicense, 0, NULL, NULL, &hKey);

       // check access rights and proceed if the user has sufficient rigths

       BOOL fCanPrint = FALSE, fCanComment = FALSE;

       hr = IpcAccessCheck(hKey, IPC_GENERIC_PRINT, &fCanPrint);

       hr = IpcAccessCheck(hKey, IPC_GENERIC_COMMENT, &fCanComment);

       // decrypt the protected file if the user has the sufficient rights

       // if (fCanPrint & fCanComment)

         PCWSTR wszOutputDirectory = …;    // directory to output the decrypted file (e.g. temp directory)

         PCWSTR wszOutputFilePath = NULL;  // output parameter to return the path of the decrypted file

         hr = IpcfDecryptFile(wszInputFilePath, IPCF_DF_FLAG_OPEN_AS_RMS_AWARE, NULL, wszOutputDirectory, &wszOutputFilePath);

       // clean up

       IpcFreeMemory(const_cast<PWSTR>(wszOutputFilePath));

       IpcFreeMemory(pvLicense);

       IpcCloseHandle(reinterpret_cast<IPC_HANDLE>(hKey));

Bruce Perler on behalf of Dan Plastina