Microsoft RMS: Standard or Stranglehold?

Posted by Sanford Bingham


pdf.pngSave a print-friendly version of this post (PDF)


“Standards allow different layers to evolve independently and therefore faster and better.”

- Sir Tim Berners-Lee, Founder and Director of the W3C


The World Wide Web is built upon standards, at every level. Because of Web standards, users can access information from multiple different browsers on a variety of platforms and operating systems, and organizations can choose from a diverse set of servers and databases to host content. This arrangement has worked well for more than twenty years, encouraging innovation and competition—as long as the information being served is intended to flow freely and without restriction. However if the contents’ owners want to control access to their information through encryption and authentication, the interoperability of the Web breaks down. The means of decrypting content for secure viewing has always required a separate, proprietary viewer or plug-in, because there is no Web standard for rights management at the file level.w3cSmall.png

Opinions differ on the wisdom and feasibility of implementing DRM for consumer content on the Web (although the channeling of rights-managed content into closed platforms such as Amazon Kindle and Apple iBooks has rendered opposition somewhat futile), but the absence of a security standard in the enterprise has created a vacuum into which a private corporation (namely Microsoft) could come to dominate the creation, distribution and consumption of information from end-to-end. Imagine a scenario in which the entire document workflow of the Fortune 1000 is beholden to a single vendor for its authoring applications, user identity management, decryption keys, usage data and other private and proprietary information.

Aside from wiping out entire categories of cloud storage platforms and security vendors, a private monopoly in rights management technology would prevent its customers from choosing among workflow and server technologies, and put their data at risk of a potentially catastrophic security breach if any vulnerabilities were exploited. The vast majority of encrypted documents would be secured with a single proprietary method. Further, such a monopoly would threaten the fundamental framework of the Web, which was originally designed to enable servers and clients on different platforms, from different vendors, to speak to each other in a common language. Without a published standard for handling encrypted documents on the Web, it becomes possible, even necessary, to limit usage to a single viewer or editor—the one sold by the same vendor of the productivity suite, identity framework and encryption tools.


The Mirage of Cloud Security

How could we be at risk of a rights-management monopoly, when the cloud era has disrupted incumbent vendors and the dominant players now encourage integration via open APIs? In his blog post from 2013 “The Rise of The Cloud Stack,” Aaron Levie of Box proclaimed “From this diversity of systems, customers will get choice, and with this choice we’ll see better applications and solutions emerge. At a lower cost, and at a higher quality.” The cloud stack was supposed to free us from single-vendor “ecosystems” so we could migrate between increasingly sophisticated platforms. But as we will see, the lack of a standard document security protocol has instead resulted in a Babel-like city of secure towers that don’t speak the same language, and therefore can’t interoperate.


First, let’s look at how cloud services handle user identity management, because any workable rights management scheme depends on user identity to determine whether or not to decrypt a file. One of the keys to the evolution of the cloud stack is the availability of what Gartner Group has named Identity and Access Management as a Service (IDaaS). Using an IDaaS service, a company can create a Single Sign-On (SSO) system for a variety of different, and often interconnected, cloud applications. With a single login, a user might now update a record in Salesforce, triggering an alert in Slack, updating a spreadsheet in Google Docs and a report in Box.

From the perspective of a network administrator, it is necessary that these new workflows also be auditable and their use controlled. So the “Access Management” part of IDaaS has become an important new element of the information security toolkit. In the example above, it is also critical that the administrator be able to revoke access to all the applications in that workflow all at once. In the current environment the granularity of IDaaS is normally at the application level; i.e. the IDaaS vendor controls access to the cloud provider itself, with that cloud provider managing access internally based on the identity provided.

In some cases, the cloud vendor may implement access control at the document-level, but the identification and permissioning of documents is specific to that environment. That is, there is no mechanism exposed by IDaaS vendors by which a document exported from Google Docs and imported into Box or Dropbox can be tracked or controlled as it moves from one environment to the next. Every cloud provider that offers some form of DRM is an island, and every protected document is trapped on that island.


RMS: Bundling Security and Identity

If there is no standard for document-level security in the cloud, what about behind the firewall, in the enterprise? There are multiple competing approaches to Enterprise Document Rights Management (EDRM), including the one developed by my company, FileOpen Systems. Each is functionally a silo; there is no standard for DRM interoperation. Among the EDRM solutions, the largest (by installed base or market share) and best-known framework is Microsoft Rights Management Services (RMS). It can certainly be argued that RMS is the de facto standard for controlled distribution of MS Office documents; the question is whether it can or should be the basis of a more formal web standard.

Microsoft RMS is a framework for DRM implemented natively in the Microsoft Office suite of products and also by third parties for some PDF viewers. The RMS software was introduced in 2003, evolving from and ultimately replacing an eBook DRM system, Microsoft Reader, which was introduced in 2000 and discontinued around 2007. Today RMS is predominantly, perhaps exclusively, focused on enterprise use-cases and workflows. The functionality was originally bundled into Windows Server 2003 and remains a part of the core Windows Server product. The RMS system is also tightly integrated with Microsoft's Active Directory product, indeed is formally named "Active Directory Rights Management Services" (AD RMS).


The tight integration of RMS with Windows Server has impeded adoption by entities not primarily using the Microsoft stack; RMS cannot be implemented directly in environments using Linux, or other Unix derivatives, at the server. Further, the reliance upon Active Directory has reduced the utility of the system for external document distribution, insofar as the Active Directory environment of the document creator and that of the document consumer are rarely integrated. Microsoft is now addressing this concern via the federation of Active Directory networks using Azure Active Directory (Azure AD) and the cloud version of RMS (Azure RMS). These cloud-based systems for identity management and DRM are intended, among other things, to simplify the process of distributing encrypted content outside the firewall.

Microsoft has also integrated the RMS functionality into a number of clients on desktop and mobile platforms, under the banner “Office everywhere, encryption everywhere.” This initiative addresses both document security in the MS Office suites and message security in the Microsoft mail clients, via S/MIME. Viewing of RMS-protected documents on iOS can now be done in third-party viewer applications or with Azure RMS in the Microsoft Office applications for Mac, iOS and Android.

Support for PDF files in the RMS environment is implemented via partners, including Foxit, Nitro and Nuance, and in Adobe Acrobat/Reader via a plug-in from GigaTrust. RMS-encrypted PDF cannot be opened in the Microsoft Reader application, which is the default handler for PDF on Windows 8.1 and later, nor by the embedded PDF viewer in Microsoft Edge (or any other browser).


Standard or Stranglehold?

The presence of the RMS client in the primary Microsoft Office applications enables workflows in which effectively any user can distribute encrypted content to any other user, without a requirement that either install new software. No other DRM system can make that claim. And while this situation is reminiscent of Microsoft’s bundling of Internet Explorer with Windows, which was ultimately sanctioned by the US courts, the integration of Microsoft’s DRM into Microsoft’s Office applications has not been the subject of any antitrust actions. So it is likely that the bundling will continue, and continue to be an advantage for Microsoft in the enterprise, as long as Office remains the primary vehicle for document creation and collaboration.

Similarly, the bundling of RMS with Windows Server and Active Directory is not optional, as the RMS functionality depends upon proprietary logic in the Microsoft Server stack. Use of RMS with any alternative webserver is not supported. We assume that Microsoft tightly integrated the RMS client and server functionality in order to increase the security and reliability of the system rather than as a competitive strategy, but the result is indistinguishable. There is no set of APIs and no licensing framework that would permit an independent vendor to create an alternative to the Microsoft implementation of RMS in Windows Server, or a cloud service that could be used as a replacement for Azure RMS.

While the original on-premises version of RMS required use of Active Directory for identity provision, the Azure RMS product offers the option of a federated identity mechanism, meaning that other IDaaS vendors can be integrated into an RMS workflow. However, by design, all DRM interactions involving the Azure RMS client/server exchange require a token from the Azure RMS server. So while an alternative identity provider may be provisioned, there is no mechanism in either RMS or Azure RMS for that identity provider to also manage the permissions on the document. In short, the RMS client and server cannot be decoupled.


As a result of these Microsoft design choices, it is not possible for an entity that chooses not to use Microsoft Server to implement RMS inside the firewall, nor is it possible for an entity using Azure RMS to operate with full independence from Microsoft. An IDaaS vendor can provide primary identity management, but cannot independently provide access control at the document level, as this capability necessarily involves the sharing of user and client data with Microsoft.


An Alternative: Standards-Based DRM

Microsoft’s approach is fundamentally at odds with the core design of the World Wide Web, which is premised on the loose coupling of client and server functionality. It is, for example, inconceivable today that a browser vendor would attempt to require use of a particular, and proprietary, server in order to implement SSL. An entity publishing data on the World Wide Web today can exert complete control over the code used at the webserver, to the point of having the option to write that code anew in any language and run it on any hardware, provided that the result properly implements the required protocols, all of which are public.

It follows that any attempt to create a standard system for DRM on the World Wide Web would, at a minimum, need to support this degree of client/server independence. However, DRM systems are rarely designed around open interfaces, at least partly due to a tendency to think that the most secure system is one in which the developer has control over both ends of the client/server interaction. Moreover, DRM differs from standard cryptographic implementations because one side of the interaction, the client, is not necessarily a willing participant in the secrecy of the conversation, and indeed may be an adversary.

So a completely open source DRM system is likely to be impossible. What can work, as demonstrated by the implementation chosen for the W3C Encrypted Media Extensions (EME), is the combination of a compiled binary client library and an open interface to an arbitrary key management system. EME is now embedded in multiple applications and platforms, and allows content distributors to manage protected video files using one or a combination of key management and delivery systems (Google Widevine, Apple FairPlay, Microsoft PlayReady, Adobe Primetime, etc.)


The FileOpen Rights Management Layer

The original design of the FileOpen DRM software, first articulated in 1997, described the same general architecture. FileOpen rights management was explicitly designed to work with any external identity provider, and to permit the entity encrypting documents to specify all relevant metadata (e.g. document identifiers, encryption keys). In the company’s early years, the only way to implement FileOpen software was to develop a custom server to manage customer and document identities and to implement business logic governing usage. Today, commercial "PermissionServer" implementations are available in .NET and PHP, and multiple cloud services are built around the FileOpen Client and protocol, which is published.

The architecture of FileOpen rights management is such that is not tied to any particular document format or viewing application. This differs markedly from Microsoft’s approach, which developed RMS for its own Office applications and has demonstrated a clear bias toward those applications with respect to competing tools (e.g. LibreOffice) and formats (e.g. PDF). We believe that decoupling the rights management protocol from the document format and viewer vendor enables organizations to share documents securely with the broadest set of users, inside and outside the firewall. It also protects publishers and document creators from a potentially costly “lock-in” to the format vendor, who would control the keys to encrypted documents and store private data about their end-users.


Moreover, because the FileOpen software does not rely upon any particular identity provider, it can be implemented natively by any IDaaS vendor. All such implementations are independent and private, in the sense that information about users/documents/permissions is fully controlled by and visible only to that vendor. Interoperation between IDaaS implementations, or between IDaaS vendors and cloud application providers, or between different cloud application providers, is likewise possible without direct involvement of FileOpen Systems, using the published interfaces of the system.

While FileOpen rights management is not yet a standard, it was designed and continues to be developed around the principles that underlie Web standards. In fact, one of the first and largest sectors to standardize on the FileOpen software is the community of Standards Developing Organizations (SDOs; e.g. ANSI, ASME, Afnor, DIN, etc.). Ultimately, the FileOpen software was designed not to be an end-to-end secure publishing system, or even a complete system for DRM, but a flexible component that can be integrated to extend the functionality of such systems--one thread in a larger, interconnected, Web.


Learn more about FileOpen rights management architecture and implementation options for Microsoft Office documents

Contact us for a demo of FileOpen Rights Management for Office



Topics: document control, drm, Rights Management, cloud, Microsoft RMS

Four Reasons to Use FileOpen to Protect Files in the Cloud

Posted by FileOpen DRM News

As businesses move to the cloud for their document storage and sharing needs, the need for stronger and more persistent security at the file level has gained urgency. However, the dominant cloud providers still do not offer  enterprise-grade security and rights management solutions, even to their "business" customers. 

FileOpen aims to fill that gap by providing responsive document control, policy enforcement and tracking regardless of where the actual files are stored, including the cloud. We've also made it easier to use cloud services such as Dropbox as a secure document delivery platform, by automatically encrypting the contents of designated folders and seamlessly authenticating user access. 




1. Persistent Security
    • Local AES-256 bit file encryption – no need to upload source files.
    • Expire documents by date, time or usage.
    • Revoke or kill access to specific documents as needed.
    • Disable or restrict copying/pasting, saving, editing and screen captures.
    • Display user identifying watermarks on every view and/or print.
    • Restrict document access to a specified count of devices by user.
2. Uncompromised User Experience
    • View protected documents in native applications such as Adobe Reader/Acrobat, Word, Excel, and PowerPoint, or in any browser that supports Flash version 11+ or HTML5
    • No cumbersome downloads or passwords to remember--authorized users may not even realize the file is protected
3. In-depth Analytics
    • Obtain a complete audit trail of document usage by user including, IP address, device type, time stamp, and more.
    • Understand your audience with page-level engagement and print metrics.
    • Review IP address and machine context of failed authentication requests to better understand unauthorized sharing patterns.
4. Built for Business
    • Plugs directly into your existing file sharing solutions so you can share files with a simple web link; Google Drive, DropBox, Box, ShareFile, Egnyte, Hightail, OneDrive, etc.
    • Integrate into existing authentication schemas such as Active Directory, SSO, SAML, etc.
    • Seamlessly integrate into virtually any other third-party system or database; including, eCommerce systems, intranets, LMS/CMS, SharePoint, and more. 

While many vendors are moving to capitalize on the growing need for secure file sharing with yet another 'better' cloud sync and share system, FileOpen’s approach has always been to focus on the document security, not the device nor the means of distribution. By securing the file itself, but storing permissions separately, FileOpen can offer truly portable file security regardless of the endpoint. 


Contact us to see how you can share files securely without changing your current technology investments, corporate culture or workflows.

Topics: secure file sharing, document security, cloud

Document Control Post-"Aurora": Don't keep it all in the Cloud

Posted by Sanford Bingham

Google's recent disclosure that its servers were breached, along with those of 34 other big-name companies including Adobe Systems, raises some important questions about security in general and the risks of hosted data services, or "cloud computing", in particular.Aurora: Danger

In an intriguing technical twist, the "Aurora" attacks (given that name by McAfee  from a fragment found in the executable), were initiated by taking control of the PCs of unsuspecting employees, apparently through "spear phishing" emails sent to specific users. When the users clicked links in the messages their machines were infiltrated and then remote-controlled to further penetrate the internal networks of the target companies.

PDF and Aurora: Setting the Record Straight 

Some early reports suggested that the infected links were PDF files, and that a vulnerability in Adobe Acrobat/Reader was the entry point for the attack. This theory has since been debunked, and the actual vector identified as a previously unknown JavaScript-execution flaw in Internet Explorer (Security Advisory 979352).

Adobe patched the Acrobat/Reader JavaScript flaw (APSA09-07) on January 12, 2010, in versions 8.2 and 9.3. However, the Adobe patch was released a week after the Aurora attack, so doesn't settle the break-in whodunit one way or the other. (The patch does, however, allow up-to-date Adobe Acrobat/Reader installations to re-enable Javascript execution and/or to avoid having to implement a blacklist framework for filtering malicious code.) Incidentally, disabling JavaScript has no impact on the operation of the FileOpen software, which loads into the Adobe viewer via the C/C++ interface, i.e. at a lower level of the Acrobat API. 

Risks of Comingling Data

Regardless of whose vulnerability was exploited to gain the beachhead, the fact remains that the attackers penetrated the internal networks of Google and dozens of other name-brand software and internet companies, set up encrypted channels for the extraction of data, and operated for a period of days or weeks before being expelled. The attackers may have stolen or modified source code from any of the targeted companies (Google's  announcement refers to "the theft of intellectual property from Google", though Adobe's announcement suggests that nothing of value was taken), and in doing so have probably paved the way for even more sophisticated intrusions down the road.

Despite the fact that most of the networks penetrated by the Aurora hack were private corporate environments, not public hosting providers, the event has sparked wide-ranging debate about the risks of storing critical data on servers "in the cloud". At least one commentary from a widely-respected author calls the breach so damaging that henceforth "none of our stuff on Google's servers is safe."

If indeed the attackers were able to extract or modify Google's source code - not just for GMail, presumably, but also the various applications providing hosted document authoring, management and storage, etc. - then the amount of data at risk is vast, and there may indeed be reason to think twice before storing important corporate data in that hosted environment, if not hosted environments in general.  

This is not meant to suggest that other companies can better defend themselves from attack than can Google, with all of its resources and security expertise, only that the centralized storage of any valuable good creates incentive for theft. In a physical world it is possible to scale security proportionally to the value of the goods - castles, Fort Knox, missile silos - but doing the same for data is much harder. Data security at a major enterprise like Google comes to resemble airport security, an imperfect struggle to avoid the worst outcome. In hosted computing, like air traffic, scale creates risk: because Google aggregates so much usage, a breach of Google's security (or Facebook's, etc.) is potentially an attack on the data of thousands of companies and millions of users.

In the next post, we'll discuss how FileOpen's document security software was designed from the start to avoid the aggregation of documents, user data and decryption keys all in one place.

Sanford Bingham   President   FileOpen Systems Inc.


Topics: document control, FileOpen, drm, adobe, aurora, china, google, cloud