Windows Rights Management Services SDK Security Guidelines

  • Article

 

April 2005

The information contained in this document represents the current view of Microsoft Corporation ("Microsoft") on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording or otherwise), or for any purpose, without the express written permission of Microsoft.

Microsoft may have patents, patent applications, trademarks, copyrights or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred.

© 2005 Microsoft Corporation. All rights reserved.

Microsoft, the Windows logo, Windows, Windows Media, Active Directory and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Abstract

This document describes best practices for implementation of applications using the Microsoft Windows Rights Management Services (RMS) Software Development Kit (SDK). It contains essential information that supplements the legal agreement that must be signed in order to obtain the digital certificates needed to implement applications using the RMS SDK.

Introduction

To use the RMS SDK properly, you must be familiar with practices that increase the protection of digital information at every stage of program flow. The guidelines contained in this document provide important concepts both for application developers and for information owners who buy applications designed to protect their intellectual property. The guidelines are organized by type of security threat and by standard of guideline: minimum standard; recommended; or preferred.

Threat Models and Mitigations

The RMS SDK provides a robust system for publishing and consuming protected information of all types. In order for an RMS system to be as strong as possible, RMS-enabled applications must be built using RMS best practices. While the core RMS technology released by Microsoft may be highly secure, a flaw in the implementation of a software application using the SDK can compromise the security of the RMS ecosystem. RMS-enabled applications share responsibility for maintaining the security of this ecosystem. Identifying security risks and providing mitigations for those risks introduced during application development helps to minimize the likelihood of an insecure software implementation.

Digital information owners also benefit from these security standards. Information owners need to be able to evaluate the environments in which their assets will be decrypted. A statement of minimum security standards can provide information owners with a framework for understanding and assessing the security of the applications to which they entrust their information.

Some vertical industries, such as government and health care, have certification and accreditation processes and standards that may apply to your product. Meeting these minimum security recommendations is not a substitute for the unique accreditation needs of your customers. However, the intent of the security standards is to help you prepare for current and future customer requirements, and any investment you make early in the development cycle will benefit your application. These are recommendations, not a formal Microsoft certification program.

There are several major categories of vulnerabilities in a rights management services system including:

  • Leakage   Information appears in unauthorized locations.
  • Corruption   Software or data is modified in an unauthorized manner.
  • Denial   A computing resource is not available for use.

This document focuses primarily on leakage issues. The integrity of a rights management services system depends upon its ability over time to protect information, enabling access only to designated entities. This document also touches upon corruption issues. Denial issues are not covered.

Microsoft requires minimum security standards of partners who are building RMS-enabled applications and wish to receive a signed certificate out of the production hierarchy (a production certificate). Partners attest to having met the minimum standards when they sign a legal agreement to obtain the production certificate. Microsoft does not test or review test results related to meeting the minimum standard; it is entirely up to the partner to ensure the minimum standards are met. Microsoft is introducing two additional levels of recommendations, as seen in the chart below, to help mitigate common threats.

Minimum standard An application that handles RMS-protected information must be determined to meet the minimum standard before the application can be signed with the production certificate received from Microsoft. Partners generally use the production hierarchy certificate only at the time of final release of the software when partners' own internal tests have verified that the application meets this minimum standard. Meeting the minimum standard is not, and should not be construed as, a guarantee of security by Microsoft. Microsoft does not test or review test results related to meeting the minimum standard; it is entirely up to the partner to ensure the minimum is met.
Recommended Recommended guidelines both chart a path to greater application security and provide an indication of how RMS may evolve as more security criteria are implemented. Vendors might attempt to differentiate their applications by building to this higher level of security guidelines.
Preferred This is the highest category of security currently defined. Vendors developing applications marketed as highly secure should aim for this standard. Applications that adhere to this standard are likely to be the least vulnerable to attack.

In general, these suggestions are additive—for example, meeting preferred recommendations assumes that you've met minimum standards, where applicable, unless otherwise specified.

Applications can be attacked using numerous methods. The following classes of vulnerabilities are covered in this section:

  • Theft
  • Malicious Code
  • Incorrectly Interpreting License Rights
  • Lack of required Certificate Hygiene

In addition to the classes of vulnerabilities, the following topics are also covered:

  • Recommended Software Development Practices
  • Final Considerations

Topics Not Covered in This Document

These guidelines only briefly describe the following issues, which are significant when creating both a secure development environment and a secure application:

  • Software development process management   Includes topics such as configuration management, securing source code, minimizing access to debugged code, and assigning priority to bugs. For some of your customers, having a secure software development process is of paramount importance to them. Some customers even prescribe a development process.
  • Common coding errors   Includes topics such as buffer overruns. We recommend the latest version of "Writing Secure Code" by Michael Howard and David LeBlanc (Microsoft Press, 2002) to review these generic threats and mitigations.
  • Social engineering   Includes topics such as procedural and structural safeguards against exploitation of code by developers or others within the manufacturer's organization.
  • Physical security   Includes topics such as locking down access to your code base and signing certificates.
  • Deployment or distribution of pre-release software
  • Network management   Includes topics such as intrusion-detection systems on your physical networks.

Theft

Theft in this document is defined as when a user actively attempts to acquire unprotected digital assets from information that is licensed to that user. This document does not cover techniques of stealing digital assets that are licensed to someone else.

The following attacks are covered:

  • Searching for unencrypted licensed information paged to disk
  • Intercepting unencrypted licensed information traveling across Inter-Process Communication (IPC) channels
  • Intercepting unencrypted licensed information traveling across a network interface
  • Scanning files to obtain unencrypted protected information
  • Accessing process memory space and walking the stack to obtain unencrypted information in released buffers
  • Polling buffers known to be used for decryption to obtain decrypted information

Searching for Unencrypted Licensed Information Paged to Disk

Unencrypted data in memory is susceptible to attack. Even if an application developer minimizes the exposure of a memory buffer to attack, the memory can be paged to disk, leaving it again susceptible to attack or theft. Thus, developers should be aware that page swapping is a risk to the security of protected information.

Minimum standard Application developers should try to minimize page swapping where feasible. Page swapping is allowed, but should be recognized as a risk. We do not expect developers to sacrifice performance to minimize swapping.
Recommended Any decrypted information that the application writes out to virtual memory should be protected. One way to do this would be to have the application call the VirtualProtect memory management function in the Microsoft Platform SDK to protect decrypted information being written out to virtual memory. To minimize the exposure of protected information, an application should incrementally decrypt only as much information as is needed at any given time.
Preferred An application never pages out decrypted information to swap files,

- and/or -

An application locks pages containing decrypted information buffers and zeros out buffers and halts operations on low-memory conditions,

- and/or -

An application may page out or temporarily persist information, however, if it does, it re-encrypts the information prior to doing so, and decrypts it only upon use.

Intercepting Unencrypted Licensed Information Traveling Across Inter-Process Communication (IPC) Channels

In this scenario, a malicious user seeks to intercept unencrypted licensed information as it travels through Inter-Process Communication (IPC) channels including shared files, named pipes, and so on.

Minimum standard There is absolutely no communication of unencrypted information through IPC channels outside of the application unless rights such as PRINT, EXTRACT, EXPORT, or OWNER are specified in the license. Because these rights make it clear that the information is meant to be exposed, requiring these rights makes the risk explicit. This requirement does not pertain to network communications. For more information, see "Intercepting unencrypted licensed information traveling across a network interface," later in this document.
Recommended A better solution when appropriate rights are specified by the license would be to encrypt the information traveling through IPC channels using cryptographic functions supported by the Microsoft CryptoAPI. The CryptoAPI allows developers to build cryptographic security into their applications by providing a flexible set of functions to encrypt, decrypt, or digitally sign data using industry-standard cryptography algorithms.
Preferred None at this time.

Intercepting Unencrypted Licensed Information Traveling Across a Network Interface

In this scenario, a malicious attacker intercepts protected information when it is sent through a network interface. Any network communication is a potential risk. This includes the use of IPC that spans different machines or remote procedure calls.

An example of this threat is passing information over a network channel to external systems when the PRINT, EXTRACT, EXPORT, OWNER, or equivalent right is not specified in the license for information.

Another example of this exploit is intercepting unencrypted licensed information available across a hardware interface for use by another device or PC when the PRINT, EXTRACT, EXPORT, OWNER, or equivalent right is not specified in the license. Because these rights make it clear that the information is meant to be exposed, requiring these rights makes the risk explicit.

Minimum standard An application cannot send unencrypted information over a network unless a right, such as the PRINT, EXTRACT, EXPORT, or OWNER right, is specified in the license. An exception is running the application under Terminal Server, NetMeeting, or any product with similar network-sharing functions.
Recommended The application uses the Microsoft CryptoAPI to pass unencrypted licensed information from one component (for example, an audio/visual player) to another (for example, a sound or video card).

The application fails when it detects Terminal Server. Failure may be as simple as providing a grayed-out window or disabled playback controls.
Preferred For video: Either the application or the input device manufacturer uses a strong key to protect the channel used to transmit input

- and/or -

The hardware/software implementation uses a purpose-built secure graphics processor (SGP) and graphics interface.

For audio: The application uses Microsoft Secure Audio Path (SAP), which is available in Microsoft Windows ME and Windows XP operating systems. This assumes that the application is built to run only on operating systems that enable this capability.

For document-protection software: The application does not enable Copy, Cut, or Paste unless the PRINT, EXTRACT, EXPORT, OWNER or equivalent right is present.

Scanning Files to Obtain Unencrypted Protected Information

In this scenario, a malicious attacker scans persistent storage and non-volatile memory for unprotected information. The goal is to ensure that this information can never be obtained in its unencrypted state.

Minimum standard If the application explicitly writes temporary information to persistent storage or non-volatile memory, it re-encrypts it prior to doing so, and decrypts it upon use. This also applies to the use of temporary files by the application.
Recommended In the event of a data dump upon an application crash, the application uses structured exception handling to zero out data buffers containing sensitive information.
Preferred Applications running in a standard execution environment must:

Never page out decrypted information to swap files

- and/or -

Lock pages containing decrypted information buffers, zero out the buffers, and halt operations on low-memory conditions

- and/or -

Encrypt protected information prior to paging or temporarily persisting information to disk. Decrypt only on use.

Accessing process memory space and walking the stack to obtain unencrypted information in released buffers.

Memory in the application process space and on the stack is vulnerable to theft. The levels of security assurance for mitigating this threat are as follows:

Minimum standard The application developer should minimize this exposure, to ensure as much as possible that information is not left in freed buffers, and is therefore available after use.
Recommended Decrypted information is not left in freed buffers and is therefore not available after use.

The application zeros out decrypted information buffers, and clears memory with the decrypted information before releasing it.

The application implements "just-in-time" decryption.
Preferred None at this time.

Polling Buffers Known to be Used for Decryption to Obtain Decrypted Information

Developers need to be aware that information left in buffers is vulnerable to attack. The levels of compliance for this threat are as follows:

Minimum standard None.
Recommended The application always allocates new buffers during decryption and rotates the buffers.
Preferred None at this time.

Malicious Code

In addition to basic functional requirements, this section also covers some supplementary compliance criteria to assist you in developing an application that will continue to work when it is RMS enabled.

Viruses typically attach to a file and propagate by attaching themselves to other files while they are running in memory. The RMS system requires applications, as well as the libraries, DLLs, and executables used by the application, to be listed in a manifest when the application(s) uses a lockbox.

The manifest, which is signed to ensure its authenticity, is an XrML file that lists required, optional, and prohibited files, identifying them by hash or public key (including Authenticode modules). Using a manifest allows you to specify what is loaded into the process space and is allowed to access RMS-protected information. This increases security by preventing other applications (viruses) from running in the same space as your application, or an attacker surreptitiously replacing DLLs with rogue modules, thus protecting the information that you are accessing. For more information on how to create a manifest for your application, see the RMS SDK documentation.

The following malicious code attacks are covered in this section:

  • Loading Unprotected Libraries
  • Imports via Address Tables

Loading Unprotected Libraries

An application can load external libraries in a variety of ways. However, the application loads libraries enumerated in the RMS manifest in two ways by calling:

  • DRMInitEnvironment, which occurs only once during the application execution.
  • DRMLoadLibrary, which can be called as many times as desired during program execution.

The Policy section of the manifest can specify two important items:

  • Which, if any, specific DLLs can be loaded. This is the module inclusion list
  • Which, if any, specific DLLs that are named in the manifest (by module or exclusion list) cannot be loaded
Minimum standard Where possible (generally, if your application runs independently this is possible), use the RMS APIs to load DLLs, executables and libraries.

Include your primary process in the manifest; this is a required module. This is required except when using the RMS Server Lockbox, where it is recommended.

Include any module that calls into msdrm.dll in the manifest. This is required except when using the RMS Server Lockbox, where it is recommended.
Recommended Include modules that manipulate protected information in your manifest. If your application hands off decrypted protected information to a system DLL, or places the information in a location prescribed by a system DLL, that DLL should be included in the module list section of the manifest. For DLLs signed in the system CAT file, it is sufficient to include the Microsoft CAT file signing certificates in the policy section of the manifest rather than using a specific hash for greater compatibility across system file updates.

When loading libraries, use only the RMS API DRMLoadLibrary, not the Microsoft Win32 API methods LoadLibrary or CoCreateInstance.

Specify any library that accesses information in the manifest, including any third-party plug-in called by your application.

The following recommendations help assure that bad code will not be injected into the environment where decrypted information is available:

  • When any optional module that is included in the rights management services environment is loaded after the environment is created (such as those loaded by the Microsoft Win32 API method LoadLibrary or CoCreateInstance), you should notify RMS by calling DRMLoadLibrary for that module.
  • Prior to unloading the module you've described using DRMLoadLibrary, you must notify RMS by calling DRMCloseHandle.
Preferred None at this time.

Imports via Address Tables

RMS does not support modification of any code at run time. Developers are generally proscribed from actions that would create a run-time code modification or inhibit Import Address Table checking. Modifications to import address tables are not allowed.

An import address table is created for every DLL that is loaded into your process space. This table specifies the addresses of all of the functions that your application imports. One common attack is to modify the Import Address Table (IAT) entries within an application, for example, to point to rogue code. We could take steps to prevent this by imposing some rules that apply to modules identified by the manifest and DRMLoadLibrary. The minimum standards here are also basic functional requirements; if you violate these, your application will fail because the RMS system will assume that someone is attempting to hack it.

Minimum standard You may not modify the executable's IAT in your application's process during execution.

Your RMS-enabled application (.exe and .dll files) specifies many of the functions called at run time via IATs. This specification cannot be altered at or after run time. Among other things, this means you may not be able to do code-profiling on an application signed with the production certificate.

  • For example, you may not call the DebugBreak function from within any DLL that is specified in the manifest.
  • You may not load a module with the DONT_RESOLVE_DLL_REFERENCES LoadLibrary flag. This flag tells the loader to skip binding to the imported modules with the result that the Import Address Table is modified and not recognized by our system.

You may not tamper with DelayLoad by making run-time or subsequent changes to the functions specified by the /delayload:dllname linker switch or the Delayimp.lib (that is, you may not implement your own delay-load helper function).

You may not unload modules delay-loaded by authenticated modules while the RMS environment exists. You may not use the /DELAY:UNLOAD linker switch to enable unloading of delay-loaded imports.
Recommended None at this time.
Preferred None at this time.

Incorrectly Interpreting License Rights

If your application does not correctly interpret and enforce the rights expressed in the RMS issuance license, you may make information available in ways that the information owner did not intend. An example of this is when an application allows a user to save unencrypted information to new media, when the issuance license only confers the right to view the information.

The RMS system organizes rights into four groups:

  • EDIT

    The EDIT right allows a user to create an encryptor and a decryptor; therefore, this user has permission to consume or publish information at will. The application itself must implement functionality for the rights that will actually be available for a user with the EDIT right, and provide or prohibit access in the interface for the exercise of various rights.

  • OWNER

    The OWNER right allows a user to exercise all rights in the license, whether or not they are specifically granted. It also allows the creation of both an encryptor and a decryptor. As in the case of a user with the EDIT right, the application may limit the exercise of some rights by not providing the functionality to exercise the rights.

  • VIEWRIGHTSDATA

    The RMS client allows a user granted the VIEWRIGHTSDATA right to reuse the license information. It grants the right to make a decrypting object, but it should ideally be used only for reusing the rights information from a license.

  • All other rights

    Users with any other rights can create a decryptor only if the rights are specifically defined by the application and granted in the license, and none of these rights allow the creation of an encryptor. Users with these rights are limited to the functions explicitly allowed by the various rights.

RMS APIs allow a user to either decrypt information or not; the information does not have any inherent protection. If a user has the right to decrypt information, the API permits it, and the application is responsible for managing or protecting that information once it is in the clear. An application is responsible for managing its environment and interface to prevent the unauthorized use of information; for example, disabling the Print and Copy buttons if a license only grants the PLAY right. Your test suite should verify that your application acts correctly on all the license rights that it recognizes.

The standards are as follows:

Minimum standard The customer implementation of XrML v.1.2 rights should be consistent with the definitions of these rights, as described in the XrML specifications, which are available at the XrML Web site (https://www.xrml.org/). Any rights specific to your application need to be defined for all entities with an interest in the product.

Your test suite and test process should verify that your application executes properly against the rights that the application supports, and does not act upon unsupported rights.

If you are building a publishing application, you must make information available that explains which intrinsic rights are and are not supported by the publishing application, and how these rights should be interpreted. In addition, the user interface should make clear to the end user what the implications are of each right granted or denied an individual piece of information.

Any rights that are abstracted by inclusion in new rights implemented by an application need to be mapped to the new terminology. For example, a new right called MANAGER might include as abstracted rights the PRINT, COPY, and EDIT rights.
Recommended None at this time.
Preferred None at this time.

Lack of Required Certificate Hygiene

Certificates obtained for applications that use RMS need to be used correctly, and must meet the following two conditions.

Minimum standard Never sign a debug build with a production certificate.

Debugging symbols must be off when building code to be shipped.
Recommended None at this time.
Preferred None at this time.

The threats described in the previous sections can be mitigated by vigilance during the software development process, and other practices that promote the implementation of security enhanced products for release. In addition to the conditions described in the legal agreement and the minimum technical specifications found in this document, there are a number of recommended practices that will help you anticipate threats during development, and ensure the physical security of any unique enabling technology used by your RMS-enabled application.

The following topics describe recommended development practices:

  • Creating an Application Security Threat Model
  • Recommended Certificate Hygiene
  • Deciding How Many Applications to Sign with a Production Certificate
  • Including Modules in the Application Manifest
  • Ensuring Physical Security
  • Creating a Security Incident Response Plan
  • Creating a Test Plan
  • Placing Information in Escrow

Creating an Application Security Threat Model

Microsoft recommends creating an application security threat model that describes various kinds of failures and attacks to which your application may be vulnerable. This enables developers to maintain attention to these risks at all stages of the development process. A security threat model might:

  • Document the threats described in this document as they relate to your product.
  • Gauge the probability of various risks, to help determine how much development time should be invested to mitigate each threat.
  • Determine the extent of the risk. Some incidents cause individual loss of data, while others could impact every instance of your installed software, putting all your end users and their data at risk.

Systemic failure may require revocation of services or exclusion of individual certificates or licenses from service. RMS includes the revocation and exclusion features described in the RMS SDK documentation. Refer to these sections to ensure that you are aware of all implications for the system.

Everything that is signed with the production certificate supplied by Microsoft must meet the minimum security standards described in the previous sections. Beyond the minimum level, Microsoft recommends protecting the production certificate by:

  • Storing the certificate in purpose-built secure cryptographic key storage such as the n-Cipher n-Shield Hardware Security Module (HSM).
  • Making sure that the hardware containing the certificate is not connected to an internal or external network.
  • Restricting access to the hardware, with only trusted employees able to access the restricted area.
  • Requiring the presence of at least two employees to log on to the machine containing the certificate.
  • Using Smart-Card or equivalent authentication.

Microsoft recommends distinguishing pre- and post-release builds of the product by using unique production certificates; by doing so, you can specifically revoke or exclude pre-release software from access to protected information. However, keep in mind that this may impact post-release access to pre-release protected data. Microsoft recommends signing Quality Fix Engineering (QFE) upgrades with the same certificate as the release build. It is also recommended that your application authenticate the certificate signature before installing upgrades.

Deciding How Many Applications to Sign with a Production Certificate

If you are considering signing multiple applications with a single production certificate, you must also consider the implications of using a single certificate for multiple applications. In the event of a security incident, the revocation or exclusion of certificate privileges may be necessary. If one single certificate is used to sign several applications, and then needs to be revoked, all applications signed with the certificate will be disabled. The use of a new certificate for each application will increase the granularity of revocation or exclusion events.

Microsoft will request that you provide information describing each application that you have signed with a specific certificate granted to you out of the Microsoft production certificate hierarchy.

Note   Debug builds should never be signed with the production certificate.

Including Modules in the Application Manifest

Microsoft recommends including all code modules used by RMS-enabled applications in the application manifests. Microsoft also recommends that any third party plug-in called by an application also be included in the manifest whenever feasible. If including all modules is not feasible, at least include all modules that handle rights-protected information.

Ensuring Physical Security

Network security may protect your product against intrusion from online hackers, but the machines on which information, code, and or certificates are stored can also be accessed internally, disabled, or even stolen. Structured, secure build processes, restricted physical certificate storage, and other physical security measures can protect your assets from tampering.

Creating a Security Incident Response Plan

All security systems can eventually fail. Having a security-incident response plan in place ahead of time to anticipate and deal with possible failures will greatly aid recovery. You should include a plan for completing QFE updates in the event of a security breach.

Microsoft will require a security-incident response plan prior to releasing a production certificate to the partner.

You may also want to create a service-level agreement (SLA) for your most important customers. An SLA would describe how to communicate a security breach, and how to perform the work required to execute a QFE.

Creating a Test Plan

A test plan should be created early in the development process. The scope and detail of testing should be documented and reviewed according to specifications dictated by the best practices and test cases designed by experienced quality-assurance professionals. The test plan must verify that your application meets minimum security standards as described in this document.

Minimum standard The specific build that you sign with the production certificate must be tested and demonstrate that it meets the minimum-security compliance standards described in this document, preferably prior to signing with the production certificate, and always prior to end-user distribution.
Recommended None at this time.
Preferred None at this time.

Placing Information in Escrow

Microsoft recommends placing certain information with a neutral party to ensure its continuity and availability throughout the various stages of product development. Recommended escrow information includes:

  • Application Security Threat Model
  • Documentation of scope of testing
  • Test Suite
  • Application Manifest
  • Source Code for Released Code
Minimum standard You must be able to recompile the application you release, at any time after its release. This requires that you maintain the ability to recreate the build environment for the released application.
Recommended None at this time.
Preferred None at this time.

Final Considerations

Before using the production certificate to build an application for release, partners must have made a good-faith attempt to meet the minimum standards described in this documentation. Their application must have passed the partner's own internal test cases that demonstrate meeting these criteria.