May 2012

Microsoft IRM protection Specification Supplement to ISO 32000

Author: Barak Cohen

for

PDF

2012 Microsoft

Revision History
2012/04/25 2011/10/19 2011/09/23 2011/09/21 0.9.6 0.9.5 0.9.1 0.9.0 Updated version for ISO submission Proposed version for standardization Add the description of the format of encrypted data and how to decrypt. Initial version

May 2012

Preface
The Portable Document Format (PDF) is a file format for representing documents in a manner independent of the application software, hardware, and operating system used to create them and of the output device on which they ar e to be displayed or printed.

What is in this guide?

This document describes Microsofts IRM protection for PDF extension and implementation notes relative to the ISO 32000 Portable document format, PDF 1.7 standard The extensions are to the PDF document format. Microsoft plans to submit these extensions to ISO as candidates for inclusion into the next version of the ISO 32000 specification.

Who should read this guide?

This guide is intended for developers of applications that consume or produce PDF content. The implementation notes are intended for developers who need more detail about the implementation.

Related documentation
Portable Document Format PDF 1.7 PDF Reference, sixth edition, version 1.7 Microsoft Right Management Services on Technet Active Directory Rights Management Services SDK Rights Management Services Protocols Overview Cipher modes Microsoft Information Protection and Control SDK

Extensions to PDF specifications

The language extensions described in this guide will be submitted to ISO as proposed changes to the PDF specification. ISO may or may not accept these extensions. If accepted, the exact syntax and semantics of the ISO version of these extensions may differ from that described in this guide.

Behavior of PDF consumers that does not support an extension

The extension convention also relies on the behavior of PDF consuming applications when they encounter PDF properties they do not recognize. The Section 2.2.8 Extensibility in the PDF Reference, sixth edition, version 1.7 describes this behavior as follows: PDF is designed to be extensible. Not only can new features be added, but applications based on earlier versions of PDF can behave reasonably when they encounter newer features that they do not understand. Appendix H describes how a PDF consumer application should behave in such cases. And Appendix H in PDF Reference, sixth edition, version 1.7 provides this additional guidance: Both viewer applications and PDF have been designed to enable users to view everything in the document that the viewer application understands and to ignore or inform the user about objects not understood. The decision whether to ignore or inform the user is made on a feature-by-feature basis. The discovery page payload feature (that is

May 2012
described below) takes advantage of this to provide a discovery mechanism for the feature on readers that do not support the extension.

PDF Protector File Format

Encryption Dictionary
The original encryption dictionary is complied with Section 7.6 Encryption in PDF Reference 1.7. Table 1 shows the extended entries in Microsoft IRM encryption dictionary. KEY
Filter PublishingLicense Name string

TYPE

VALUE
RequiredThe name of extended security handler. It is always "MicrosoftIRMServices". (Required) Encoded Publishing License issued from server to the Content publisher. This field contains the publishing license from Microsoft IRM services or a comparable IRM service The original data of Publishing License should be compressed by Flate compression algorithm at first, and then encoded by Base-64 Encryption algorithm. (Optional, Extended) An array of dictionary object. Each dictionary object is encoded Server EUL, which contains following entries: << /ServerID() /ServerEUL() >> The original data of Server ID and Server EUL should be compressed by Flate compression algorithm at first, and then encoded by Base-64 Encryption algorithm.

ServerEulList

Array

MicrosoftIRMVersion

Number

(required) The default value is 1

Table 1- Encryption Dictionary Entries

Encrypted Payload
The encrypted payload complies with section 7.6 in the PDF 1.7 spec. The PL contains the information about the specific method that is used to encrypt the payload.

IRM Discovery Payload (optional)

The IRM Discovery Payload, (also known as Wrapper) is a standard PDF file that complies with the PDF

May 2012
specification that is wrapping the original encrypted files (see section 7.5.5 File Trailer in PDF Reference 1.7). The goal for having the discovery payload is to be able to point the readers to the steps that will help them get a compatible reader that supports the extension that this document describes and that can show the encrypted payload. The following tables define the keys that are used in the payload. KEY
Wrapper

TYPE
dictionary

VALUE
(Required, Extended) A dictionary that marks the extension as a Discovery Payload (Wrapper). It defines the related controls and descriptions. (See details in Table 2.2) (Required, Extended) The offset of current discovery payload from the beginning of the file. It is only valid when there is a wrapper dictionary.

WrapperOffset

integer

Table 2 - Extension to File Trailer

KEY

TYPE

VALUE
(Required) The wrapper name. It must be MicrosoftIRMServices. (Optional) The current version number of the wrapper. The default value is 1.

Type name Version number Table 3 - Wrapper Dictionary Entries

Implementation notes
These notes will help developers understand how this extension is manifested in actual PDF documents. In here we provide an example of a PDF file that supports the extension in addition to notes on the encryption implementation of the payload inside the document.

PDF content example

The example below shows how a PDF file will look like supporting the extension:
%PDF-1.7 1 0 obj << /Type/Catalog/Outlines 2 0 R/Pages 3 0 R/AcroForm<</Fields[]>> >> endobj 9 0 obj << /Filter /MicrosoftIRMServices / MicrosoftIRMVersion 1 /PublishingLicense() /ServerEUL [<</ServerId()/ServerEUL()>>] >> endobj xref 0 10 0000000000 65536 f 0000000017 00000 n 0000000848 00000 n trailer <</Root 1 0 R /Encrypt 9 0 R /ID [() ()] /Size 10>> startxref

May 2012
35908 %%EOF %Following is the discovery payload %PDF-1.7 15 0 obj <</Length 377/Filter/FlateDecode>> stream endstream endobj xref 0 16 0000000000 65536 f 0000036212 00000 n trailer << /Root 1 0 R /Info 3 0 R /Size 16 /Wrapper <</Type /MicrosoftIRMServices /Version 1>> /WrapperOffset 36195 >> startxref 37873 %%EOF

Figure 1 - sample of an encrypted file with discovery payload

Encryption and Decryption of Stream and String

As described in PDF specification, the stream and string object should be encrypted when protecting a PDF document. The encryption/decryption method is described as following:

Encrypt
1. 2. 3. Get the length of the data to be encrypted. Append 4 bytes header at the beginning of the data. These 4 bytes will store the length (with the high-order byte first) of the data to be encrypted. Encrypt the data (including the 4 bytes header).

Decrypt
1. 2. 3. 4. Decrypt the data. Read the first 4 bytes header at the encrypted data. This 4 bytes data is the length (with the high-order byte first) of the decrypted data. Get the decrypted data from the 5th bytes with the length in step 3.

Note
Please note that the 4 bytes header is stored with high-order byte first, which is different with what the integer is stored in memory on Windows platform. This is to ensure the interoperability between different platforms.

Encrypt Example
1) Data to be encrypted:
5

May 2012
H e l l o

2) Append 4 bytes header:

0x00 0x00 0x00 0x05 H e l l o

3) Encrypt the data (including the header):

x x x x x x x x x x x x x x x x x x x x

Decrypt Example
1) Data to be decrypted:
x x x x x x x x x x x x x x x x x x x x

2) Decrypt the data:

0x00 0x00 0x00 0x05 H e l l o x x x x x x x

3) Get the original data from the 5th bytes with the given data length.
H e l l o

Encryption and Decryption methods

Microsoft IRM services uses the Advanced Encryption Standard (AES) algorithm and the electronic codebook (ECB) block cipher ( in 1024 and 2048 key length), or cipher-block chaining (CBC), for encryption. To make the lives of developer easier, Microsoft provides a client side library that wraps the IRM services (MSIPC) as described in Microsoft Information Protection and Control SDK.