IRM - EMC Community Network

EMC CORPORATIONEMC Documentum Information RightsManagement (IRM)Overview of Technical Architecture8/10/2011Copyright © 2011 EMC Corporation. All rights reserved.EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.THE INFORMATION IN THIS PUBLICATION IS PROVIDED ―AS IS.‖ EMC CORPORATION MAKES NO REPRESENTATIONS ORWARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMSIMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.comEMC 2 , EMC, Documentum, eRoom, and where information lives are registered trademarks of EMC Corporation. All other trademarks usedherein are the property of their respective owners.Overview of Technical Architecture Page 1

Overview of Technical Architecture Page 2

Abstract:EMC Documentum solutions for information rights management (IRM) help global companiesand government agencies actively control, secure, and track sensitive information wherever itresides. Documentum IRM is a suite of products that enable customers to protect sensitive orconfidential information wherever it resides—within a work group on usersdesktops/repositories, across departments, or with partners and suppliers inside or outside thefirewall.This White Paper provides an overview of the technical architecture of the Documentum IRMServer and Documentum IRM Clients.Overview of Technical Architecture Page 3

ContentsOverview ....................................................................................................................................................... 6System Architecture ...................................................................................................................................... 6Encryption and Distribution Process ............................................................................................................. 6Cryptography ................................................................................................................................................ 7FIPS ................................................................................................................................................................ 8Separation of Keys and Content ................................................................................................................... 9Persistent Security & Control ........................................................................................................................ 9Time Handling ............................................................................................................................................... 9System Components ..................................................................................................................................... 9IRM Server ................................................................................................................................................. 9IRM Clients .............................................................................................................................................. 10IRM Services for Documentum and More .............................................................................................. 11IRM SDK ................................................................................................................................................... 11IRM Server Management API .............................................................................................................. 11IRM Server Extension API .................................................................................................................... 12IRM Client Integration API .................................................................................................................. 12IRM Client Decryption API ................................................................................................................... 12Additional Information............................................................................................................................ 12Database ................................................................................................................................................. 12Authentication ............................................................................................................................................ 12Windows ..................................................................................................................................................... 13LDAP ............................................................................................................................................................ 13Certificates .................................................................................................................................................. 14RSA SecurID ................................................................................................................................................. 14Session Security .......................................................................................................................................... 14Server/Client Handshaking ......................................................................................................................... 15Connecting to the IRM Server when opening a protected document.................................................... 15Connecting to the IRM Server without opening a protected document ................................................ 16For certificate user authentication ......................................................................................................... 16IRM Server Permissions .............................................................................................................................. 16Login Restrictions .................................................................................................................................... 16Overview of Technical Architecture Page 4

Users and Groups .................................................................................................................................... 16Server Restrictions .................................................................................................................................. 17Server Extensions .................................................................................................................................... 17Version Exclusion .................................................................................................................................... 17Client Branding ........................................................................................................................................ 17Policies ........................................................................................................................................................ 17Policy Types ............................................................................................................................................. 17Policy Options ......................................................................................................................................... 18Page Level and Document Level Protection (PDF Only) ......................................................................... 18Watermarks ............................................................................................................................................ 18Advanced Screen Capture Defeat ........................................................................................................... 18Guest Access ........................................................................................................................................... 19Offline Access .......................................................................................................................................... 19Audits, Reports, and Notifications .............................................................................................................. 19Network Deployment and Configuration ................................................................................................... 20Conclusion ................................................................................................................................................... 22Overview of Technical Architecture Page 5

OverviewThe EMC® Documentum® Information Rights Management (IRM) Server and the various client components form asystem with the primary objective of providing strong, persistent security and control over information in electronicform. Unlike solutions that only ensure secure delivery of information to authorized recipients, the DocumentumIRM system extends control beyond delivery so that the information is always secure and under the control of theinformation owner. IRM secures content at the object level as opposed to peripheral security solutions which secureaccess to the repository where content resides. It accomplishes this through the use of strong cryptography,controlling access to decryption keys and locking down content consuming applications to prevent undesired use ofthe information. The goal of this paper is to explain the inner-workings of the Documentum IRM architecture and todiscuss some of the security considerations that have been addressed.This document addresses the features available as of the Version 5.0 release of the IRM Server and associatedclients. The IRM products are available in various languages.System ArchitectureThe IRM architecture consists of a family of client applications that works with a common IRM Server to secure andcontrol electronic information. Each of the IRM client applications is responsible for working with a particularinformation type or format. For example, the IRM Client for Microsoft Office is a COM add-in for Microsoft Officeapplications (specifically, Word, Excel, and PowerPoint) designed to secure and control documents in these formats.Likewise, the IRM Client for PDF is designed to secure and control PDF documents within Adobe Acrobat, and theIRM Client for E-Mail is a series of plug-ins for the Microsoft Outlook and Lotus Notes e-mail clients aimed atsecuring e-mail messages and their attachments.Encryption and Distribution ProcessWhen information owners want to secure and control content, they start by registering that content with an IRMServer (depicted as step 1 in the following diagram). Registration can be initiated from within a native applicationsuch as Microsoft Office or Outlook, or Adobe Acrobat.Alternatively, IRM customers can perform this either in a batch mode or programmatically as our protection is oftenused in large-scale applications for content sharing. This method is for customers who do not wish to have enterprisesecurity decisions in the hands of the end users. The advantages are that content security is easier to adopt since it istransparent for the end users, and it ensures consistency of security policy application. Either mode—user–initiatedregistration or programmatic registration—is equally well supported.Initiating the registration process causes the IRM client to establish a secure connection to an IRM Server. The userthen authenticates to the IRM Server and selects the desired security parameters (i.e., who can access it, can it beprinted, should it carry a watermark, should the content be rendered inaccessible at a specific future date, etc.). TheIRM client then generates a random encryption key to protect the content, and sends the key to the server whichrecords the key and policies (security parameters). The client encrypts the content with the key using a symmetriccipher and then discards the key. At the completion of this process, the IRM Server has only the policy andencryption key for the content. The client machine has only the encrypted content—no key or clear text is availableto the user.Overview of Technical Architecture Page 6

Once the content is registered (encrypted), it can be distributed safely through whatever mechanism or protocol ismost appropriate (step 2). It is not necessary for the communication path to be secure since the content isintrinsically secure. However, some customers also include a secure path to transmit the content for extra security.When a recipient tries to open the protected content, the appropriate IRM client is automatically invoked. The clientestablishes a secure connection back to the IRM Server that holds the decryption keys (step 3). The recipient isauthenticated over this connection and a request is made for the key to decrypt the content for viewing. If the IRMServer determines that the access should be authorized (for example, is the user authorized, are all time windowconstraints met, is the request coming from an authorized IP address, etc.), it sends the key and use restrictions (cancontent be copied from, or printed, what watermark should appear) to the client over this secure connection. Theclient decrypts the content to memory then destroys the decryption key. The in-memory copy is purged when theuser closes the file.At any point, the information owner can revoke a given user‘s access to the content or change the policy. Suchchanges take effect the next time a key request is made, which can occur when opening, printing or (in the case ofPDF documents) changing pages. If the keys are deleted from the IRM Server, either manually by the informationowner or automatically through the passing of a preset expiration date, then all copies of the protected content arerendered permanently inaccessible. This is assured since the client never stores local copies of the keys (exceptwhen off-line document access is enabled, as discussed later in the Offline Access section).Since access to protected information requires authenticated interaction with the IRM Server, the server maintainsan extensive audit trail. Through that audit trail, content owners can determine such information as who accessed theprotected content successfully, who were denied access, whether or not the document was printed, and the IPaddress of the machine from which they accessed the protected content.CryptographyThe IRM Server makes use of cryptography for the security of electronic information. There are several ciphers usedwith varying key lengths. A cipher is an equation that is operated on plain text (information) to produce cipher text(encrypted information) and then reversed to produce plain text from cipher text, usually using a key as a variable inthe equation. The actual cryptographic ciphers and how they work is beyond the scope of this document. However,we would point out that cryptographic algorithms generally fall into one of two categories: Symmetric orAsymmetric.Symmetric cryptography is generally meant to describe cryptography that uses the same key for encryption anddecryption of the information. Asymmetric cryptography is generally meant to describe cryptography that uses a keypair – one key to encrypt and the other key to decrypt the information. The IRM products use a symmetric cipher tosecure the information in documents and messages. Therefore, the same key that is used to encrypt the informationOverview of Technical Architecture Page 7

is used to decrypt it. For further information on cryptography, a good reference is the book Applied Cryptography 1by Bruce Schneier.FIPSThe IRM Server, starting with Version 4.6, is compliant with Federal Information Processing Standards 140-2(hereafter referred to as FIPS). As part of being compliant, the IRM Server uses the FIPS certified cryptographiclibrary, RSA BSAFE® Crypto-C Micro Edition via the RSA BSAFE Micro Edition Suite (MES).With Version 4.6 – 4.7, new instances created using the IRM Server operate in FIPS mode (also true for newinstances on an upgraded IRM Server). As of Version 5.0, the administrator has a choice of whether tocreate/upgrade the instance to FIPS mode. For backwards compatibility, any IRM Server instance upgraded to V4.6does not operate in FIPS mode. As stated, an IRM Server instance in FIPS mode uses only the RSA Micro EditionSuite cryptographic library. In non-FIPS mode, the IRM Server instance uses an earlier version of the RSA BSAFEcryptographic library.Besides the cryptographic library used, here are the main differences in the operation of an IRM Server instance inFIPS mode as opposed to an instance in non-FIPS mode:•A non-FIPS IRM Server instance allows the user to select Secure Socket Layer (SSL) to connect to theLDAP directory server. A FIPS IRM Server instance requires TLS to communicate with the LDAP directory server.•A FIPS IRM Server instance communicates to the IRM clients using TLS V1.0. An IRM Server in non-FIPS mode uses SSL V3.0. During an initial connection, the IRM client may try one protocol then the other toconnect to the IRM Server. The IRM client may already know which protocol to use if the client has previouslyconnected to the IRM Server or is connecting to an IRM Server as part of the process of opening protected content.•IRM clients can open content protected by IRM Server instances in FIPS mode, as well as contentprotected by IRM Servers in non-FIPS mode. However, the IRM client is not allowed to open protected contentfrom a FIPS mode IRM server while protected content from a non-FIPS IRM Server is opened, and vice versa.An IRM Server in FIPS mode and the IRM clients that support FIPS can be part of a FIPS compliant environment.Setting up a FIPS compliant environment is beyond the scope of this document, but you can find information aboutFIPS and the RSA MES product at the RSA and Federal government websites:•http://www.rsa.com•http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#828•http://csrc.nist.gov/groups/STM/cavp/1 ISBN 0-471-11709-9Overview of Technical Architecture Page 8

Separation of Keys and ContentMany systems that strive to extend control over information after it has been distributed have adopted an approachin which encrypted key vouchers are granted to users once they have authenticated or performed an operation suchas paying for the content. These systems encrypt the policy options and keys in a voucher that is stored on therecipient‘s system. The viewing client implements a secret algorithm to decrypt the voucher, pull out the keys, andthen decrypt the content and enforce the policy. One drawback to these systems is that a nefarious user can executeoff-line attacks to discover the secret algorithm. Once such a user has discovered this algorithm, he can generate anddistribute his own application that will crack all content protected with this scheme. There have been severalexamples of this happening. The other drawback to this approach is that once the voucher is provided to therecipient, there is no reliable way to modify or revoke his or her access. The recipient can always make a copy of thestate of the system and reproduce that state at a future time when they want to access the information.The IRM system takes a different approach. Keeping key and policy information on the IRM Server prevents offlineattacks. Furthermore, you do not need to rely on a secret algorithm for securing a voucher. Also in the IRMscheme, all time-based decisions are made based on the IRM Server‘s clock (as opposed to the local client clock),which is not subject to manipulation by a malicious user.Persistent Security & ControlUsers may e-mail, rename, and even make copies of a protected document. The information in each rendition is stillprotected. Should the information owner decide to change use permissions on protected content, all copies of theprotected content are affected. For example, the information owner can take away viewing permissions on adocument after it has been e-mailed to multiple users and stored on their PCs.Let‘s look at an example. You send out a sales document to a number of people, then later discover a critical error.In the meantime, that document has been edited, renamed and sent to even more people. As the information owner,you can revoke access permissions, at which point none of the recipients will be able to open any copy. You couldthen distribute an updated copy.Here‘s another example. You protect sensitive legal information in a document and send it to business partners andselect internal employees. At one point, you are no longer business partners with one particular company. You canrevoke access for the users in that particular company alone. All other users still have access.Time HandlingAll time-based decisions are made based on the IRM Server‘s clock as opposed to the local client clock. Theexception to this is when offline access permission is granted. This is where a user is granted the permission to viewprotected content while unable to connect to the IRM Server. Since offline access is granted for a limited amount oftime (e.g., 3 days), the client machine‘s clock is used to determine when the document was opened offline.However, should malicious users change the clock‘s time on their computer once they start working offline to gainadditional time, they invalidate all offline access permissions.Should an information owner wish to view the activity log, all times are based on the server clock but displayed inthe client‘s time zone.System ComponentsLet‘s take a closer look at the components within the IRM architecture.IRM ServerThe IRM Server is a service that accepts connections from various clients, authenticates users, and managesauthorization to, and dissemination of, encryption keys and policies for protected content. The system ensures thatOverview of Technical Architecture Page 9

individuals, even authorized users, cannot get direct access to encryption keys. To accomplish this, the encryptionkeys and other sensitive information are also encrypted as they are stored in the server‘s database. The key forencrypting these sensitive entries is generated when the IRM Server instance is created and is encrypted with theIRM Server instance password.An IRM Server in FIPS mode encrypts the keys and sensitive information with the AES algorithm. The key size is128 bits and used in counter (CTR) mode. An IRM Server in non-FIPS mode encrypts the keys and sensitiveinformation using the RC5 algorithm, where the key size is 128 bits and used in cipher-block chaining (CBC) mode.Besides the database encryption key, a variety of configuration information, some of it sensitive, is stored in theserver‘s configuration file, authentica.cfg. For example, the authentica.cfg file contains both the public and privatekeys 2 of the server‘s certificate (used for authenticating the server and establishing secure connections with clients).Before the IRM Server service can start, the administrator must enter the server startup password. The server startuppassword is used as a component to derive the key for decrypting the sensitive information held in the authentica.cfgfile. The server uses the password to unlock the authentica.cfg file and extract the necessary information. The serverthen begins waiting for connections from clients.The authentica.cfg file itself is encrypted with Triple-DES (3DES) in CBC mode. The algorithm used to convert thepassword to a key is the same as OpenSSL's EVP_BytesToKey, which is described at the following web site. The"salt" value used is randomly generated and stored in authentica.cfg (in the unencrypted portion of the file).http://www.openssl.org/docs/crypto/EVP_BytesToKey.htmlThe database encryption key is also stored in the database and encrypted with the startup password. This is done inorder to handle the situation where there are multiple IRM Servers using the same database (to ensure that the keysare in-sync). The algorithm used to encrypt the database key in the database is DES (not 3DES). Note, that you candelete the key that is stored in the database without having any effect on the system. The key is stored there onlywhen the database is initially created.IRM ClientsThe readily available IRM clients can protect Microsoft Office documents (Word, Excel, and PowerPoint), PDFdocuments, and e-mail messages (Lotus Notes and Microsoft Outlook) and email attachments. Using the IRM SDK(described later), partners can also create IRM-enabled applications to protect content in other formats.The IRM SDK also provides an Image Viewer application that allows users to protect images and view protectedimages. The image viewer includes supports for Bitmap (BMP), Graphics Interchange Format (GIF), JointPhotographic Experts Group (JPEG), and Portable Network Graphics (PNG).2 Public and private keys signify asymmetric cryptography. Certificates, as a general rule, use asymmetric cryptography.Overview of Technical Architecture Page 10

When protected content is opened in an environment where the IRM plugin(s) are installed, the appropriate IRMclient is invoked. The client connects to the IRM Server, authenticates the user, and requests the documentencryption keys. Based on policies, the IRM Server grants a single key to the client for the content. The client usesthe key and the encrypted information (cyphertext) as input to the symmetric AES cipher to decrypt the data(generating plain text). The client also activates the Advanced Screen Capture Defeat feature (described later). Whenthe protected content is closed, the client destroys its copy of the key and deactivates the Advanced Screen CaptureDefeat.It is important that the encryption keys never be exposed to anyone or be saved to disk. Otherwise, there would beno way to ensure policy changes or access revocation. Therefore, great care has been taken to minimize thepossibility that this sensitive information be exposed. For example, decryption keys are destroyed as soon as they arenot needed.To encrypt content, the IRM Server uses the AES-256 Block Cipher in CTR mode for Microsoft Office documents.IRM-enabled applications developed with the Client Integration API use the AES-128 Block Cipher in CTR mode.For PDF documents, one of the following Block Ciphers is used to encrypt content:•If using page level encryption: AES-256 in CBC mode.•If using document level encryption: AES-128 in CBC mode. This is AES-128 since Acrobat onlysupports 128-bit encryption when using doc-level encryption. Decryption is performed in the Adobe Acrobat orAdobe Reader code. Encryption is performed in Adobe Acrobat if the protection is invoked through Acrobat.Encryption is performed in libpvsapi.dll (IRM code) if encryption is invoked via Documentum or through commandline or custom programs.IRM Services for Documentum and MoreThe IRM Services products include IRM Services for Documentum, IRM Services for eRoom, and IRM Servicesfor ApplicationXtender. These services are used in conjunction with an IRM Server and the IRM clients to accessand protect Microsoft Office and PDF documents.IRM Services for Documentum software works with an IRM Server to extend Documentum ACLs outside theDocumentum repository. IRM permissions are managed within the Documentum repository alongside the standardDocumentum permissions. An IRM profile can be defined for a folder to automatically protect documents importedinto the folder. The IRM Services for Documentum software is installed and configured on the DocumentumContent Server and each application server that contains Webtop, Documentum Administrator (DA), TaskSpace, orCenterStage.IRM Services for eRoom operates much the same way; folders, databases, and other eRoom containers can beconfigured to automatically protect contained/attached documents. IRM permissions for protected documents aremanaged using the eRoom UI.IRM Services for ApplicationXtender, similar to IRM Services for Documentum, is another example of IRMintegration with a content management product.IRM SDKThe IRM Server Software Developer‘s Kit (SDK) is a collection of APIs that you can use to automate managementfunctions, write extensions to enhance the IRM Server‘s authorization architecture, integrate your own application toprotect content in different formats, and programmatically decrypt content for eDiscovery or full-text indexing.Here‘s a brief description of each API.IRM Server Management APIThe IRM Server Management API is a shared library that allows programmatic manipulation of an IRM Server. Youcan also use the API in conjunction with specific programming languages to extend environments such as MicrosoftInternet Information Server (IIS). With this API you can provide high-level calls for encryption, and allowmanipulation of server objects such as users, groups and policies.Overview of Technical Architecture Page 11

IRM Server Extension APIThe API provides an events-based interface allowing software engineers to extend or override the IRM Server'spolicy-handling logic or enable authentication for users in unsupported authentication systems. For example, theIRM Services are applications that use the IRM Server Extension API.A Group Policy Server Extension is provided as an example with the IRM SDK kit. It uses the IRM ServerExtension API to provide extra granularity over the assignment of print and edit rights for users who are members ofmultiple user groups.IRM Client Integration APIThis API allows software engineers to build applications that use the IRM Server to protect content in differentformats, such as CAD. It supports GUI applications on Windows using the same dialogs as the IRM clients and alsosupports batch applications on Windows. The IRM SDK includes a sample IRM-enabled imaging application thatallows developers to learn more about the extensibility framework.The features of this API include:•Enables protection of additional file formats.•Provides a consistent user experience and feature set with EMC IRM clients.•Provides high-level calls for encryption and decryption.IRM Client Decryption APIThe IRM Client Decryption API allows programmers to develop applications that can programmatically decryptIRM protected content. This is especially useful when protected content is stored in a repository, where full indexingis desired or required.The API enables decryption capabilities without interfering with compliance rules, enables eDiscovery (searchingencrypted content), allows full-text indexing of protected content, and supports integration with Content/InformationManagement applications.Additional InformationAn application developed using the Client Integration or Content Decryption API is considered to be an IRMenabledapplication. Each IRM-enabled application must be registered with an IRM Server. To do this, theapplication developer must generate an XML file that contains the application name, a certificate chain, types ofcontent, any custom permission, and any language support. Afterwards, the XML file must be registered with theIRM Server in order for IRM users to protect or decrypt content with the application.In addition, the IRM Server administrator can allow or prevent content protected by the IRM Server to be decryptedby a registered application. This setting resides in a document policy. If allowed, the information owner can alsoconfigure this setting.We recommend that you visit the EMC IRM community network at the following web site:https://community.emc.com/docs/DOC-3503This is a place where partners and customers can share information and helpful tips, collaborate on issues, downloadthe latest version of the IRM SDK, and more. It also has the newer IRM-enabled applications, developed bypartners, which protect content in formats such as Auto-CAD and Open Office.DatabaseThe IRM Server requires tablespace in a database. Depending on the OS platform where the IRM Server is installed,the database could be Oracle, MS SQL Server, or MS SQL Express. The database is used to store such informationas the various keys, some configuration settings, policies, and groups. A single tablespace can be used for multipleinstances of the IRM Server that are working together.AuthenticationCentral to any access control system is the ability to reliably determine the identity of the access requestor.Enterprises have invested heavily in establishing authentication infrastructures. In order for a new access controlproduct to be effective, it must integrate cleanly with and leverage the existing authentication infrastructure. TheIRM Server has been designed to do just that. In addition to using shared secret, the IRM Server can easily beOverview of Technical Architecture Page 12

configured to leverage existing authentication systems including Windows login, LDAP, certificate-basedauthentication, and RSA SecurID.The IRM Server Extensions API may be used to provide additional authentication mechanisms; like authenticatingusers against a custom in-house application.WindowsWhen a user authenticates to an IRM Server via (transparent), the client sends Standard SSPIauthentication information to the server. The information is the same that Internet Explorer and IIS would exchangefor "Integrated Windows Authentication," except the IRM product does not use HTTP as the transport medium.Instead IRM uses its own proprietary protocol. This transparent Windows authentication is subject to the samelimitations as the IE/IIS authentication scheme.An IRM Server administrator can allow users from a Windows domain to automatically log in to IRM clientapplications without entering an IRM Server user name and password. If they already logged in to the Windowsdomain through their operating system, the IRM Server uses their Windows domain user name and password to logthem in to the IRM Server.For Windows Single Sign-On (SSO) (aka Integrated Windows Authentication) to work, the client and server mustboth be in the same domain or they need to be in domains with a trust relationship that would permit theauthentication.LDAPThe IRM Server supports using an LDAP directory service to authenticate and authorize users connecting to theIRM Server. The users must be members of an authentication domain that you set up to use the directory service.There are three types of IRM Server authentication domains that you can set up to use an LDAP directory service:•Windows domain with LDAP capabilities•LDAP password domain•Certificate domain with LDAP capabilitiesAs part of adding a Windows domain or a certificate domain, you can add LDAP authentication and authorizationcapabilities to the domain. You may want to do this if your organization has users that log in to their computersusing a Windows domain and password or a certificate, but you also have an LDAP directory service set upcontaining users and groups in your organization. You can also add an LDAP password domain if you want to useLDAP authentication and authorization and your organization does not use Windows domains and passwords orcertificates.Using LDAP with authentication domains allows you to query the LDAP directory service for users and groupswhen you set up server restrictions, groups, e-mail policies, or named policies on the IRM Server. The IRM Serveruses queries to retrieve user information from the LDAP directory server. You can then add this information to thepolicy, or you can place a query in the policy.When a user accesses protected content, the IRM Server checks the Windows domain or certificate to authenticatethe user. If the domain is an LDAP password domain, the IRM Server checks the LDAP directory service to makesure the user name and password are valid. Since there are all types of LDAP domains, the IRM Server also checksthe validity of the user by locating the user in the LDAP directory service and retrieving the user‘s distinguishedname, and that the user is mapped to exactly one entry in the LDAP directory. The IRM Server then checks theappropriate levels of the policy hierarchy and executes any LDAP queries added to the policies in the hierarchy. TheIRM Server also checks that the policies allow the distinguished name of the user or group or the full IRM Serveruser name at each level of the policy hierarchy. The full IRM Server user name for a user is the authenticationdomain name followed by the user name.The LDAP protocol allows directory servers to specify referrals. These referrals allow a directory server to have anentry that references another entry on that server, or even an entry on another directory. When retrieving userinformation from a directory server, the IRM Server automatically follows referrals that reference local entries. Forexample, the IRM Server follows referrals to directory entries that reside in that directory service. The IRM Serverdoes not follow any referral that references entries on a different directory service.Overview of Technical Architecture Page 13

CertificatesCertificate authentication takes advantage of digital certificates and public key cryptography. As part of adding acertificate domain, you can add LDAP authentication and authorization capabilities to the domain. You may want todo this if your organization has users that log in to their computers using a certificate, but you also have an LDAPdirectory service defining users and groups.If you choose to authenticate users with certificates, the IRM Server uses public key cryptography to ensure theidentity of users, where public key cryptography is based on an asymmetric model of encryption.The IRM Server supports X.509 format certificates. To authenticate using a certificate, the certificate must to beavailable from the Windows certificate store on the client system. For example, if an end user adds a certificateusing the Firefox browser, the user may need to export the certificate to Internet Explorer, if the certificate is notalready in the IE store. The same is true for fob and SmartCard certificates.RSA SecurIDA SecurID is a card (token) initialized by a SecurID (RSA) server containing a number that dynamically changes atspecific intervals of time. In addition to having a username, the SecurID server assigns you a PIN. When you log into the IRM Server, you enter your passcode. This is either the PIN followed by the number that appears at thatmoment in time on the SecurID card, or the number that appears on your card after you enter the PIN on it. The IRMServer contacts the SecurID server and uses the passcode to verify your identity and that you have access to the IRMServer.Session SecuritySSL (outer)Application-level encryption (inner)Document KeyThe IRM Server grants an encryption key to a remote client based on policy when the client connects and requests it.This connection and communication is done via an encrypted communications session. This session is protectedusing two levels of encryption.When a client establishes a connection to the server, an SSL session is negotiated just like connecting to an httpssite. (SSL V3.0 for the IRM Server instances in non-FIPS mode, and TLS V1.0 (aka SSL V3.1) for IRM Serverinstances in FIPS mode.) IRM uses SSL server side authentication to authenticate the communicating parties and togenerate a session encryption key. The actual operation of SSL is beyond the scope of this document, but isdiscussed on Netscape‘s developer Web site 3 . The random session key that is generated is a 168-bit key that usesstandard encryption for the SSL tunnel. This key protects all of the client/server communications.3 Introduction to SSL - http://wp.netscape.com/eng/ssl3/Overview of Technical Architecture Page 14

One of the goals of the IRM system is to prevent direct access to decryption keys and sensitive information, evenfrom users authorized to view the content. A knowledgeable, nefarious authorized user could intercept and subvertthe SSL negotiation. Therefore, the client and server negotiate a secondary session key using EMC Documentum‘sproprietary protocol that is used to encrypt data at the application layer, effectively creating a secondary encryptiontunnel inside the SSL tunnel. This protocol uses 256-bit AES (in FIPS mode) or 128-bit RC4 (in non-FIPS mode).Server/Client HandshakingHere‘s more detail on the server/client handshaking process in different situations. IRM uses SSL authenticationonly for authenticating the IRM Server. IRM does not use mutual SSL authentication.Connecting to the IRM Server when opening a protected documentThe user attempts to open a protected document. The IRM client is invoked and determines the IRM Server host andport from the document. The client then establishes a TLS (FIPS) or SSL (non-FIPS) connection with the server. Ifall is well, the IRM Server validates the client then they negotiate the IRM protocol version that establishes whichcapabilities each supports.Initially, the client attempts to get the document key without authenticating the user. This succeeds if the document'spolicy and server restrictions allow guest access. If guest access is not allowed, the user is required to authenticate.Overview of Technical Architecture Page 15

Connecting to the IRM Server without opening a protected documentUsing any application with an IRM plugin already installed, the user logs in by providing the IRM Server host nameand port number, as well as the credentials with which to authenticate. The client then establishes a TLS (FIPS) orSSL (non-FIPS) connection with the server. If this succeeds, the IRM Server validates the client then together theynegotiate the IRM protocol version that establishes which capabilities each supports. The IRM Server concludes byauthenticating the user.For certificate user authenticationThe user logs in by providing the IRM Server host name and port number, but also selects the certificate that is to beused. The client establishes a TLS (FIPS) or SSL (non-FIPS) connection with the server. If this succeeds, the IRMClient sends an authentication message to the IRM Server, which contains the entire certificate chain that the user isattempting to use to authenticate. If the certificate chain is trusted (meaning that there is a certificate authenticationdomain defined on the server that trusts the certificate chain), the server responds with a randomly generatedchallenge string that is encrypted with the user‘s certificate. The client decrypts the value from the challenge andsends it back to the server. The server verifies that the value was decrypted properly. If not, then an error isdisplayed.IRM Server PermissionsWhen determining to allow or deny access to the IRM Server itself and subsequently to the keys for protectedcontent, the IRM Server checks a hierarchy of authorization, which governs different levels of server access. Thefollowing sections describe each level and show how administrators can be very specific on granting access towhom, where, and when.An IRM Server administrator sets the login restrictions, group rights, and server restrictions. The administrator or aninformation owner with permission can also set the document policy. Users sending e-mail set the e-mail policy forthe messages they send.Login RestrictionsThe login restrictions govern when, and from where, users can connect to the IRM Server. The IRM Server enforcesany networks and times set in the login restrictions for every user who accesses the server. For example, if the loginrestrictions specify that only one network entity (company.com) can access the server on weekdays, only users whoconnect from computers on the company.com network on weekdays can access protected content. If a network has atime set to allow or deny access, the IRM Server enforces that time for every user accessing that server over thatnetwork. Even if another type of policy specifically states that users can access content from a specific network at aparticular time, if the login restrictions on the server do not allow it, users cannot connect to open protected content.Users and GroupsOnce you create authentication domains and individual shared secret accounts, you can add users or groups to anytype of policy. This allows you to control authorization. While an authentication domain or shared secret accountallows users to authenticate to the IRM Server, a group identifies one or more users and specifies what those usershave the authority to do.Every user who accesses the IRM Server must belong to at least one group. You can also query an LDAP directoryservice for users and groups or add an LDAP query to a group if you set up an LDAP authentication domain or anauthentication domain with LDAP capabilities. You can specify that users or groups can access the IRM Serverfrom a particular network entity or at a particular time, view, print, or copy from protected content, protect contentwith or without guest access, delete or expire protected content they own, or allow users to work offline.If a user is in more than one group, permissions to print and edit content are evaluated as a logical ‗OR’ of grouppermissions and the resultant permission is that with the least restrictive rights independent of document policyassignment. Let‘s look at a scenario. John Smith is a member of the Sales group, which has only the Viewpermission, and the Management group, which has the Print permission. Now an information owner protects adocument, called SALES REPORT, with a policy that includes only the Sales Group. The expectation might be thatOverview of Technical Architecture Page 16

John Smith can only view the document. However, John Smith can view and print the document since he inheritedthat permission from another user group.The IRM SDK contains a Group Policy Server Extension that provides extra granularity over the assignment of printand edit rights at the Group level. This extension can modify the behavior of how permissions are granted in usergroups.The IRM Server also provides various levels of administrator permissions.Server RestrictionsServer restrictions govern the entire IRM Server. The IRM Server enforces any authorizations set in the serverrestrictions for every user who accesses the server and all content protected by the server. For example, if the serverrestrictions do not allow printing, users cannot print any of the content protected by the server, regardless of thepolicy protecting that content.The server restrictions govern permissions such as how users can perform actions on protected content (print, copyfrom, edit, guest access, offline access, watermark, and custom permissions). Server restrictions also dictate whenthe IRM Server will be allowed to destroy keys for expired content.Server ExtensionsApplications that use the IRM Server Extension API can also grant and deny permissions in conjunction with thedocument policy. A server extension application may not override any restrictions already placed on the document(e.g., through server restrictions or the document policy), but additional users may be given access to the document.In the case of IRM Services for Documentum, the administrator creates a global document policy on the IRM Serverthat allows all the permissions that any particular user may ever need. Permission sets configured by Documentumusers can further restrict those permissions for specific documents (e.g., by only allowing certain users to print). TheDocumentum Server Extension can also grant access to Documentum users not listed in the document policy on theIRM Server.Version ExclusionYou can control which versions of IRM client applications can access the IRM Server. You may want to do this soyou can deny access to previous clients. If you do not specify client versions, the IRM Server allows access to allcurrent and future versions of clients that exist when you purchase your IRM Server.Client BrandingThis feature allows customers to change the EMC logo on many of the IRM client dialog boxes, to one of their ownchoosing. Branding affects only those IRM clients running on a Windows platform. The ability to change the logorequires creating a resource-only DLL branding file, then uploading this file to the IRM Server using the IRMServer Configure utility. The procedure is documented in the IRM Server Installation Guide.PoliciesInformation owners authorize access to their content through the use of policies. Policies determine how protectedcontent can be accessed, when it can be accessed, and by whom. It also defines the actions a user can perform on thecontent.An IRM Server administrator creates and maintains the policies; however, an administrator can grant informationowners the permission to make their own customized policies.Policy TypesAn e-mail policy restricts access to specific protected e-mail messages. A document policy determines access to theprotected document. A document policy is generated from either a named policy created by an administrator or froma custom policy created by an information owner.There are two types of named policies. One is a document policy template, which allows an administrator to createstandard policies that can be selected by users when protecting documents. Once applied, a copy of the template iscreated, which becomes the document policy. The document policy applies to a single document. Any changes tothe template after the document is protected do not affect the document. However, a document owner withOverview of Technical Architecture Page 17

permission or administrator can modify the document policy at any time. For example, an owner may want toremove users or groups from the list of authorized viewers. IRM client users with appropriate permissions can alsodefine their own document policy templates. When creating named policies, administrators can select the Globaloption which makes the policies available to all users.The other type of named policy is the shared document policy (also known as a referential policy), which alsoallows an administrator to create standard policies that can be selected by users when protecting documents.However, unlike a template, the policy can be applied to multiple documents, and changes to the shared policy affectthe documents protected by the policy. The document owner cannot make changes to a shared policy.Information owners, at the discretion of the administrator, may be granted the permission to create their own customdocument policies. This allows the information owner to determine access permissions and which users or groupsare allowed to access the protected content. This capability allows administrator to force information owners to usepredefined policies, or to be flexible in allowing the owners to define their own. Information owners who createtheir own custom document policies using the IRM client can also save their policies as personal templates for reuse.Policy OptionsPolicies are used to control the access rights available for a given document. Policy options include: An access list containing the users, groups and network locations, which can access the document Rights: document rights including print, copy from text, edit Available Date: the date the document will become available to users Expiration Date: A date or time-span after which no one will be able to access the document Watermark: Assign a watermark to be displayed when the document is printedPage Level and Document Level Protection (PDF Only)For protected PDF content, the IRM Server and IRM Client for PDF have the capability to encrypt the document asa whole using a document level policy or encrypt each page individually using a page level policy.A page level policy allows you to apply a different set of permissions and user access to selected pages within aprotected document. For example, you could protect a document so that one part is classified as confidential, anotherpart is secret, and a third part is top secret. You can distribute the protected document knowing that individuals willbe able to view only the sections they are authorized to view. The page level feature applies a different encryptionkey to each page whether or not you apply a different set of permissions to selected pages. Because of this, usingpage level in a large document may decrease performance. Also, page-level protection can result in a much largerfile due to the way Adobe optimizes image use.When an authorized user opens a protected PDF file that uses page-level encryption, a key request is made to theIRM Server every time the user changes pages. If the window size does not display the full page, scrolling down orup also causes a key request, since only the text that can be displayed in the window is decrypted.WatermarksA watermark is text that appears on a protected PDF, Word, Excel and PowerPoint document when a user prints thedocument. (Watermarks for e-mail are not supported.) The watermark also shows up on the screen while viewingPDF documents. The IRM Server administrator defines watermarks and can associate them with user groups,document policies, or for the whole server using server restrictions. A watermark could be as simple as including theword confidential across the top of a company confidential document. Watermarks can be more sophisticated byaltering their color, layout, and font or by including additional information such as the username of the user viewingthe document and the date and time they are viewing it.Watermarks are page specific, so each page may have a different watermark. It can even be sensitive to the type andversion of the IRM client used to view the document.The watermark feature also supports using double-byte characters (Chinese, Korean, or Japanese).Advanced Screen Capture DefeatEMC IRM includes features called Screen Capture Defeat, which provides protection from native MicrosoftWindows print screen functions, and Advanced Screen Capture Defeat (ASCD), which provides protection fromcommon 3rd party screen grabbing tools. IRM ASCD is an added deterrent to users who wish to take maliciousaction within a protected document. IRM ASCD is not a fail-proof mechanism for stopping a malicious user fromOverview of Technical Architecture Page 18

writing a custom program to grab the contents of the screen, taking a picture of the screen, writing down what theysee to a piece of paper, or taking their laptop/monitor over to a copy machine.Guest AccessYou can allow users to create a policy that allows guest access. When protected content allows guest access, theviewer of the protected content can view it without authenticating with the IRM Server. However, the viewer musthave the IRM client installed and be able to contact the IRM Server.The guest user is still governed by the permissions granted or denied in the document policy, as well as the serverrestrictions. And the audit trail does track the activity of guests.An example of using this feature is to combine it with network entities, allowing partners from a specific domain toshare documents without requiring a username. You can also allow both guest access and authenticated user accesson a specific document. For example, a PDF document protected at the page level could allow guest access to thefirst page but require authenticated user access for the other pages.Offline AccessOne aspect of the IRM approach is that the user must be connected in order to access the protected information.With the proliferation of broadband and always-on connectivity, this is often a reasonable constraint. However, insome cases a live connection to the IRM Server is not feasible. For those applications the IRM system is capable ofgenerating and downloading vouchers (for offline access) that are encrypted and saved locally on the client. Likeother voucher-based schemes, the sensitive information is encrypted and obfuscated to deter access or tampering.Via the document policy, the information owner and the IRM Server administrator control whether or not adocument is allowed to have offline access.The information owner can also determine the duration allowed for working offline. For example, a protecteddocument may only be allowed to be offline for 10 days; after which, the document is no longer accessible until theviewer reconnects to the IRM Server.You access the protected document offline the same way you access it online. If you were required to log into theIRM Server while online, you still need to enter your login information to open the document. The permission set(such as editing, printing, and copying) for the document remains the same.For security, changes to the clock on the client machine while working off-line may invalidate all offline accesspermissions.The SecurID authentication mechanism is incompatible with offline access. Therefore, users authenticating withSecurID do not have access to this feature.Audits, Reports, and NotificationsNo security system is completely secure. However one feature that helps to maximize the security of a given systemis the ability to audit activity. One feature of the IRM architecture is that the IRM Server is involved in all access tosensitive information. This provides a unique opportunity to maintain a comprehensive audit trail. Not only can youtrack who accessed a piece of information, when, and what they did with it, you can also track who tried but wasdenied access and from what IP address they made their attempt. Often the threat of audit is enough to deterinappropriate use of sensitive information.The IRM Server ships with a custom Active Server Pages (ASP) reporting application, which extracts historicalactivity information from the IRM Server's XML log files. The reports allow you to view activity on the IRMServer. If the reports do not provide the information you want to view, you can use them as examples and createyour own reports using third-party software tools.You can receive a notification when the server logs messages matching criteria that you specify. You can specify:•The severity about which to notify you•The method used to notify you (including SMTP messages and SNMP traps)•The time period during which to notify youInformation owners can also track activity for their document. The IRM clients provide an activity window thatdisplays information such as when a document was accessed and by whom and at what time, whether access wasdenied, and if the document was printed.Overview of Technical Architecture Page 19

Network Deployment and ConfigurationAs discussed earlier, the IRM Server is a service and the clients are plug-ins. Generally speaking, there are nosettings in the IRM software that specifically relate to load balancing or High Availability (HA). Supportingmultiple IRM servers is done by DNS, other hardware and basic networking. The IRM Server uses TCP for theconnection between the server and external entities, such as SMTP, LDAP and ODBC. A single host can havemultiple instances of the IRM Server.The IRM products support a completely virtualized infrastructure. For example, the IRM Server supports being runin a VMWare environment.Here is an example configuration in HA:Overview of Technical Architecture Page 20

IRM can be configured in an active-active network configuration to provide for high availability via failover andload balancing. Typical IRM implementations involve two or more IRM Servers configured in an active/activeconfiguration (for high availability and failover) and a physically separate database server or cluster. The followingdiagram shows two sample configurations:Overview of Technical Architecture Page 21

ConclusionThe objective of the EMC Documentum IRM architecture is to extend the security and control of sensitiveinformation beyond delivery to and access by authorized users. As such, it faces unique challenges. The IRM systemuses strong industry-standard cryptography, combined with unique client-server architecture, to address thosechallenges. Great care has been taken to ensure the security of communications between the client and server, toprevent direct access to the encryption keys and plain text, and to control what can be done with the informationonce it is decrypted and displayed to the user. The resulting persistent control opens entirely new opportunitiesregarding the way sensitive information can be shared.EMC Documentum IRM should be considered a critical piece of the overall security solution an organizationdeploys. This includes the physical security of the computer, control over what users can install on their computer,control over who has access to the data based on access control lists, forcing users to authenticate to the content. Thevalue added by EMC Documentum IRM is that of an additional layer of dynamic protection and auditing ofinformation after it is opened. IRM provides object level protection of the information itself, regardless of wherethat information is located – inside or outside your secure environment.Overview of Technical Architecture Page 22