Security Overview of Microsoft Rights Management Services (RMS)

Transcription

1 Security Overview of Microsoft Rights Management Services (RMS) J. Donnelly The scientific or technical validity of this Contract Report is entirely the responsibility of the contractor and the contents do not necessarily have the approval or endorsement of Defence R&D Canada. Defence R&D Canada -- Ottawa CONTRACT REPORT DRDC Ottawa CR April 2006

2

3 Security Overview of Microsoft Rights Management Services (RMS) J. Donnelly Titus International Prepared by: Titus International 200G-356 Woodroffe Ave. Ottawa ON K2A 3V6 Contract number: W Contract Scientific Authority: R. Sawilla, DRDC Ottawa, (613) The scientific or technical validity of this Contract Report is entirely the responsibility of the contractor and the contents do not necessarily have the approval or endorsement of Defence R&D Canada. Defence R&D Canada Ottawa Contract Report DRDC Ottawa CR April 2006

4 Her Majesty the Queen as represented by the Minister of National Defence, 2006 Sa majesté la reine, représentée par le ministre de la Défense nationale, 2006

5 Abstract The Microsoft Windows Rights Management Services (RMS) is concerned with the protection and proper handling of electronic information, potentially with differing handling restrictions and requirements for protection, with enforcement of those protections and handling restrictions across multiple domains. An RMS system allows originators to properly classify, tag and assign rights to information when it is created and change those rights even after the information is distributed. These rights are called usage rights and include restrictions such as whether or not the information can be printed, copied or shared. This report discusses RMS in the context of Defence Research and Development Canada (DRDC). The most important conclusions presented in this report include: a) A robust RMS solution will help to establish a more reliable information management capability as compared to what is available today. b) RMS can apply to a plethora of information with different protection requirements. c) Using existing Entrust certificates as the sole authentication requirement for RMS is not possible at this time. d) The RMS technology is still evolving, and therefore subject to change. DRDC Ottawa CR i

6 Résumé Le Système de gestion des droits (RMS) de Microsoft permet la protection et la manipulation appropriées de l information électronique, en fonction notamment de différentes restrictions à la manipulation et de différents critères de protection. En outre, il permet d appliquer ces mécanismes de protection et de restriction à l ensemble des domaines. Un système de gestion des droits permet aux créateurs de classifier, de marquer et d attribuer des droits à l information au moment de sa création et de modifier ces droits même après diffusion. Il s'agit plus précisément de droits d utilisation qui comprennent des restrictions en vertu desquelles l'information peut ou non être imprimée, copiée ou partagée. Le présent rapport traite de RMS dans le contexte de Recherche et développement pour la défense Canada (RDDC). Le rapport contient notamment les conclusions suivantes, parmi les plus importantes : a) Une solution robuste de gestion des droits (RMS) contribuera à l instauration d une capacité de gestion de l information plus fiable que les mécanismes actuellement disponibles; b) Le RMS peut être appliqué à une multitude d'informations et à autant de besoins différents en matière de protection; c) À l heure actuelle, il n est pas possible d utiliser exclusivement les certificats Entrust existants comme critère d authentification pour la gestion des droits. d) La technologie RMS est continuellement perfectionnée et elle risque donc d'être encore modifiée. ii DRDC Ottawa CR

7 Executive Summary Security Overview of Microsoft Rights Management Services (RMS) J. Donnelly; DRDC Ottawa CR ; Defence R&D Canada Ottawa; April The Microsoft Windows Rights Management Services (RMS) is concerned with the protection and proper handling of electronic information, potentially with differing handling restrictions and requirements for protection, with enforcement of those protections and handling restrictions across multiple domains. An RMS system allows originators to properly classify, tag and assign rights to information when it is created and change those rights even after the information is distributed. Rights include who can access the information as well as what they can do with it once it s opened. These rights are called usage rights and include restrictions such as whether or not the information can be printed, copied or shared. This report discusses RMS in the context of Defence Research and Development Canada (DRDC). This includes: a. An overview of RMS b. The components of an RMS infrastructure c. Details regarding how RMS works The material presented within this report was derived from a variety of sources, including the technical training course Deploying Windows Rights Management Services [Reference 1], the Communications Security Establishment (CSE) Information Rights Management (IRM) Report [Reference 2], the RMS help files [Reference 3], the RMS Software Developer Kit (SDK) [Reference 4] and analysis of the current RMS technology. The most important conclusions presented in this report include: a. A robust RMS solution will help to establish a more reliable information management capability as compared to what is available today. Specifically, today s traditional procedural controls are subject to a variety of weaknesses including both unintentional human error and even malicious behaviour. The policies enforced by RMS can substantially improve the controls on information management. b. RMS can apply to a plethora of information with different protection requirements. This is especially relevant in the context of DRDC, given the various sensitivity levels and differing business requirements for handling sensitive information within the Department of National Defence. DRDC Ottawa CR iii

8 c. While RMS can work with the existing Entrust Public Key Infrastructure (PKI), and as services running under Microsoft Internet Information Services (IIS), RMS can be configured to require client certificates such as those issued by Entrust, the RMS servers issue and require the use of their own certificates for user authentication as well. Using existing Entrust certificates as the sole authentication requirement for RMS is not possible at this time. d. The RMS technology is still evolving, and therefore subject to change. Although this report provides a current snapshot, it is emphasized that this is likely to change over time. In addition, this report makes several recommendations as follows: a. DRDC needs to actively monitor, investigate and, where appropriate, influence emerging RMS technologies; b. Detailed business and functional requirements associated with RMS within DRDC need to be developed; c. A DRDC RMS Concept of Operations (CONOP) needs to be developed; and d. DRDC should establish a test environment where RMS products can be analyzed and assessed. iv DRDC Ottawa CR

9 Sommaire Security Overview of Microsoft Rights Management Services (RMS) J. Donnelly; RDDC Ottawa CR ; R & D pour la défense Canada Ottawa; avril Le Système de gestion des droits (RMS) de Microsoft permet la protection et la manipulation appropriées de l information électronique, en fonction notamment de différentes restrictions à la manipulation et de différents critères de protection. En outre, il permet d appliquer ces mécanismes de protection et de restriction dans l ensemble des domaines. Un système de gestion des droits permet aux créateurs de classifier, de marquer et d attribuer des droits à l information au moment de sa création et de modifier ces droits même après diffusion. Les droits permettent de déterminer quels utilisateurs peuvent avoir accès à l'information, de même que ce qu'ils peuvent en faire par la suite. Il s'agit plus précisément de droits d utilisation qui comprennent des restrictions en vertu desquelles l'information peut ou non être imprimée, copiée ou partagée. Le présent rapport traite de RMS dans le contexte de Recherche et développement pour la défense Canada (RDDC) et fournit notamment : a. Un aperçu du RMS b. Les éléments d une infrastructure de RMS c. Des détails sur le fonctionnement de RMS Les renseignements contenus dans le présent rapport proviennent de diverses sources, y compris le cours de formation technique intitulé «Déploiement de Windows Rights Management Services» [Réf. 1], le rapport sur les Gestion des droits relatifs à l'information (IRM) du Centre de la sécurité des télécommunications (CST) [Réf. 2], les dossiers d aide de RMS [Réf. 3], la trousse de développement RMS (SDK) [Réf. 4], ainsi que d une analyse de la technologie RMS à son état actuel. Le rapport contient notamment les conclusions suivantes, parmi les plus importantes : a. Une solution robuste de gestion des droits (RMS) contribuera à l instauration d une capacité de gestion de l information plus fiable que les mécanismes actuellement disponibles; En particulier, les contrôles procéduraux traditionnels comportent diverses lacunes, notamment en cas d'erreurs humaines non intentionnelles ou de comportements malveillants. Les politiques mises en œuvre grâce au RMS peuvent améliorer substantiellement les mesures de contrôle applicables à la gestion de l information. DRDC Ottawa CR v

10 b. Le RMS peut être appliqué à une multitude d'informations et à autant de besoins différents en matière de protection; Cela est particulièrement pertinent dans le contexte de RDDC, compte tenu des multiples niveaux de sensibilité et des différentes exigences du ministère relativement à la manipulation de l information au sein du MDN. c. Bien que le RMS soit compatible avec l'infrastructure à clés publiques (ICP) Entrust, et qu il puisse être exécuté comme un service sous Internet Information Services (IIS) de Microsoft, il peut également être configuré pour exiger des certificats clients tels que ceux qui sont émis par Entrust. En outre, les serveurs RMS peuvent générer leurs propres certificats d authentification des utilisateurs et en exiger l utilisation. À l heure actuelle, il n est pas possible d utiliser exclusivement les certificats Entrust existants comme critère d authentification pour la gestion des droits. d. La technologie RMS est continuellement perfectionnée et elle risque donc d'être encore modifiée. Bien que ce rapport fournisse un aperçu de la situation actuelle, il faut insister sur le fait qu il devra probablement être mis à jour ultérieurement. Le rapport contient également plusieurs recommandations : a. Le RDDC doit surveiller, étudier et, s il y a lieu, influencer les nouvelles technologies de gestion des droits; b. Il est essentiel de définir des besoins fonctionnels en matière de RMS au sein de RDDC. c. Il faut élaborer un concept des opérations en matière de RMS à RDDC et d. RDDC devrait mettre en place un milieu d essai où les produits de RMS pourraient être analysés et évalués. vi DRDC Ottawa CR

11 Table Of Contents 1. Introduction Aim Of This Report Why Consider RMS? RMS Architecture RMS Trust Hierarchy RMS Credentials And Licenses RMS Components Service Connection Point (SCP) RMS Client Components Rights Management Account Certificate (RAC) How RMS Works RMS Enrollment Process Generating The RAC Acquiring The Client Licensor Certificate Protecting Content Online Protecting Content Offline RMS Consumption Process RMS Use License Requests Contents Of A Use License Request Offline RMS Consumption Exclusion Policies Rights Policy Templates Revocation Contents Of An RMS Protected Document Compound Documents Known Vulnerabilities And Safeguards Built In Security Measures RMS Integration With Entrust PKI DRDC Ottawa CR vii

12 4. Related Products Microsoft Office Certipost Adobe Entrust SealedMedia Authentica Titus International Titus Labs Conclusions Future Work And Recommendations References Annexes Annex A Contents Of Templates, Licenses And Certificates Contents Of A Rights Policy Template Contents Of An RMS Use License Contents Of A Machine Certificate Contents Of A RAC Contents Of An SLC Contents Of A CLC Annex B Contents Of A Revocation List Annex C Logging Details viii DRDC Ottawa CR

13 List of figures Figure 1: forwarded outside of Department... 2 Figure 2: RMS trust hierarchy... 4 Figure 3: How RMS works Figure 4: RMS enrollment process Figure 5: Generating the RAC Figure 6: Acquiring the CLC Figure 7: Protecting content online Figure 8: Protecting content offline Figure 9: RMS consumption process Figure 10: Use License request Figure 11: Contents of a rights protected document Figure 12: Contents of a Policy Template part Figure 13: Contents of a Policy Template part Figure 14: Contents of a Use License part Figure 15: Contents of a Use License part Figure 16: Contents of a Use License part Figure 17: Contents of a Use License part Figure 18: Contents of a Machine Certificate part Figure 19: Contents of a Machine Certificate part Figure 20: Contents of a Machine Certificate part Figure 21: Contents of a Machine Certificate part Figure 22: Contents of a Machine Certificate part Figure 23: Contents of a RAC part DRDC Ottawa CR ix

14 Figure 24: Contents of a RAC part Figure 25: Contents of a RAC part Figure 26: Contents of a RAC part Figure 27: Contents of a RAC part Figure 28: Contents of a SLC Figure 29: Contents of a CLC part Figure 30: Contents of a CLC part Figure 31: Contents of a CLC part Figure 32: Contents of a CLC part Figure 33: Contents of a CLC part Figure 34: Contents of an unsigned Revocation List List of tables Table 1: RMS credentials and licenses... 6 Table 2: RMS key lengths and type... 7 Table 3: UL logged items Table 4: Acronyms list x DRDC Ottawa CR

15 1. Introduction The Microsoft Windows Rights Management Services (RMS) is concerned with the protection and proper handling of electronic information, potentially with differing handling restrictions and requirements for protection, with enforcement of those protections and handling restrictions across multiple domains. An RMS system allows originators to properly classify, tag and assign rights to information when it is created and change those rights even after the information is distributed. Rights include who can access the information as well as what they can do with it once it s opened. These rights are called usage rights and include restrictions such as whether or not the information can be printed, copied or shared. 1.1 Aim Of This Report This report discusses RMS in the context of Defence Research and Development Canada (DRDC). It includes an overview of RMS outlining what RMS is for and why it is being considered by DRDC. This report also details the components and functioning of an RMS infrastructure. The aim is to describe the strengths and weaknesses of RMS including how it might integrate with the existing Entrust PKI infrastructure as well as to evaluate RMS as a suitable technology for a military environment. The report also provides a list of related products, conclusions and recommendations for future work regarding RMS. 1.2 Why Consider RMS? Ensuring the privacy and confidentiality of digital content is a difficult task. The increased use of office automation software and Internet technologies means that more and more information is available in an electronic format. Though this electronic format provides productivity improvements and improves the ability to distribute content it also means that more content must be protected from both intentional and accidental disclosure. Organizations typically use a combination of security technologies, such as firewalls, Access Control Lists (ACLs) and encryption to protect sensitive data. The following lists the challenges of relying solely on these methods: Firewalls do nothing to prevent users from transporting sensitive data outside the firewall on mobile devices such as laptops or Universal Serial Bus (USB) drives. Such data could be left completely unprotected; ACLs work well to limit access to documents that are stored on server inside the enterprise, but when a file is removed from a file server share, the permissions do not remain with the file. So if a file is copied from the server, all restrictive permissions could be removed; and DRDC Ottawa CR

16 Encryption is effective for protecting documents; however, once the recipient decrypts the document, there is no control over what that recipient can do with the document or to whom they can forward the information. Information leaks come from many sources. A security breach can occur by accident such as when a user s storage media is lost or stolen. Compact Discs (CDs), Digital Video Discs (DVDs) and USB thumb drives are all vulnerable media. A user could also accidentally send a document to the wrong address, and therefore, forward sensitive information by accident. Some threats to information security might be intentional. An employee may choose to forward an internal memo to friends or business acquaintances. A disgruntled employee may choose to forward sensitive documents to the press. Corporate spies could leak any information to which that they can gain access. Figure 1 illustrates how simple it can be for internal employees to forward confidential messages to those outside the department if they choose. Figure 1: forwarded outside of Department RMS not only protects digital content by using encryption technology, it also allows the owner of the content to define what a user can do with it after they have accessed it. This is sometimes called defining usage rights, such as the ability to save or print a document or forward an to someone else. The following are some examples of RMS usage rights: The permission to view the content Restrictions determining how long the content is available (expiry dates) 2 DRDC Ottawa CR

17 The permission to print the content The permission to copy the content, including restricting the ability to cut and paste sections of the content or use the print screen function The permission to save the content or use the save as functions Restricting forwarding of and restricting replying to or using the reply to all function DRDC Ottawa CR

18 2. RMS Architecture This section will detail the RMS architecture including the major components, the certificates and licenses used by RMS and how RMS protection works. 2.1 RMS Trust Hierarchy Figure 2: RMS trust hierarchy Figure 2 above, copied from of the RMS Software Developer Kit [Reference 4], outlines the RMS trust hierarchy as follows: 1. Each client computer is issued a unique lockbox that contains the Microsoft root public key. 2. When it receives a license request, RMS validates the principals by following the path that is in the trust hierarchy back to the root of trust. 3. RMS verifies the authenticity of the trusted entity that is named in the license. 4 DRDC Ottawa CR

19 4. RMS verifies that the trusted entity's certificate was issued by a server that is in the trust hierarchy. At each level of the certificate chain, RMS validates the license or certificate, and then verifies that it connects to a known root of trust through a chain of trust. Each license or certificate that is in the chain is checked by RMS to validate the following conditions: Its XrML is valid. The issuer signature is valid. The semantics of the license are appropriate for the intended use. Conditions (such as validity dates) are met. The license has not been revoked. The license signature key and certified issuer key match. 2.2 RMS Credentials And Licenses There are multiple credentials associated with RMS. The purpose of the various credentials is to form the trust model upon which RMS information protection rests. Each participant in the RMS environment has a credential, and often a key pair, associated with it: servers, clients, users, and applications. Specifically, the second entry in this table is the Rights Account Certificate (RAC), an Extensible Rights Markup Language (XrML) certificate which attests the identity of an RMS user, based on authentication to Active Directory (AD) (or Microsoft Passport). The RAC, also sometimes called a Group Identity Certificate (GIC), is the I am who I say I am credential. The Client Licensor Certificate (CLC) is a credential issued by an RMS server to allow a user to protect information without a live connection to that server this is known as offline publishing and is a common scenario in MS Office In addition to credentials that attest to user or other participants (client, server, etc), there are credentials and certificates associated with the actions of publishing and consuming information (publishing and licensing, respectively). Table 1 and Table 2 list the XrML certificates and summarize the policy with which the information is protected. DRDC Ottawa CR

20 Table 1: RMS credentials and licenses CREDENTIAL IDENTIFIES CONTAINS ALLOWS Machine Certificate (one per user per PC) A trusted machine Machine public key Machine and Lockbox to participate in RMS environment Rights Account Certificate (RAC) A trusted user User public and private key (private key encrypted with the machine public key) Signature of issuing server Authorized user to protect and consume RMS content Client Licensor Certificate (CLC) A user allowed to protect content (i.e. publish ) on behalf of the RMS Server, without connectivity to the RMS Server CLC public key CLC private key (encrypted with RAC public key) Copy of RMS Server Licensor Cert (RMS server public key) A user to protect content off-line Publishing License (Issued by either an RMS server or by a user via their CLC) Policy (users, rights, conditions) governing content consumption) Usage rights Required to protect content and to issue Use Licenses Symmetric (128 bit AES) key used for content encryption URL of licensing server Content owner s address and rights request URL (usually a mailto:) Issuing server or CLC signature Use License (Issued by RMS licensing server) Individual user and the Content Key encrypted for that rights and conditions one user they are assigned to the protected content. A list of rights for that user An authorized principal (user) to consume content according to usage rights in the Publishing License A list of any applicable exclusions A URL of an applicable revocation list (optional) A signature by the issuing Licensing Server 6 DRDC Ottawa CR

21 Table 2: RMS key lengths and type KEY(S) TYPE AND LENGTH USE RMS Server Pair of 2048 bit Rivest, Shamir and Adleman (RSA) keys Public encrypt content keys Private sign Publishing License (PL), Use Licenses (UL) and RACs and decrypt content keys Client Machine Pair of 1024 bit RSA keys Public encrypt RAC private key Private decrypt RAC private key RAC Pair of 1024 bit RSA keys Public encrypt content key Private decrypt content key CLC Pair of 1024 bit RSA keys Public encrypt content key Private - decrypt content key and sign PL Content Key Symmetric 128 bit AES Encrypt Content Finally, since each of these credentials has an associated public/private key pair, the private keys are protected in the system using the Data Protection Application Programming Interface (DPAPI), a standard set of Microsoft interfaces. 2.3 RMS Components The following are requirements for an RMS infrastructure RMS Server RMS is a group of web services that run on Windows Server 2003 that certify trusted entities and license rights-protected content. The RMS server also provides the administrative interface for RMS. The RMS server must be running Windows Server 2003 with Internet Information Server 6.0, including ASP.NET, and Microsoft Message Queue. SQL Server A SQL server manages the three databases used by RMS. The configuration database, the logging database and the directory services database. The configuration database holds all the configuration settings for RMS, the Rights Account Certificates (RACs) for the enrolled users, the RMS policy templates and potentially the RMS server s private key. The RMS server s private key is only in the configuration database if a Hardware Security Module (HSM) is not used. DRDC Ottawa CR

22 Active Directory For user authentication, group expansion and to provide the Service Connection Point (SCP) RMS Client software Windows Rights Management client software is a set of Windows APIs that facilitate the machine activation process and allow RMS enabled applications to work with the RMS server to provide licenses for publishing and consuming rights-protected information. RMS enabled applications Work with the RMS client to provide the software interface and the functions to RMS protect content. RMS Software Developer Kits (SDKs) SDKs for the server and client components include a set of tools, documentation, and sample code that enables software developers to customize an RMS environment and to create RMS enabled applications Service Connection Point (SCP) The Service Connection Point (SCP) is an entry in the Active Directory configuration container that points to the RMS root certification URL. This enables RMS clients to discover the root RMS server(s) and enroll in the RMS infrastructure. It is a best practice to abstract the SCP URL to a generic name to allow for changes later on and for load balancing. This is accomplished using a Domain Name System (DNS) alias entry for the SCP URL. For example, RMS.DomainName.ca RMS Client Components RMS Client Software The RMS client software is nothing but a set of API s that the RMS enabled applications call in order to protect or consume RMS protected information. As such, there is no user interface to the RMS client software. All user actions are performed using the RMS enabled applications RMS Enabled Applications RMS enabled applications call the RMS client APIs to enable information protection features such as the do not forward for an , or view only and expiration policy rights on a document. 8 DRDC Ottawa CR

23 RMS enabled applications require a signed application manifest to be trusted within the RMS hierarchy. In order to make sure the calling application is a trusted RMS enabled application, and not a rogue app that might breach RMS protection policies, the RMS client requires a credential called an application manifest from any RMS enabled application that calls it. The application manifest attests that the calling application is the same application (based on a hash of its executables) for which Microsoft signed a rights management license agreement and issued a signing certificate. Developers of RMS enabled applications must following certain security and tamper resistance requirements and sign a two year agreement with Microsoft attesting that they have followed the requirements before the signing certificate will be issued. Once they have met the requirements, a certificate that includes the certificate chain, without expiry date, is granted. (The agreement signed with Microsoft is a two year agreement, the certificate does not expire.) This is a trust model and Microsoft does not inspect the signed applications to ensure they conform to the requirements. The application manifest is a signed XrML certificate that identifies the application itself, as well as all libraries that the application can or must use, as well as those that cannot be loaded in the same process with the protected application Lockbox The lockbox performs the low-level encryption operations on behalf of the user and RMS enabled applications. Lockboxes reside on client computers. A lockbox is an integral part of identifying a computer or device that is trusted by RMS. A computer or device receives a lockbox when the RMS client is activated. Each lockbox is a DLL that identifies the computer by hardware hash. This is the hash of a number derived in part from the hardware ID numbers taken from various components of the client computer. (The details are not fully documented by Microsoft for security reasons.) The lockbox is tied to a machine certificate. The machine certificate is the last certificate on a chain and contains the machine public key and is signed by the root of trust. The lockbox contains the private key of the activated computer and is Federal Information Processing Standard (FIPS) compliant. (RMS 1.0 SP 1) In RMS v1.0, the client activation step required the client machine to connect, via the RMS server, to an internet activation service hosted by Microsoft. This activation service generated a unique lockbox and machine certificate, validating the client machine to use RMS. With RMS 1.0 SP 1, the client machine activation step no longer requires this connection to Microsoft, nor any internet connection at all. Client machine activation has been updated to a self-activation model. The RMS 1.0 SP 1 client is delivered with the lockbox already included, with all the logic necessary to generate, store, and digitally sign the machine s credentials. Using Windows encryption and data protection APIs, the RMS Client will generate the necessary unique key material and digital signatures itself, upon activation. Client activation occurs upon first use of RMS by any user on the machine. This is unchanged from v1.0. In SP 1, however, it does not require the end user to have administrative privileges on their machine. Also, machine keys are now unique to the user, enabling an additional layer of security among users on a common machine. DRDC Ottawa CR

24 There are three different types of lockboxes in RMS: Server lockbox. Enables ISVs to perform server side content access as well as publishing Examples: Work flow applications Content indexing and antivirus scanning Server could apply different RMS templates based on rules set in applications Lockbox for RMS client 1.0 SP 1. Lockbox for RMS client 1.0. Though the RMS users must have Active Directory accounts, there is no requirement for computers to be members of an Active Directory domain to receive a lockbox or machine certificate Rights Management Account Certificate (RAC) The RAC is a certificate only issued to user accounts to identify those users as trusted entities. The RAC can also be simply referred to as the user certificate and contains a single user s public and private key pair. Section Generating the RAC describes how a user enrolls in an RMS infrastructure and receives a RAC. The private key in the RAC is encrypted using the public key from the client computer s machine certificate thus protecting the private key and associating that RAC to a specific computer. The RAC key pairs are securely stored in the SQL database so that when a particular user enrolls in the RMS infrastructure from multiple computers that user will receive the same key pair each time. User may have multiple RACs on same machine if they participate in multiple RMS infrastructures. (Not recommended because of the extra support overhead.) 2.4 How RMS Works Figure 3 and the steps outlined below in, explain the common, high level process for how RMS works. Note that the steps below are not meant to include every detail, just enough to understand the basics. The numbers in Figure 3 correspond to the numbered steps below it. (For the purposes of illustration, Alice and Bob represent fictitious users). 10 DRDC Ottawa CR

25 Figure 3: How RMS works 1) RAC request and CLC request sent to RMS server. This only needs to happen once. 2) Authentication by Active Directory. Active directory can use multi-factor authentication with smart card as well. 3) Each request, and results of the request, are logged in a SQL database. 4) If the content creator was successfully authenticated, RAC and CLC then sent to the content creator. 5) Once the content creator has a RAC and a CLC the RMS client software and RMS enabled application encrypt the digital content along with a Publishing License. The Publishing License includes the usage rights applied to that content. The usage rights may have been applied by a Policy Template. Example: A single Policy Template could grant one group of users full control of the content, a second group view plus printing permissions and a third group view only permissions. The protected content is stored as a file or sent as an message like any other standard file or message. 6) The content consumer attempts to access the RMS protected content by opening the file or message. 7) The RMS client application contacts the RMS server to request a Use License to access the protected content. If the content consumer has not yet enrolled in the RMS domain, a RAC request will be sent first. (Same as steps one and two for the content creator.) 8) The content consumer s user credentials must be authenticated for the Internet Information Service (IIS) and their RAC for the RMS Licensing service. User authentication is usually provided by Microsoft Active Directory but could be provided by an existing Public Key Infrastructure (PKI) certificate as well. 9) The access request and the results of that request, whether granted or not, are usually logged in a SQL database. (Exactly what gets logged is configurable) 10) If the content consumer is successfully authenticated and has been authorized to access the content, the RMS server issues a Use License that allows the content DRDC Ottawa CR

26 consumer to decrypt and access the protected content. Any restrictions regarding the use of the content, like no printing, no copying etc, are specified in the Use License and enforced by the RMS enabled application. For example, if the Use License does not allow printing, Microsoft Word will disable the option to print that specific document for that particular user RMS Enrollment Process RMS Server Active Directory Domain Controller 1 RMS client software installed. (V1 SP1.) 2 RMS client self activates on 1 st use of IRM in Office Receive RAC 6 9 Certification pipeline receives RAC request. Send RAC to user Send CLC request Receive CLC Figure 4: RMS enrollment process Please see the steps below for a description of the RMS enrolment process shown in.figure 4 1) The RMS client software must be installed on the client computer. It can be installed manually or preferably automatically via an Active Directory GPO or Microsoft s Systems Management Server (SMS). 2) The RMS client self activates on first use of any Information Rights Management (IRM) features in Office This means the first time a user either opens RMS protected content or attempts to RMS protect some content the RMS client will generate the lockbox and the client machine s key pair. 3) The RMS client must then discover the Service Connection Point (SCP). 4) The client will retrieve the SCP from the Active Directory configuration container by querying an Active Directory domain controller. 12 DRDC Ottawa CR

27 5) The client will send a RAC request to URL defined in the SCP. 6) The certification service running on the RMS server (certification.asmx) receives the RAC request. 7) The user must first be authenticated via so an Active Directory domain controller is contacted. The users Active Directory credentials are verified. Active Directory could have this user account mapped to an X.509 certificate if required. 8) The results of the RAC request are sent to the DRMS_Logging database on the SQL server. The fact that the user requested a RAC, when and from where and whether or not the request was a success or failure is all logged. 9) Assuming the RAC request is a success, the RAC is sent to the user s computer. 10) The user s computer receives the RAC and places it in the user s profile directory. (%userprofile%/local settings/application data/mircosoft/drm) 11) The Client Licensor Certificate (CLC) request is now sent to the licensing pipeline on the RMS server. 12) The licensing pipeline, specifically the publishing service on the RMS server (publish.asmx), receives the CLC request. 13) The user again must be authenticated using their Active Directory credentials and potentially an X.509 certificate associated with their Active Directory account. 14) The results of the CLC request are then logged into the DRMS_Logging database on the SQL server. The fact that the user requested a CLC, when and from where and whether or not the request was a success or failure is all logged. 15) The CLC is sent to the user s computer. 16) The user s computer receives the CLC and places it in the user s profile directory. (%userprofile%/local settings/application data/mircosoft/drm) The user is now enrolled in the RMS infrastructure and ready to protect and consume RMS content. DRDC Ottawa CR

28 2.4.2 Generating The RAC RM Client 1) RAC Request RMS Server 2) Generate user keypair RMS Server Private Key 3) Encrypt user private key with machine public key 4) Include keys in file 5) Sign certificate 6) Send RAC RM Account Certificate 7) Store copy of user keypair in database. Figure 5: Generating the RAC The RAC is generated as follows: 1. The client sends a RAC request to the RMS Server along with client authentication. 2. The server verifies if a RAC has already been created for the user. If so, the server will use the same key pair, otherwise it will generate a new key pair. 3. The server encrypts the user s private key with the machine public key. 4. Server includes the keys in the RAC. 5. RAC is signed by the RMS server s private key. 6. RAC is sent to the client. 7. User s key pair are encrypted with the RMS server s private key and stored in the SQL database. 14 DRDC Ottawa CR

29 2.4.3 Acquiring The Client Licensor Certificate RMS Client 1) CLC Request RMS Server 2) Generate CLC keypair Server Licensor Cert Server Private Key RAC 3) Encrypt CLC private key with user public key 4) CLC public key and SLC 5) Sign CLC 6) CLC Response Client Licensor Certificate Figure 6: Acquiring the CLC 1) During a Client Licensor Certificate request, the RMS Client will send their RAC to the Licensing Server. 2) The Licensing Server will generate a new RSA key pair for the CLC. 3) The Licensing Server then encrypts the CLC Private Key with the user s Public Key which was extracted from the RAC. 4) The CLC Public Key, the encrypted CLC Private Key, and the Server Licensor Certificate all go into the Client Licensor Certificate. 5) The Licensing Server uses its Private Key to sign the CLC. 6) The Licensing Server returns the new CLC to the RMS Client. DRDC Ottawa CR

30 2.4.4 Protecting Content Online RMS Client 1) Generate symmetric content key Lockbox Usage Rights Server public key 2) Encrypt content key with server public key 3) Send PL Request RMS Server 4) Decrypt content key with server private key 5) Encrypt content key and usage rights with server public key Server private key 6) Encrypted content key with usage rights go into PL Server public key 9) Application binds PL to content 8) Send PL Response 7) PL is signed with server s private Key Figure 7: Protecting content online 1) When issuing RMS content, a symmetric Content Key is creates in the lockbox and the content is encrypted with this Content Key. 2) The Content Key is then encrypted with the Licensing Server s Public Key. 3) The encrypted Content Key and the Usage Rights are sent to the Licensing Server when the Publishing License is requested. 4) The Licensing Server uses its Private Key to decrypt the encrypted Content Key, ensuring that the Publishing License request has been sent to the appropriate Licensing Server. 5) The Licensing Server then encrypts the Content Key with it s own Public Key. Ensuring that only this Licensing Server can decrypt the key and issue a Use License. 6) The encrypted Content Key and the Usage Rights are placed into a Publishing License. 7) The Publishing License is then signed with the Licensing Server s Private Key. 8) The Publishing License is returned to the client. 9) The RMS enabled application then binds the Publishing License to the RMS protected document. 16 DRDC Ottawa CR

31 2.4.5 Protecting Content Offline Lockbox CLC 1) Generate symmetric content key (128 AES) 2) Extract RMS server s public key from CLC RM Client 3) Encrypt content key with server public key 6) Include encrypted content keys in PL 4) Extract CLC Public Key from CLC 5) Encrypt content key with CLC public key 9) Insert PL in document 7) Decrypt CLC private key with RAC private key 8) Sign PL with CLC private key User RAC Figure 8: Protecting content offline 1) When a user creates RMS content while offline, a symmetric Content Key is created in the lockbox. 2) The RMS Client extracts the Licensing Server s Public Key from the Server Licensor Certificate in the CLC. 3) It then encrypts the Content Key with the Licensing Server s Public Key. 4) The RMS Client then extracts the CLC Public Key from the CLC. 5) It then encrypts the Content Key a second time, this time with the CLC Public Key. 6) Both copies of the encrypted Content Key along with the Usage Rights are placed into the Publishing License. 7) The RMS Client then uses the user s Private Key in the RAC to decrypt the CLC Private Key stored in the CLC. 8) It then signs the Publishing License with the CLC Private Key. 9) The RMS Client then binds the signed Publishing License to the document. DRDC Ottawa CR

32 2.4.6 RMS Consumption Process RMS client sends UL request to URL in PL Receives the UL Application associates UL to the protected content 7 Verifies user RAC and permissions listed in PL. Creates UL and sends it to the consumer 6 Results of UL request are logged in DRMS_Logging database 4 10 Figure 9: RMS consumption process Please see the steps below for a description of the RMS consumption process shown in Figure 9. 1) User opens the RMS protected file or message just like any other file or message. For the purposes of this example we will assume the user has already enrolled in the RMS infrastructure. (See figure 3 earlier in this report for the enrollment process.) 2) The RMS client will retrieve the Publishing License (PL) from the protected content, read the URL of the RMS licensing server contained in the PL and send a Use License (UL) request to that URL. The UL request includes the user s RAC. 3) The Licensing pipeline on the RMS server receives the UL request. 4) The RMS server contacts an Active Directory domain controller to have the user authenticated. Active Directory authentication can be configured to require an X.509 certificate as can the Internet Information Services (IIS) on the RMS server if that is desired. 5) Once the user has been authenticated by Active Directory, this only satisfies the authentication requirements for IIS. The RMS server verifies the user s RAC and checks the rights listed in the PL. 18 DRDC Ottawa CR

33 6) The results of the UL request are logged in the DRMS_Logging database. For complete details of what gets logged for each UL request see Table 3 7) The RMS server creates the UL and sends it to the user s computer. The UL is specific to that one user listing the rights and conditions for only that one user and encrypted for that one user. 8) The user s computer receives the UL 9) The RMS enabled application binds the UL to the protected content. 10) The RMS enabled application opens the protected content and enforces the usage rights and conditions listed in the UL RMS Use License Requests RMS Client 1) UL Request RMS Server 2) Decrypt symmetric content key with server private key RMS Server Private Key 3) Encrypt symmetric content key with user public key RAC 6) UL Response 4) Include encrypted key in UL 5) Sign UL Figure 10: Use License request 1) The client requests a Use License by sending the RAC and Publishing License to the Licensing Server which originally issued the Publishing License. 2) The Licensing Server uses its Private Key to decrypt the encrypted Content Key (which is in the Publishing License). 3) The Licensing Server then encrypts the Content Key for the user by using the Public Key in the RAC. 4) The encrypted Content Key and any conditions are put into a Use License. 5) The Licensing Server uses its Private Key to sign the Use License. 6) The Use License is then sent back to the client. NOT SHOWN: DRDC Ottawa CR

34 7) The RMS Client extracts the user s Private Key from their RAC 8) The Lockbox decrypts the user s Private Key using the Private Key stored in the lockbox 9) The Lockbox decrypts the Content Key with the user s Private Key 10) The Lockbox decrypts the encrypted content using the Content Key Contents Of A Use License Request The contents of a Use License are summarized below and detailed in Section RMS client version Lockbox version number Client machine identifier Publishing License Includes encrypted content key and usage rights etc Requesting user s address and SID User s RAC URL of the licensing pipeline (/_wmcs/licensing/license.asmx) A Microsoft Network Monitor capture file called Use License Request.cap [Reference 5] has been provided for those who may wish to investigate the details of the network traffic generated during a Use License request Offline RMS Consumption User must initially connect to server to get a Use License. RMS-protected content can only be consumed when the client is offline if: Use License was previously obtained AND No connection to Licensing Server is required (policy) Revocation is not enabled (policy) RAC is valid Caching behaviour - Use Licenses: Default behaviour is to cache UL 20 DRDC Ottawa CR

35 In document header if New Technology File System (NTFS) permissions allow, otherwise in user s profile directory ( message UL always cached in the user s profile directory) Policy can set UL expiry and/or refresh interval Outlook 2003 can pre-fetch UL (Exchange Cached Mode) Exclusion Policies Principals are excluded through the RMS administrative web site and written to configuration database and, depending on the type of exclusion, may be written to issued Use Licenses as well. (Use Licenses are not issued if the Lockbox or RAC is excluded.) The four types of principals which can be excluded are: 1) Lockboxes Older lockbox versions can be excluded to ensure consistent versions of lockboxes are deployed throughout the enterprise. Lockbox exclusions are stored in the DRMS_Config database (DRMS_ClusterPolicies table) and if the minimum Lockbox version is not installed on the client computer no Use Licenses will be issued to users at that computer. 2) Applications Applications can be excluded to prevent harmful applications from accessing RMS-protected content. These exclusions are stored in the DRMS_Config database (DRMS_ApplicationExclusionList table) and written to Use Licenses. Application exclusions are enforced by the RMS client and if an excluded application attempts to open RMS protected content it fails and an error message indicates application upgrade is required. 3) Versions of Windows Windows 98 and Windows ME are excluded if this policy is enabled though it is possible to modify OS-Exclusion Version span in the configuration database to exclude any Windows OS version deemed necessary. The RMS client will not install on versions of Windows previous to Windows 98. OS version exclusions are stored in the DRMS_Config database (DRMS_ClusterPolicies table) and written to the Use Licenses as an OS-Exclusion Version span with excluded version numbers. If the client computer Windows OS version falls within the excluded version span the content fails to open with error stating to contact an administrator. 4) RACs RAC exclusions are stored in the DRMS_Config database (DRMS_GICExclusionList table). If a user is excluded, no more Use Licenses will be issued to that user. Any Use License DRDC Ottawa CR

36 requests will result in an error message being displayed that states Cannot verify user information at this time. Do you want to open this document using a different set of credentials? Rights Policy Templates While there is great value in being able to protect content for certain users ad hoc and as the need arises, an organization may also wish to define policies which describe a standard set of users, rights and conditions for all content which falls under that policy. Rights policy templates enable authors and organizations to quickly apply the same level of protection for content across the enterprise. All content protected by a template has the same rights, users and conditions applied. (Those that are defined within the template.) Some examples of rights policy templates are Company Confidential. Such a template could be used to allow only employees the ability to view content, but not forward, copy or save the document. Expires in 30 days could be used to ensure that content is invalid after 30 days. A Letter of Offer or a Request for Proposal (RFP), or perhaps a draft version of a document would only be consumable for a set period of time. To ensure expiry policies are not subverted, the RMS lockbox component disables all RMS functionality on a workstation if the clock is set back. Must Be Connected To Consume ensures that recipients have connectivity to an RMS server and are not using cached copies of Use License to consume content. This could be used in the case where a template is subject to change and you want recipient to always consume the latest version. Also, if a laptop is lost or stolen, the RMS protected content would not be accessible to the new owner. Different templates can be distributed to various branches of the enterprise. By using NTFS permissions, one can be sure that only certain parties have access to certain templates. RMS policy templates are extensible Mark-up Language (XML) files created via the RMS administrative web site and are stored in the DRMS_Config database as well as the file system. A registry key on the client computer points to location of the template files in the file system. The XML template files are used when applying the templates to RMS protected content. The rights and conditions defined in a policy template for a given user are written to the Use License issued to that user from the copy of the template in the DRMS_Config database. This is because the policy template could have been updated since the author originally RMS protected content using that template. RMS ensures that the latest version is always used when issuing a Use License by using the version from the DRMS_Config database. Rights Policy Template settings can include: Users and Groups with different rights assigned to them Expiration Policy (When UL expires / must be renewed) 22 DRDC Ottawa CR

37 Extended Policy (Author s rights, if the Rights Management Add-on for Internet Explorer (RMA) is allowed, if UL cached) Revocation Policy (When and where to get revocation list) It is also possible for RMS enabled applications to automatically apply policy templates based on rules defined within an organization using 3rd party software. (See Section 4: Related Products.) Revocation Revocation is only defined within a rights policy template. To define revocation: Create a rights policy template Specify location and file name of revocation list Specify public key to verify signature on list Specify revocation list refresh rate Creating A Revocation List The steps required to create and publish a revocation list are: Use the sn.exe tool from the.net SDK (or similar tool) to create a private key file Use the sn.exe tool to extract a public key file from the previously created private key Write the XrML Revocation List While the ISSUEDTIME and SIGNATURE elements are created automatically by the RLSigner tool, the DESCRIPTOR, ISSUER and REVOCATIONLIST are not. They are created manually. DESCRIPTOR is the same for all revocation lists. ISSUER will be different depending on the Licensing Server that issued the revocation list. ISSUER is represented by GUID which can be found in any license or certificate issued by that server. It can also be found in the SQL database. REVOCATIONLIST will be different depending on the principal being revoked. SQL contains the required information for defining a REVOCATIONLIST element. Entities which can be revoked include: DRDC Ottawa CR

38 Principals by public key Principals by principal ID Certificates and licenses by hash value Certificates and licenses by issuer public key Certificates and licenses by Globally Unique Identifier (GUID) Certificates and licenses by issuer ID Content by Content ID REVOCATIONLIST can be empty. This would happen in the event where a revocation list has been defined in rights policy template, but no principals have yet been defined in the list. Once the revocation list is written, use the RLsign tool (This tool is distributed with RMS) to sign the revocation list. Then copy the revocation list to a Uniform Resource Locator (URL) or Universal Naming Convention (UNC) path specified in a rights policy template that references it. Annex B contains a sample revocation list. 24 DRDC Ottawa CR

39 Contents Of An RMS Protected Document Created when file is protected Encrypted with the server s public key Encrypted with the server s public key Encrypted with Content Key, a cryptographically secure 128-bit AES symmetric encryption key Example: Rights-Protected Document Word, Excel, or PowerPoint 2003 Professional Edition a Publishing License Content Key Rights Info w/ addresses End User Licenses Rights for a particular user Content Key (big random number) The Content of the File (Text, Pictures, metadata, etc) Figure 11: Contents of a rights protected document NOTE: Outlook EULs are Only added to the stored file after in the server local licenses user profile a user to directory open it Encrypted with the user s public key Encrypted with the user s public key Figure 11 shows a graphical depiction of an RMS-protected Microsoft Office document. Note the Publishing License is included within the file upon protection, and is encrypted with the server s public key (exception: the field that shows the URL of the licensing server is readable in clear text) Note also that the Figure 9 shows that Use Licenses are cached inside the file. This only happens if the user has NTFS permissions to write to the file, otherwise they are cached in the user s profile directory. For MS Outlook (unlike MS Word, PowerPoint and Excel), the Use Licenses are not stored in the [ ] files themselves, rather they are always cached in the user s profile directory. The content stream of the document is encrypted with AES symmetric key encryption. This is the content key depicted in both the Publishing License and the Use License. Note: It is the same key in both the Publishing License and the Use License. The difference is that in the Publishing License the content key in encrypted with the RMS server s public key and in the Use License the content key is encrypted with the end user s public key. (Meaning the public key belonging to the authorized consumer who was issued the Use License.) DRDC Ottawa CR

40 Compound Documents It is possible to protect different paragraphs of the same document with different usage rights by using compound documents. Microsoft Office applications create compound documents by using Object Linking and Embedding (OLE) as the framework for assembling documents from multiple sources as the main (compound) document is opened. Though this does function, it is rather cumbersome for the end user as there can be several prompts and messages displayed during the process to successfully open a compound document. This is because there is a separate Use License issued for each RMS protected document embedded and linked to the compound document. If the user has not been granted view access to one of the embedded and linked documents, the compound document will still open and the user will be able to view the authorized sections but a dialog box will appear indicating that the user does not have access and prompt the user to try to open the document using different credentials. This could be very confusing as the dialog box will not indicate what the user does not have access to and the compound document does still open, just without the content the user doesn t have access to. Some customization would be required to make this user friendly. RMS enabled applications that protect and consume web based content could be developed using the RMS SDK to add greater functionality and ease of use for compound documents. 26 DRDC Ottawa CR

41 3. Known Vulnerabilities And Safeguards Though RMS is FIPS 140 compliant, it is promoted by Microsoft as a policy enforcement tool, not a security tool. Vulnerabilities known to the author at the time of this writing are: Domain Administrators can circumvent RMS is several ways: Domain Administrators can change users passwords and then log on as that user to access all that users documents. Domain Administrators could decommission the RMS servers and remove all RMS protection from all protected documents. Domain Administrators could enable the Super Users function within RMS, make themselves a Super User and access any document. Domain administrators could export the RMS cluster s private key and templates and with that build a new RMS cluster offsite and use it to access protected documents. Domain administrators, and potentially many others who have been given appropriate access, can modify the address on user and group accounts in Active Directory and thus spoof authorized users. Domain administrators and SQL administrators can manipulate the contents of the tables used by RMS for caching group membership. A rogue administrator could add their own name or someone else s to the appropriate table thereby effectively adding that name to the group, and getting access to documents, without modifying Active Directory. Anyone with permissions to change group membership in Active Directory can add their own name to a group to gain access to documents protected for that group. Third party screen scraping tools as well as any analog attacks can be used by those with view access to capture the contents of protected documents. Microsoft is the current root of all trust for RMS. The Server Licensor Certificate (SLC) must be renewed each year and if the administrator fails renew the certificate, or Microsoft fails or refuses to issue one, RMS would no longer function in the enterprise. This means no new certificates or licenses would be issued. Without a valid SLC, when users RACs need to be renewed that too would then fail and no RMS protected data would be accessible. Not even previously licensed content. RMS does not ever digitally sign the RMS protected documents or messages. However RMS does sign all certificates and licenses. DRDC Ottawa CR

42 Microsoft Network Monitor capture files Enroll and UL request.cap [Reference 6] and Group lookup.cap [Reference 7] have been provided for those wishing to investigate the network traffic further. 3.1 Built In Security Measures The RMS client checks for potential hacking in several ways and disables RMS functionality on that workstation if a compromise is suspected. Some of the documented built in security measures include: The RMS client checks the RMS enabled application manifests to make sure that they are signed and unchanged. See Section , RMS Enabled Applications, for details regarding application manifests. The RMS client checks to make sure the lockbox is unchanged and machine matches the Hardware ID. The Lockbox is tied to the Hardware ID; therefore, the Lockbox cannot be moved to another computer. This also prevents the machine certificate from being moved. User certificates are tied to the machine certificate and therefore also cannot be moved. The system clock is checked to make sure that it is unchanged to avoid expired RACs and expired Use Licenses from being used. The RMS client checks for debugging applications and the use of the /Debug flag in the boot.ini file. Each standard RAC contains the user s SID so that the RAC cannot be copied and used by another user, even on the same computer. RACs are protected on the client computer because only the machine private key can decrypt the RAC private key. This means that any RAC can only be used on the one machine it was issued for. If a user who has already been issued a RAC, logs onto another computer, a new RAC is issued. The new RAC contain the same key pair as the original but it is tied to the new client machine. The original RAC is still tied to the original client computer. When a Use License is requested the server validates the signature in the user s RAC and the signature in the Publishing License. Any changes to either will invalidate the corresponding digital signature. Use Licenses are also digitally signed by the issuing RMS server. Any changes to the Use License will invalidate that signature thus invalidating the Use License. The Lightweight Directory Access Protocol (LDAP) traffic between the RMS server and the Active Directory domain controller is signed and the servers mutually authenticate. Traffic between the client and the RMS server only consists of encrypted and signed contents to begin with (the certificates and licenses) and can easily be further secured using Secure Sockets Layer (SSL). 28 DRDC Ottawa CR

43 The RMS 1.0 SP 1 client running on Windows XP has been certified to FIPS level 1, and the RMS 1.0 SP 1 server has been certified to FIPS 140-2, level RMS Integration With Entrust PKI RMS can coexist with an existing Entrust PKI system. The Entrust PKI infrastructure need not change, RMS simply will add its policies and usage rights capabilities to the overall security procedures already in place. To configure the RMS server use the Entrust PKI system as an authentication mechanism, configure IIS on the RMS server to use SSL and require client certificates. Windows Authentication (Active Directory) and requiring a client certificate (Entrust certificate) for authentication are functions of IIS. The RMS certification and licensing services still require an RMS issued certificate, this is the user s RAC, as authentication for the users. Taking advantage of the existing Entrust certificates and using them as RMS authentication certificates, in other words replacing the RMS issued RAC with an Entrust certificate, is not possible at this time. RMS acts as its own root CA and there is no option to replace it with any other CA including an Entrust CA. An RMS server will not accept certificates from any other type of CA. Microsoft does acknowledge that this is an important issue to some clients but states that any plans to implement/release this functionality would be post Longhorn server. DRDC Ottawa CR

44 4. Related Products The following list is not meant as a complete and exhaustive list. It is only to serve as a sampling of the most widely used RMS enable applications and related products. For a current list of the Microsoft RMS partners see: Microsoft Office Microsoft Office Professional Edition 2003 provides Information Rights Management (IRM) functionality to restrict who can view, copy, print or forward digital content created with Microsoft Office Word 2003, Microsoft Office Excel 2003, Microsoft Office PowerPoint 2003 and Microsoft Office Outlook IRM in Microsoft Office 2003 products work in conjunction with the Microsoft RMS. Most, though not all, of the other vendors in the IRM space also rely on Microsoft RMS to provide the back-end services for their IRM enabled applications. Rights Management Add-on for Internet Explorer is a free application from Microsoft that allows people who do not use Microsoft Office 2003 to view RMS protected content with Internet Explorer (provided they have been granted access). 4.2 Certipost Certipost s Trust² product allows a Microsoft Office Professional Edition 2003 user to grant access and user rights to documents. This user/sender decides whether the recipient is allowed to read, copy, edit, print, modify or forward his or her Outlook s or Excel, Word and PowerPoint Office files. The sender can also set an expiry date on a document. To check the identity (and profession if desired) of the sender and recipient, Trust² uses the electronic identity card or a professional digital signature from Certipost. The digital certificate in the electronic Identification (eid)-chip contains personal identification information (e.g., the person s name). The professional digital signature guarantees the authenticity of the professional qualification and the correctness of the personal identity. Rights are granted or obtained based on the eid or the professional digital signature. The recipient of the electronically sent documents does not need to have Microsoft Office Professional Edition; they can view documents through Microsoft Internet Explorer. 4.3 Adobe Adobe LiveCycle Policy Server enables organizations to manage document policies by determining who can view, modify, copy, print or forward PDF documents. Through integration with standard LDAP-based 30 DRDC Ottawa CR

45 authentication and identity management infrastructures, the software provides assurances that only intended recipients can open a protected document. The permissions on these documents also can be changed or revoked even after they have been distributed. 4.4 Entrust The Entrust Entelligence Messaging Server provides customers with automated protection of sensitive communications in a manner that is transparent to the sender, where the protection level is determined according to context information, and which is delivered to the recipient via the most suitable supported format. Security credentials for external recipients are transparently managed at a gateway for the organization. As a part of the expanded delivery options, Entrust's secure gateway is also being integrated with the Adobe LiveCycle Policy Server to allow for the dynamic conversion of sensitive communications to policy-protected Adobe PDF documents. This integration is an industry milestone, and will provide organizations with the ability to protect content persistently, long after the recipient receives the . Content protection applied to a PDF document can help prevent that document from being printed, opened by unintended recipients or cut and pasted, while enforcing the expiry of the message contents. 4.5 SealedMedia SealedMedia provides an enterprise document security solution that seals confidential or valuable documents against digital leakage (the loss of confidential information held in electronic format by either malicious or inadvertent means). Only authorized users can use sealed documents and, even while using them, cannot abuse them by redistributing them to unauthorized users. The right to use sealed documents can be revoked at any time, even from previously authorized users and regardless of the final location of the sealed documents. 4.6 Authentica Authentica Secure Mail gives an organization complete control and security over content. Unlike traditional secure delivery solutions, Secure Mail protects content both during and after delivery. and attachments are kept confidential and tamper-proof no matter where they are distributed or stored. A detailed audit trail provides proof of compliance with corporate security policies and regulatory requirements. Authentica Secure Documents is a flexible, secure document sharing application that gives an organization total control over electronic documents -- even after recipients have them. The solution leverages Authentica's patented Active Rights Management technology to continuously protect documents both during and after delivery. DRDC Ottawa CR

46 4.7 Titus International Titus International is a software development and training organization focused on delivering security and policy management solutions. Their focus is on building policy management solutions for and valuable corporate documents, and on providing consulting and training services on the Microsoft Windows RMS platform. 4.8 Titus Labs Titus Labs MessageRights provides enterprises with the ability to effectively manage , including the ability to restrict distribution of sensitive . With access to the powerful classification features of MessageRights, users and enterprises categorize for easy storage, search and retrieval. The classification labels may represent security, sensitivity, distribution, retention or even the project or case associated with the message. MessageRights can also be used to enforce privacy or retention policies to ensure compliance with legislation such as Sarbanes-Oxley, the Health Insurance Portability and Accountability Act (HIPAA) or other corporate or legal guidelines. Titus Labs Rights Gateway is server-based policy enforcement software for Microsoft Exchange that allows customers to manage the distribution of valuable corporate . Designed for large enterprises, Rights Gateway allows administrators to stop sensitive, confidential or classified information from being distributed to unauthorized individuals and domains. 32 DRDC Ottawa CR

47 5. Conclusions A robust RMS solution will help to establish a more reliable information management capability as compared to what is available today. Specifically, today s traditional procedural controls are subject to a variety of weaknesses including both unintentional human error and even malicious behaviour. The policies enforced by RMS can substantially improve the controls on information management. RMS can apply to a plethora of information with different protection requirements. This is especially relevant in the context of DRDC, given the various sensitivity levels and differing business requirements for handling sensitive information within the Department of National Defence. While RMS can work with the existing Entrust Public Key Infrastructure (PKI), and as services running under Microsoft Internet Information Services (IIS), RMS can be configured to require client certificates such as those issued by Entrust, the RMS servers issue and require the use of their own certificates for user authentication as well. Using existing Entrust certificates as the sole authentication requirement for RMS is not possible at this time. The RMS technology is still evolving, and therefore subject to change. Although this report provides a current snapshot, it is emphasized that this is likely to change over time. DRDC Ottawa CR

48 6. Future Work And Recommendations DRDC needs to actively monitor, investigate and, where appropriate, attempt to influence emerging RMS technologies. Detailed business and functional requirements associated with RMS within DRDC need to be developed. A DRDC RMS Concept of Operations (CONOP) needs to be developed. DRDC should establish a test environment where RMS products can be analyzed and assessed. 34 DRDC Ottawa CR

49 7. References [Reference 1] Deploying Windows Rights Management Services (James Donnelly, John Thomson, Tim Upton. November 2003 Titus International Inc.) [Reference 2] Communications Security Establishment Information Rights Management Report (James Donnelly, Steve Lloyd. January 2006 CSE) [Reference 3] RMS help files RMS_Help.chm. (Microsoft Corporation, RMS product help files) [Reference 4] RMS Software Developer Kit - RMS_SDK.chm (Microsoft Corporation. Free download from [Reference 5] Use License Request.cap (James Donnelly, March Titus International Inc. Microsoft Network Monitor application recommended to view this file.) [Reference 6] Enroll and UL request.cap (James Donnelly, March Titus International Inc. Microsoft Network Monitor application recommended to view this file.) [Reference 7] Group lookup.cap (James Donnelly, March Titus International Inc. Microsoft Network Monitor application recommended to view this file.) DRDC Ottawa CR

50 8. Annexes 8.1 Annex A Contents Of Templates, Licenses And Certificates Contents Of A Rights Policy Template The template below was created using the Microsoft Windows RMS purely as an example for this report. In the case of Microsoft RMS, policy templates are created by RMS administrators by means of filling in the blanks on a Web page within the RMS administration Web site. Office 2003 applications include the user interface for the author to choose the desired template (File menu / Permissions / <template name>). This sample policy template defines the rights that allow members of the LegalManagers group permissions to view and edit documents or messages protected with this template, while allowing members of the LegalAid group permissions only to view the document and granting a user, Bob, full control. The contents of the sample policy template have been split into two images, Figure 12 and Figure 13, for ease of viewing in this report. Note: Though the work item appears in both images, it only exists once in the policy template. 36 DRDC Ottawa CR

51 Figure 12: Contents of a Policy Template part 1 DRDC Ottawa CR

52 Figure 13: Contents of a Policy Template part 2 38 DRDC Ottawa CR

53 8.1.2 Contents Of An RMS Use License The next four images, Figure 14 to Figure 17, make up the contents of a single Use License. Figure 14: Contents of a Use License part 1 DRDC Ottawa CR

54 Figure 15: Contents of a Use License part 2 40 DRDC Ottawa CR

55 Figure 16: Contents of a Use License part 3 DRDC Ottawa CR

56 Figure 17: Contents of a Use License part 4 42 DRDC Ottawa CR

57 8.1.3 Contents Of A Machine Certificate The next five images, Figure 18 to Figure 22, are the contents of a single machine certificate. Figure 18: Contents of a Machine Certificate part 1 DRDC Ottawa CR

58 Figure 19: Contents of a Machine Certificate part 2 44 DRDC Ottawa CR

59 Figure 20: Contents of a Machine Certificate part 3 DRDC Ottawa CR

60 Figure 21: Contents of a Machine Certificate part 4 46 DRDC Ottawa CR

61 Figure 22: Contents of a Machine Certificate part 5 DRDC Ottawa CR

62 8.1.4 Contents Of A RAC The next 5 images, Figure 23 to Figure 27, are the contents of a single RAC. Figure 23: Contents of a RAC part 1 48 DRDC Ottawa CR

63 Figure 24: Contents of a RAC part 2 DRDC Ottawa CR

64 Figure 25: Contents of a RAC part 3 50 DRDC Ottawa CR

65 Figure 26: Contents of a RAC part 4 DRDC Ottawa CR

66 Figure 27: Contents of a RAC part 5 52 DRDC Ottawa CR

67 8.1.5 Contents Of An SLC Figure 28: Contents of a SLC DRDC Ottawa CR

68 8.1.6 Contents Of A CLC The next 5 images, Figure 29 to Figure 33, are the contents of a single CLC. Figure 29: Contents of a CLC part 1 54 DRDC Ottawa CR

69 Figure 30: Contents of a CLC part 2 DRDC Ottawa CR

70 Figure 31: Contents of a CLC part 3 56 DRDC Ottawa CR

71 Figure 32: Contents of a CLC part 4 DRDC Ottawa CR

72 Figure 33: Contents of a CLC part 5 58 DRDC Ottawa CR

73 8.2 Annex B Contents Of A Revocation List The example below is a representative of an unsigned revocation list. It is revoking a single principal by specifying the public key from the user s RAC. (The revocation list would have to be signed in order to be used.) Figure 34: Contents of an unsigned Revocation List DRDC Ottawa CR

74 8.3 Annex C Logging Details Table 3 shows the items logged and an explanation describing what each item is. Note the items logged can be modified using settings on the RMS administration web site and settings in the configuration database. The items shows are the default items logged for a Use License request. Table 3: UL logged items ITEM LOGGED s_hostmachinename s_hostmachinerequestid dt_requesttime s_requestpath s_requesttype s_requestuseraddress s_requestuseragent s_authenticatedstate s_secureconnectionstate s_authenticatedid s_receivedxrml s_issuedxrml s_metadata s_successorfailure s_errorinformation dt_logcreatetime EXPLANATION RMS server host name RMS server ID Time of request ISS path (_wmcs/licensing/license.asmx type of request made (AquireLicense) IP address of the user s computer Client software that made the request (Windows Rights Management Client) True or False (if IIS anonymous access allowed state=false, else=true) True or False If using SSL state=true, else=false_ Name of authenticated user (Domain\UserName) This is the Publishing License This is the Use License if the request was successful. If request failed this field is blank address of the owner of the content (taken from Publishing license) Success or Failure (success if UL issued, else failure) Reason for failure Time entry entered into the log 60 DRDC Ottawa CR

75 List Of Acronyms And Abbreviations Acronyms and abbreviations that have been used in this document are listed below. ACL Access Control List Table 4: Acronyms list AES CLC CSE DNS DRM eid EUL FIPS GIC GUID HIPAA HSM HTML HTTP ID IRM LDAP NTFS OLE PKI Advanced Encryption Standard Client Licensor Certificate Communications Security Establishment Domain Name System Digital Rights Management Electronic Identification End User License (also called Use License) Federal Information Processing Standard Group Identity Certificate (more commonly called a RAC Rights Account Certificate) Globally Unique Identifier Health Insurance Portability and Accountability Act Hardware Security Module Hyper Text Mark-up Language Hyper Text Transfer Protocol Identification Information Rights Management Lightweight Directory Access Protocol New Technology File System Object Linking and Embedding Public Key Infrastructure DRDC Ottawa CR

76 PL RAC RFP RMS SLC SMS SSL UL URL UNC USB XML XrML Publishing License (also called an issuance license) Rights Account Certificate Request for Proposal Rights Management Services Server Licensor Certificate Microsoft Systems Management Server Secure Sockets Layer Use License (or End User License) Uniform Resource Locator Universal Naming Convention Universal Serial Bus extensible Mark-up Language extensible Rights Markup Language 62 DRDC Ottawa CR

77 UNCLASSIFIED SECURITY CLASSIFICATION OF FORM (highest classification of Title, Abstract, Keywords) DOCUMENT CONTROL DATA (Security classification of title, body of abstract and indexing annotation must be entered when the overall document is classified) 1. ORIGINATOR (the name and address of the organization preparing the document. Organizations for whom the document was prepared, e.g. Establishment sponsoring a contractor s report, or tasking agency, are entered in section 8.) Titus International 200G-356 Woodroffe Ave Ottawa, ON K2A 3V6 2. SECURITY CLASSIFICATION (overall security classification of the document, including special warning terms if applicable) UNCLASSIFIED 3. TITLE (the complete document title as indicated on the title page. Its classification should be indicated by the appropriate abbreviation (S,C or U) in parentheses after the title.) Security Overview of Microsoft Rights Management Services (RMS) (U) 4. AUTHORS (Last name, first name, middle initial) Donnelly, James 5. DATE OF PUBLICATION (month and year of publication of document) April, a. NO. OF PAGES (total containing information. Include Annexes, Appendices, etc.) 74 6b. NO. OF REFS (total cited in document) 7. DESCRIPTIVE NOTES (the category of the document, e.g. technical report, technical note or memorandum. If appropriate, enter the type of report, e.g. interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period is covered.) 7 Contract Report 8. SPONSORING ACTIVITY (the name of the department project office or laboratory sponsoring the research and development. Include the address.) DRDC Ottawa 3701 Carling Ave Ottawa, ON K1A 0Z4 9a. PROJECT OR GRANT NO. (if appropriate, the applicable research and development project or grant number under which the document was written. Please specify whether project or grant) 15BS01 10a. ORIGINATOR S DOCUMENT NUMBER (the official document number by which the document is identified by the originating activity. This number must be unique to this document.) 9b. CONTRACT NO. (if appropriate, the applicable number under which the document was written) W b. OTHER DOCUMENT NOS. (Any other numbers which may be assigned this document either by the originator or by the sponsor) DRDC Ottawa CR DOCUMENT AVAILABILITY (any limitations on further dissemination of the document, other than those imposed by security classification) ( X ) Unlimited distribution ( ) Distribution limited to defence departments and defence contractors; further distribution only as approved ( ) Distribution limited to defence departments and Canadian defence contractors; further distribution only as approved ( ) Distribution limited to government departments and agencies; further distribution only as approved ( ) Distribution limited to defence departments; further distribution only as approved ( ) Other (please specify): 12. DOCUMENT ANNOUNCEMENT (any limitation to the bibliographic announcement of this document. This will normally correspond to the Document Availability (11). However, where further distribution (beyond the audience specified in 11) is possible, a wider announcement audience may be selected.) Unlimited UNCLASSIFIED SECURITY CLASSIFICATION OF FORM DCD03 2/06/87

78 UNCLASSIFIED SECURITY CLASSIFICATION OF FORM 13. ABSTRACT ( a brief and factual summary of the document. It may also appear elsewhere in the body of the document itself. It is highly desirable that the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with an indication of the security classification of the information in the paragraph (unless the document itself is unclassified) represented as (S), (C), or (U). It is not necessary to include here abstracts in both official languages unless the text is bilingual). The Microsoft Windows Rights Management Services (RMS) is concerned with the protection and proper handling of electronic information, potentially with differing handling restrictions and requirements for protection, with enforcement of those protections and handling restrictions across multiple domains. An RMS system allows originators to properly classify, tag and assign rights to information when it is created and change those rights even after the information is distributed. These rights are called usage rights and include restrictions such as whether or not the information can be printed, copied or shared. This report discusses RMS in the context of Defence Research and Development Canada (DRDC). The most important conclusions presented in this report include: a) A robust RMS solution will help to establish a more reliable information management capability as compared to what is available today. b) RMS can apply to a plethora of information with different protection requirements. c) Using existing Entrust certificates as the sole authentication requirement for RMS is not possible at this time. d) The RMS technology is still evolving, and therefore subject to change. 14. KEYWORDS, DESCRIPTORS or IDENTIFIERS (technically meaningful terms or short phrases that characterize a document and could be helpful in cataloguing the document. They should be selected so that no security classification is required. Identifiers such as equipment model designation, trade name, military project code name, geographic location may also be included. If possible keywords should be selected from a published thesaurus. e.g. Thesaurus of Engineering and Scientific Terms (TEST) and that thesaurus-identified. If it is not possible to select indexing terms which are Unclassified, the classification of each should be indicated as with the title.) Digital Rights Management (DRM), Microsoft Windows Rights Management Services (RMS), document management, usage rights, security UNCLASSIFIED SECURITY CLASSIFICATION OF FORM

79

80