Compartir a través de

5 Appendix A: Product Behavior

  • Artículo

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

  • Microsoft Office 97

  • Microsoft Office 2000

  • Microsoft Office XP

  • Microsoft Office 2003

  • The 2007 Microsoft Office system

  • Microsoft Office 2010 suites

  • Microsoft Office 2013

  • Microsoft Office 2016

  • Microsoft Office 2019

  • Microsoft Office SharePoint Server 2007

  • Microsoft SharePoint Server 2010

  • Microsoft SharePoint Server 2013

  • Microsoft SharePoint Server 2016

  • Microsoft SharePoint Server 2019

  • Microsoft Office 2021

  • Microsoft SharePoint Server Subscription Edition

  • Microsoft Office LTSC 2024

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 2.2:  Applications in Office 2003, the 2007 Microsoft Office system, Microsoft Office 2010 suites and Office 2013 versions encrypt the Microsoft Office binary documents by persisting the entire document to a temporary OLE compound file and then transforming the physical representation of the OLE compound file as a single stream of bytes. Similarly, ECMA-376 documents [ECMA-376] are encrypted by adding the entire file package to a temporary file and then transforming the physical representation of the file as a single stream of bytes.

The following streams are also stored outside the protected content to preserve interoperability with applications that do not understand the IRMDS structure:

  • _signatures

  • 0x01CompObj

  • Macros

  • _VBA_PROJECT_CUR

  • 0x05SummaryInformation

  • 0x05DocumentSummaryInformation

  • MsoDataStore

Applications in Office 2003, the 2007 Office system, Office 2010 and Office 2013 also create the streams and storages necessary to create a default document within the OLE compound file. This default document contains a short message to the user indicating that the actual document contents are encrypted. This allows versions of Microsoft Office that do not understand the IRMDS structure to open the default document instead of rejecting the file.

<2> Section 2.2.1:  Office 2003, the 2007 Office system, Office 2010 and Office 2013 offer the user the option of creating a transformed MHTML representation of the document when applying a rights management policy to a document. This option is on by default in Microsoft Office Excel 2003 and off by default in all other applications in Office 2003, and it is off by default in all applications in the 2007 Office system, Office 2010 and Office 2013. If the transformed MHTML representation is created, the 0x09LZXDRMDataSpace data space definition is applied to it (which includes both LZX compression and encryption).

<3> Section 2.2.2:  Office 2003, the 2007 Office system, Office 2010 and Office 2013 offer the user the option of creating a transformed MHTML representation of the document when applying a rights management policy to a document. This option is on by default in Office Excel 2003 and off by default in all other Office 2003 applications, and it is off by default in all applications in the 2007 Office system and newer versions. If the transformed MHTML representation is created, the 0x09LZXDRMDataSpace data space definition is applied to it (which includes both LZX compression and encryption).

<4> Section 2.2.3:  Office 2003, the 2007 Office system, Office 2010 and Office 2013 offer the user the option of creating a transformed MHTML representation of the document when applying a rights management policy to a document. This option is on by default in Office Excel 2003 and off by default in all other Office 2003 applications, and it is off by default in all applications in the 2007 Office system, Office 2010 and Office 2013. If the transformed MHTML representation is created, the 0x09LZXDRMDataSpace data space definition is applied to it (which includes both LZX compression and encryption).

<5> Section 2.2.6:  Office SharePoint Server 2007 uses the AUTHENTICATEDDATA element with the name set to "ListGUID" as the application-specific GUID that identifies the storage location for the document. This is stored encrypted within the element as follows.

 <AUTHENTICATEDDATA id="Encrypted-Rights-Data">

Once decrypted, the XrML document contains an element named AUTHENTICATEDDATA, containing an attribute named id with a value of "APPSPECIFIC" and an attribute named name with a value of ListGUID with the contents of the ListGUID.

<6> Section 2.2.11:  Office 2003, the 2007 Office system, Office 2010 and Office 2013 offer the user the option of creating a transformed MHTML representation of the document when applying a rights management policy to a document. This option is on by default in Office Excel 2003 and off by default in all other Office 2003 applications, and it is off by default in all applications in the 2007 Office system, Office 2010 and Office 2013. If the transformed MHTML representation is created, the 0x09LZXDRMDataSpace data space definition is applied to it (which includes both LZX compression and encryption).

<7> Section 2.3.1:  In the 2007 Office system, the 2007 Office system, Office 2010 and Office 2013, the default encryption algorithm for ECMA-376 standard encryption documents [ECMA-376] is 128-bit AES, and both 192-bit and 256-bit AES are also supported. It is possible to use alternate encryption algorithms, and for best results, a block cipher supporting ECB mode is recommended. Additionally, the algorithm ought to convert one block of plaintext to one block of encrypted data, where both blocks are the same size. This information is for guidance only, and it is possible that if alternate algorithms are used, the applications in the 2007 Office system, Office 2010 and Office 2013 might not open the document properly or that information leakage could occur.

<8> Section 2.3.2:  Several of the cryptographic techniques specified in this document use the Cryptographic Application Programming Interface (CAPI) or CryptoAPI when implemented by Microsoft Office on the Microsoft Windows operating systems. While an implementation is not required to use CryptoAPI, if an implementation is required to interoperate with the 2007 Office system, the 2007 Office system, Office 2010 and Office 2013 on the Windows XP operating system, Windows Vista operating system, Windows 7 operating system, Windows 8 operating system and Windows 8.1 operating systems, the following are required:

Cryptographic service provider (CSP): A library containing implementations of cryptographic algorithms. Several CSPs that support the algorithms required in this specification are present by default on Windows XP, Windows Vista, Windows 7, Windows 8 and Windows 8.1 operating systems. Alternate CSPs can be used, if the CSP is installed on all systems consuming or producing a document.

AlgID: An integer representing an encryption algorithm in the CryptoAPI. Required AlgID values are specified in the remainder of this document. Alternate AlgID values can be used if the CSP supporting the alternate AlgID is installed on all systems consuming or producing a document.

AlgIDHash: An integer representing a hashing algorithm in the CryptoAPI. Required AlgIDHash values are specified in the remainder of this document. For encryption operations, the hashing algorithm is fixed and cannot vary from the algorithms specified.

The following cryptographic providers are recommended to facilitate interoperability across all supported versions of Windows:

  • Microsoft Base Cryptographic Provider v1.0

  • Microsoft Enhanced Cryptographic Provider v1.0

  • Microsoft Enhanced RSA and AES Cryptographic Provider

Note that the following providers are equivalent:

  • Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)

  • Microsoft Enhanced RSA and AES Cryptographic Provider

The provider listed as "Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)" is found on Windows XP. An implementation needs to treat these providers as equivalent when attempting to resolve a CSP on a Windows system.

When using AES encryption for ECMA-376 documents [ECMA-376], the Microsoft Enhanced RSA and AES Cryptographic Provider is written into the header, unless AES encryption facilities are obtained from an alternate cryptographic provider as noted in the next paragraph. When using CryptoAPI RC4 encryption, be aware that the Microsoft Base Cryptographic Provider v1.0 is limited to 56-bit key lengths. The other providers listed support up to 128-bit key lengths.

Other cryptographic providers can be used, but documents specifying other providers will not open properly if the cryptographic provider is not present. On a non-Windows system, the cryptographic provider will be ignored when opening a file, and the algorithm and key length will be determined by the EncryptionHeader.AlgID and EncryptionHeader.KeySize fields. When writing a file from a non-Windows system, a correct cryptographic provider needs to be supplied for implementations on Windows systems to properly open the file.

Additionally, a ProviderType parameter is required for an EncryptionHeader structure that is compatible with the CSP and encryption algorithm chosen. To facilitate interoperability, the ProviderTypes listed in section 2.3.2 are recommended.

Additionally, see section 4.1.3 for additional information regarding the cryptography used.

<9> Section 2.3.4.5:  Office 2003 applications set a Version.vMajor version value of 0x0002.  Applications in the 2007 Office system and Microsoft Office 2007 Service Pack 1 (SP1) set a Version.vMajor value of 0x0003. Versions Microsoft Office 2007 Service Pack 2 (SP2), Office 2010 and Office 2013 set a Version.vMajor value of 0x0004.

<10> Section 2.3.4.5:  In the 2007 Office system, Office 2010 and Office 2013, the default encryption algorithm for ECMA-376 standard encryption documents [ECMA-376] is 128-bit AES, and both 192-bit and 256-bit AES are also supported. It is possible to use alternate encryption algorithms, and for best results, a block cipher supporting ECB mode is recommended. Additionally, the algorithm ought to convert one block of plaintext to one block of encrypted data, where both blocks are the same size. This information is for guidance only, and it is possible that if alternate algorithms are used, the applications in the 2007 Office system, Office 2010 and Office 2013 might not open the document properly or that information leakage could occur.

<11> Section 2.3.4.5:  In the 2007 Office system, Office 2010 and Office 2013, the default encryption algorithm for ECMA-376 standard encryption documents [ECMA-376] is 128-bit AES, and both 192-bit and 256-bit AES are also supported. It is possible to use alternate encryption algorithms, and for best results, a block cipher supporting ECB mode is recommended. Additionally, the algorithm ought to convert one block of plaintext to one block of encrypted data, where both blocks are the same size. This information is for guidance only, and it is possible that if alternate algorithms are used, the applications in the 2007 Office system, Office 2010 and Office 2013 might not open the document properly or that information leakage could occur.

<12> Section 2.3.4.6:  On Windows XP, Windows Vista, Windows 7, Windows 8 and Windows 8.1, CSPName specifies the GUID of the extensible encryption module used for this file format. This GUID specifies the CLSID of the COM module containing cryptographic functionality. The CSPName is required to be a null-terminated Unicode string.

<13> Section 2.3.4.10:  The use of RC2 is not recommended. If RC2 is used with a key length of less than 128 bits, documents could interoperate incorrectly across different operating system versions.

<14> Section 2.3.4.10:  The use of DES is not recommended. If DES is used, the key length specified in the KeyBits element is required to be set to 64 for 56-bit encryption, and the key decrypted from encryptedKeyValue of KeyEncryptor is required to include the DES parity bits.

<15> Section 2.3.4.10:  The use of DESX is not recommended. If DESX is used, documents could interoperate incorrectly across different operating system versions.

<16> Section 2.3.4.10:  If 3DES or 3DES_112 is used, the key length specified in the KeyBits element is required to be set to 192 for 168-bit encryption and 128 for 112-bit encryption, and the key decrypted from encryptedKeyValue of KeyEncryptor is required to include the DES parity bits.

<17> Section 2.3.4.10:  If 3DES or 3DES_112 is used, the key length specified in the KeyBits element is required to be set to 192 for 168-bit encryption and 128 for 112-bit encryption, and the key decrypted from encryptedKeyValue of KeyEncryptor is required to include the DES parity bits.

<18> Section 2.3.4.10:  Any algorithm that can be resolved by name by the underlying operating system can be used for hashing or encryption. Only block algorithms are supported for encryption. AES-128 is the default encryption algorithm, and SHA-1 is the default hashing algorithm if no other algorithms have been configured.

<19> Section 2.3.4.10:  Any algorithm that can be resolved by name by the underlying operating system can be used for hashing or encryption. Only block algorithms are supported for encryption. AES-128 is the default encryption algorithm, and SHA-1 is the default hashing algorithm if no other algorithms have been configured.

<20> Section 2.3.4.10:  All ECMA-376 documents [ECMA-376] encrypted by Microsoft Office using agile encryption will have a DataIntegrity element present. The schema allows for a DataIntegrity element to not be present because the encryption schema can be used by applications that do not create ECMA-376 documents [ECMA-376].

<21> Section 2.3.5.1:  Office 2003 applications set a Version.vMajor version of 0x0002.  Applications in the 2007 Office system and Office 2007 SP1 set a Version.vMajor value of 0x0003. Versions such as Office 2007 SP2, Office 2010 and Office 2013set a Version.vMajor value of 0x004.

<22> Section 2.3.5.1:  Several of the cryptographic techniques specified in this document use the Cryptographic Application Programming Interface (CAPI) or CryptoAPI when implemented by Microsoft Office on the Windows operating systems. While an implementation is not required to use CryptoAPI, if an implementation is required to interoperate with Microsoft Office on the Windows operating systems, the following are required:

Cryptographic service provider (CSP): A CSP refers to a library containing implementations of cryptographic algorithms. Several CSPs that support the algorithms required in this specification are present by default on the latest versions of Windows. Alternate CSPs can be used, if the CSP is installed on all systems consuming or producing a document.

AlgID: An integer representing an encryption algorithm in the CryptoAPI. Required AlgID values are specified in the remainder of this document. Alternate AlgIDs can be used if the CSP supporting the alternate AlgID is installed on all systems consuming or producing a document.

AlgIDHash: An integer representing a hashing algorithm in the CryptoAPI. Required AlgIDHash values are specified in the remainder of this document. For encryption operations, the hashing algorithm is fixed and cannot vary from the algorithms specified.

The following cryptographic providers are recommended to facilitate interoperability across all supported versions of Windows:

  • Microsoft Base Cryptographic Provider v1.0

  • Microsoft Enhanced Cryptographic Provider v1.0

  • Microsoft Enhanced RSA and AES Cryptographic Provider

Note that the following providers are equivalent:

  • Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)

  • Microsoft Enhanced RSA and AES Cryptographic Provider

The provider listed as "Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)" is found on Windows XP. An implementation needs to treat these providers as equivalent when attempting to resolve a CSP on a Windows system.

When using AES encryption for ECMA-376 documents [ECMA-376], the Microsoft Enhanced RSA and AES Cryptographic Provider is written into the header, unless AES encryption facilities are obtained from an alternate cryptographic provider as noted in the next paragraph. When using CryptoAPI RC4 encryption, be aware that the Microsoft Base Cryptographic Provider v1.0 is limited to 56-bit key lengths. The other providers listed support up to 128-bit key lengths.

Other cryptographic providers can be used, but documents specifying other providers might not open properly if the cryptographic provider is not present. On a non-Windows system, the cryptographic provider will be ignored when opening a file, and the algorithm and key length will be determined by the EncryptionHeader.AlgID and EncryptionHeader.KeySize fields. When writing a file from a non-Windows system, a correct cryptographic provider needs to be supplied for implementations on Windows systems to properly open the file.

Additionally, a ProviderType parameter is required for an EncryptionHeader structure that is compatible with the CSP and encryption algorithm chosen. To facilitate interoperability, the ProviderTypes listed in section 2.3.2 are recommended.

Additionally, see section 4.1.3 for additional information regarding the cryptography used.

<23> Section 2.3.5.4:  Office 2003, the 2007 Office system, Office 2010 and Office 2013 allow the user to optionally encrypt the \0x05SummaryInformation and \0x05DocumentSummaryInformation streams. Additional streams and storages can also be encrypted within the RC4 CryptoAPI summary stream.

<24> Section 2.4.1:  Documents generated by Microsoft Office Excel 2007, Microsoft Excel2010 and Microsoft Excel 2013 can be encrypted as specified in section 2.3 with the following password: "\x56\x65\x6C\x76\x65\x74\x53\x77\x65\x61\x74\x73\x68\x6F\x70". The conditions under which this password is used are described in [MS-XLS] and [MS-XLSB].

<25> Section 2.4.2.2:  Documents generated by Office Excel 2007, Excel 2010 and Excel 2013 can be encrypted as specified in section 2.3 with the following password: "\x56\x65\x6C\x76\x65\x74\x53\x77\x65\x61\x74\x73\x68\x6F\x70". The conditions under which this password is used are described in [MS-XLS] and [MS-XLSB].

<26> Section 2.4.2.3: Documents created by Microsoft Office PowerPoint 2003, Microsoft Office PowerPoint 2007 and Microsoft Office PowerPoint 2007 Service Pack 1 use the default password. Microsoft Office PowerPoint 2007 Service Pack 2 does not use the default password. A document created without the default password can be opened in earlier versions. Due to security concerns, it is preferable not to use the default password.

<27> Section 2.4.2.4:  Any algorithm that can be resolved by name by the underlying operating system can be used for hashing or encryption. Only block algorithms are supported for encryption. AES-128 is the default encryption algorithm, and SHA-1 is the default hashing algorithm if no other algorithms have been configured.

<28> Section 2.5.2.1:  In the 2007 Office system, the SHA-1 hashing algorithm is required to be used for this purpose. Office 2010 and Office 2013 require only that the underlying operating system support the hashing algorithm.

<29> Section 2.5.2.1:  In the 2007 Office system, the SHA-1 hashing algorithm is required to be used for this purpose. Office 2010 and Office 2013 require only that the underlying operating system support the hashing algorithm.

<30> Section 2.5.2.4:  In the 2007 Office system, the SHA-1 hashing algorithm is required to be used for this purpose. Office 2010 and Office 2013 versions require only that the underlying operating system support the hashing algorithm.

<31> Section 2.5.2.5:  Office 2010, Office 2013 and the 2007 Office system reserve the value of {00000000-0000-0000-0000-000000000000} for their default signature providers and {000CD6A4-0000-0000-C000-000000000046} for their East Asian signature providers.

<32> Section 2.5.2.6:  Office 2010 and Office 2013 adds XML Advanced Electronic Signatures ([XAdES]) extensions to xmldsig signatures when configured to do so by the user. By default, XAdES-EPES signatures are used, as specified in [XAdES] section 4.4.2.

<33> Section 2.5.2.6:  By default, Office 2010 and Office 2013 places the reference to the SignedProperties element within the SignedInfo element. the 2007 Office system needs an update to correctly validate a reference within the SignedInfo element that is not to a top-level Object element, and incorrectly rejects these signatures as invalid. To ensure compatibility with earlier versions of Office that have not been updated to validate the signature correctly, an implementation can place the Reference element within a manifest.