Behind the Scenes with RMS

Authoring Rights-protected Content
Most users protect content offline, but you can use RMS to protect content online as well. The RMS Licensing Server protects content online, and the author's Client Licensor Certificate (CLC) is used to protect content offline. Offline protection is useful when you want to author rights-protected content and you're disconnected from a corporate network (e.g., when you're on an airplane or in a coffee shop). Office 2003 applications always protect content offline with a CLC. The first time a user uses RMS to protect content, an RMS-aware application requests a CLC from the configured RMS Licensing Server for the user if the application doesn't detect a valid CLC on the RMS Client. The RMS Client stores the CLC in the user's machine-local profile.

Content that is protected online or offline will be assigned an associated Publish License (PL), which contains the rights granted by the author to users. RMS uses encryption to protect content. The content and the portion of the PL that defines the rights assigned to the content and which users have rights to the content is encrypted. Without encryption, applications that are not RMS-aware and don't enforce rights (such as Microsoft Notepad) could access protected content.

Consuming Rights-protected Content
Before a consuming user can access Rights-protected content, the RMS-aware application sends a request through the consuming user's RMS Client to the RMS Licensing Server that originally protected the content (or issued the CLC to the author for the content protected offline) to obtain an End-User License (EUL). The RMS Client sends the consuming user's RAC and the content's PL in the EUL request. The RMS Licensing Server verifies that the consuming user named in the RAC is named in the PL, or is a member of a group named in the PL. If the consuming user is named, or is a member of a named group, the server issues an EUL which grants access rights to the consuming user.

When an RMS-aware application detects that a user needs a new certificate or license, or is required to renew one, it works with the RMS Client to obtain the certificate or license automatically for the user. This means that users can safely send Rights-protected content to a recipient without worrying if they haven't used RMS before.

Enforcing Protections in RMS
Only RMS-aware applications can open rights-protected content. RMS-aware applications are responsible for enforcing the rights granted to users by content authors. As a result, developers must include code in RMS-aware applications to use the RMS Client API, and for protecting data at all times. For example, if an application uses a temporary file to format a document before sending it to a printer, the application must make sure that the temporary file is encrypted to prevent the user or a hacker from accessing it to circumvent the protections RMS affords. However, relying on applications to enforce the rights granted to a user poses a problem: How do you trust an application? What is to prevent a hacker from writing an application that uses the RMS Client API to access rights-protected content and then not enforce the rights, allowing the hacker to access content without restrictions? The answer lies in the RMS Client.

Before an RMS-aware application can access content, the RMS Client checks the application's manifest. Every RMS-aware application ships with a manifest (an XML-style file) that lists the components of the application, including each DLL and executable (EXE) file. Application developers request a manifest-signing certificate from Microsoft. The application developer uses the certificate to sign the manifest. The RMS Client checks the signature to make sure the application manifest is valid and also checks the running process to make sure that each DLL and EXE file hasn't been tampered with, and that a rogue DLL hasn't been injected into the process. If the process doesn't conform to the manifest, the RMS Client returns an error and denies access to rights-protected content. In the event that a vendor ships an application that contains a vulnerability that can be exploited to strip protection from rights-protected content, the RMS Administrator can exclude the application by naming it and its version number(s) on RMS Licensing Servers. Excluded applications are written to the EUL, which the RMS Client checks. Applications themselves can exclude earlier versions of themselves when they generate a PL, and these exclusions are copied to the EUL. The RMS Client checks the exclusion list in the EUL against the application manifest, and if there is a match, the RMS Client prevents the RMS-aware application from accessing the content. For more information about enforcing central policy governing document right-protecting, see the Web-exclusive sidebar "Implementing Policy Through Templates," http://www.windowsitpro.com, InstantDoc ID 49005.

Storing EULs
EULs for content authored with Microsoft Office applications are valid for 7 years by default. Microsoft Office applications store EULs within the rights-protected content. As long as a user has a valid EUL, he or she can access the same content continuously online or offline. To store an EUL in protected content the author must have write permission to the binary file on a disk drive. Because rights are application-specific, write access to a file doesn't necessarily confer write or edit access to rights-protected content stored in the file. Due to an RMS quirk, if a user is denied write access to a file through the NTFS DACL, the RMS Client discards the user's EUL, and the user will have to access content online and obtain a new EUL every time he or she wants to access the content. However, if the FAT-style read-only attribute bit is set, the RMS Client stores the EUL in the user's machine-local profile (%USERPROFILE%\LocalSettings\ApplicationData\Microsoft\DRM), and the RMS Client can reuse the EUL. Microsoft Outlook 2003 always stores EULs for rights-protected email access in the user's machine-local profile. If several users have binary-write access to a rights-protected file (e.g., a file stored on a shared folder) and each user accesses it, the file will grow substantially in size as the EUL for each user is stored in the file.