Basic requirements for ciphers
The encrypted message must be readable only if the key is present.
The number of operations required to determine the used encryption key from the fragment of the encrypted message and the corresponding plaintext must not be less than the total number of possible keys;
The number of operations required to decrypt information by searching through all possible keys must have a strict lower estimate and go beyond the capabilities of modern computers (taking into account the possibility of using network computing);
knowledge of the encryption algorithm should not affect the reliability of protection
a slight change in the key should lead to a significant change in the form of the encrypted message even when the same source text is encrypted;
a slight change in the source text should lead to a significant change in the form of the encrypted message even when using the same key;
Structural elements of the encryption algorithm must be unchanged;
additional bits introduced into the message during the encryption process must be completely and securely hidden in the ciphertext;
The length of the ciphertext must be equal to the length of the original text;
· there should be no simple and easily established dependencies between the keys sequentially used in the encryption process;
any key from the set of possible ones must provide reliable protection of information;
The algorithm should allow both software and hardware implementation, while changing the key length should not lead to a qualitative deterioration of the encryption algorithm.
Software implementations of ciphers
The possibility of software implementation is due to the fact that all cryptographic transformation methods are formal and can be represented as a finite algorithmic procedure.
To the virtues software implementation can be attributed to its flexibility and portability. In other words, a program written for one operating system can be modified for any type of operating system. In addition, you can update the software with less time and cost. In addition, many modern achievements in the field of cryptographic protocols are not available for implementation in the form of hardware.
To disadvantages cryptographic protection software should include the possibility of interfering with the operation of encryption algorithms and gaining access to key information stored in public memory. These operations are usually performed using a simple set of software tools. For example, in many operating systems, a memory crash dump is performed on a hard disk, while there may be keys in memory that are not difficult to find.
Thus, the weak physical security of software is one of the main disadvantages of such methods for implementing encryption algorithms.
Hardware and software implementation
Recently, combined encryption tools have begun to appear, the so-called. software and hardware. In this case, a kind of "cryptographic coprocessor" is used in the computer - a computing device focused on performing cryptographic operations (modulo addition, shift, etc.). By changing the software for such a device, you can choose one or another encryption method.
The main functions assigned to the hardware of the hardware-software complex of cryptographic information protection are usually the generation of key information and its storage in devices protected from unauthorized access by an intruder. In addition, using techniques of this type, it is possible to authenticate users using passwords (static or dynamically changing, which can be stored on various carriers of key information), or based on biometric characteristics unique to each user. A device for reading such information may be part of the software and hardware implementation of information security tools.
Microsoft Office 2010 contains options that allow you to control which data is encrypted when using Microsoft Access 2010, Microsoft Excel 2010, Microsoft OneNote 2010, Microsoft PowerPoint 2010, Microsoft Project 2010, and Microsoft Word 2010. This article discusses cryptography and encryption in Office 2010, describing capabilities settings for data encryption and providing compatibility information with previous versions of Microsoft Office.
As you plan your encryption options, consider the following guidelines:
- We recommend that you do not make changes to the default encryption settings unless your organization's security model requires encryption settings that differ from the defaults.
- We recommend using a password length and complexity to ensure that strong passwords are used when encrypting data.
- We recommend you not use RC4 encryption.
- There's no administrative setting that allows you to force users to do document encryption. However, there is an administrative setting that allows you to remove the ability to add passwords for documents and thus prevent documents from being encrypted.
- Saving documents in trusted locations does not affect encryption settings. If the document is encrypted and stored in a secure location, the user must provide a password to open the document.
In this article:
About cryptography and encryption in Office 2010
The encryption algorithms available for use with Office depend on the algorithms that can be accessed through an API (Application Programming Interface) in the Windows operating system. Office 2010, in addition to providing support for the Cryptography API (CryptoAPI), also includes support for CNG (CryptoAPI: Next Generation), which was first introduced in the 2007 Microsoft Office system Service Pack 2 (SP2).
CNG allows more flexible encryption, where you can specify algorithms that support different encryptions and hashes on the host computer to use during the document encryption process. CNG also allows for better extensibility of encryption where third-party encryption modules can be used.
When Management uses the CryptoAPI, the encryption algorithms are dependent on those who supply the CSP (Cryptography Service Provider), which is part of the Windows operating system. The following registry key contains a list of CSPs installed on the computer:
HKEY_LOCAL_MACHINE/software/Microsoft/encryption/default/provider
The following CNG encryption algorithms, or any other CNG extension ciphers installed on the system, can be used with Office 2010 or the 2007 Office SP2 system:
AES, DES, DESX, 3DES, 3DES_112 and RC2
The following CNG hash algorithms, or any other CNG cipher extensions installed on the system, can be used with Office 2010 or the 2007 Office system SP2:
MD2, MD4, MD5, RIPEMD-128, RIPEMD-160, SHA-1, SHA256, SHA384 and SHA512
While there are Office 2010 options for changing how encryption is performed, when encrypting Open XML format files (.docx, .xslx, .pptx, etc.) the default values are AES (Advanced Encryption Standard), 128-bit long key, SHA1, and CBC (cipher block chaining) - provide strong encryption and should be fine for most organizations. AES encryption is the strongest standard algorithm available and has been selected by the National Security Agency (NSA) to be used as the standard by the United States government. AES encryption is supported on Windows XP SP2, Windows Vista, Windows 7, Windows Server 2003 and Windows Server 2008.
Cryptography and Encryption Options
The following table lists the options that are available for changing encryption algorithms when using the version of Microsoft Office that is available for the CryptoAPI. This includes Office versions up to and including Office 2010.
|
Setting |
Description |
| Encryption type for password-protected Office Open XML files | This option allows you to set the encryption type for Open XML files from available Cipher Service Providers (CSPs). This setting is required when using custom COM add-in encryption. For more information, see the "2007 Office System Encryption Developer's Guide," which is available as part of the Sharepoint Server 2007 sdk. This setting is required if you are using the 2007 Office system SP1 or are using a version of the Compatibility Pack that is older than the Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint file formats and you want to change the encryption algorithm to something other than the default. |
| Encryption type for password-protected Office 97-2003 files | This option allows you to set the encryption type for Office 97-2003 files (binary) from available cryptographic services (CSP). The only supported algorithm when using this option is RC4, which, as mentioned earlier, we do not recommend. |
In Office 2010, if you want to change the setting encryption type for password-protected Office Open XML files, you first need to enable the option encryption compatibility please specify and select an option use legacy format. Parameter specify encryption compatibility available for Access 2010, Excel 2010, PowerPoint 2010 and Word 2010.
The following table lists the options that are available for changing encryption algorithms when using Office 2010. These options apply to Access 2010, Excel 2010, OneNote 2010, PowerPoint 2010, Project 2010, and Word 2010.
|
Setting |
Description |
| Setting the CNG Encryption Algorithm | This setting allows you to customize the CNG encryption algorithm that is used. The default is AES. |
| Customize LNG cipher clutch mode | This setting allows you to configure the cipher, chaining mode used. The default is Cipher block chaining (CBC). |
| Set LNG Encryption Key Length | This option allows you to configure the number of bits to use when generating the encryption key. The default value is 128 bits. |
| Set Compatibility Encryption | This option allows you to specify the compatibility format. Default value - use next generation format. |
| Setting parameters for the CNG context | This option allows you to specify the encryption options to be used for the LNG context. To use this option, the CNG context must first be created using CryptoAPI: Next Generation (CNG). |
| Set LNG hashing algorithm | This option allows you to specify the hashing algorithm to use. The default value is SHA1. |
| Set a password for LNG scrolls | This option allows you to specify the number of times to spin (paraphrase) the password check. The default is 100000. |
| Specify CNG Random Number Generation Algorithm | This option allows you to configure the CNG Random Number Generator to use. The default is RNG (Random Number Generator). |
| Specify LNG Salt Length | This option allows you to specify the number of bytes salt that should be used. The default value is 16. |
In addition to the CPG options that were listed in the previous table, the CPG option that is listed in the following table can be configured for Excel 2010, PowerPoint 2010, and Word 2010.
You can use the options listed in the following table to remove the ability to add passwords to documents and thus prevent documents from being encrypted.
Compatibility with previous versions of Office
If you have to encrypt Office documents, we recommend that you save documents as Open XML format files (.docx, .xlsx, .pptx, etc.) instead of Office 97-2003 format (.doc, .xls, . ppt and so on). The encryption that is used for binary documents (.doc, .xls, .ppt) uses RC4. This is not recommended, as stated in sections 4.3.2 and 4.3.3 for security reasons, the Office Specification Structure Cryptography document. Documents saved in older binary Office formats can only be encrypted using RC4 to maintain compatibility with earlier versions of Microsoft Office. AES, the recommended algorithm, and the default for encrypting Open XML format files.
Office 2010 and the 2007 Office system allow you to save documents as Open XML files. Additionally, if you have Microsoft Office XP or Office 2003, you can use the Compatibility Pack to save documents as Open XML format files.
Documents that are saved as Open XML format files and encrypted by Office 2010 can only be read by Office 2010, Office 2007 SP2, and Office 2003 with the Office 2007 SP2 Compatibility Pack. To ensure compatibility with all previous versions Office, you can create a registry key (if it doesn't exist) under HKCU\Software\Microsoft\Office\14.0\
If your organization uses the Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint file formats to encrypt Open XML format files, you should consider the following information:
- By default, the Compatibility Pack for Encrypting Open XML Files uses the following options:
- ExtensionMicrosoftRSAAndAEScrypto provider (prototype),AES 128,128 (on Windows XP Professional operating system).
- ExtensionMicrosoftRSAAndAEScryptographic service providerAES 128,128 (on Windows Server 2003 and Windows Vista operating systems).
- Users are not notified that the Compatibility Pack is using these encryption options.
- The GUI in earlier versions of Office may display incorrect encryption options for Open XML format files if the Compatibility Pack is installed.
- Users cannot use the GUI in earlier versions of Office to change encryption settings for Open XML format files.
Encrypting file system
The Encrypting File System is a service that is tightly integrated with NTFS and resides in the Windows 2000 kernel. Its purpose is to protect data stored on a disk from unauthorized access by encrypting it. The appearance of this service is not accidental, and was expected for a long time. The fact is that the file systems that exist today do not provide the necessary protection of data from unauthorized access.
An attentive reader may object to me: what about Windows NT with its NTFS? After all, NTFS provides access control and data protection from unauthorized access! Yes it's true. But what if the NTFS partition is accessed not through the Windows NT operating system, but directly, at the physical level? After all, this is relatively easy to implement, for example, by booting from a floppy disk and running a special program: for example, the very common ntfsdos. A more sophisticated example is the NTFS98 product. Of course, you can provide for this possibility and set a password to start the system, but practice shows that such protection is ineffective, especially when several users work on the same computer at once. And if an attacker can remove the hard drive from the computer, then no passwords will help here. By connecting the drive to another computer, its contents can be read with the same ease as this article. Thus, an attacker can freely take possession of confidential information that is stored on the hard drive.
The only way to protect against physical reading of data is to encrypt files. The simplest case of such encryption is archiving a file with a password. However, there are a number of serious shortcomings here. Firstly, the user needs to manually encrypt and decrypt (that is, in our case, archive and unarchive) data each time before and after work, which in itself reduces data security. The user may forget to encrypt (archive) the file after the end of work, or (even more banally) simply leave a copy of the file on disk. Secondly, user-created passwords are usually easy to guess. In any case, there are a sufficient number of utilities that allow you to unpack password-protected archives. As a rule, such utilities carry out password guessing by enumeration of the words recorded in the dictionary.
The EFS system was designed to overcome these shortcomings. In the following, we'll take a closer look at the details of encryption technology, EFS user interaction, and data recovery methods, get to know the theory and implementation of EFS in Windows 2000, and look at an example of encrypting a directory using EFS.
Encryption technology
EFS uses the Windows CryptoAPI architecture. It is based on public key encryption technology. To encrypt each file, a file encryption key is randomly generated. In this case, any symmetric encryption algorithm can be used to encrypt the file. EFS currently uses one algorithm, DESX, which is a special modification of the widely used DES standard.
EFS encryption keys are stored in a resident storage pool (EFS itself is located in the Windows 2000 kernel), which prevents unauthorized access to them through the page file.
User interaction
By default, EFS is configured so that the user can immediately start using file encryption. The encryption operation and the reverse are supported for files and directories. If a directory is encrypted, all files and subdirectories of this directory are automatically encrypted. It should be noted that if an encrypted file is moved or renamed from an encrypted directory to an unencrypted one, it will still remain encrypted. Encryption/decryption operations can be performed in two different ways - using Windows Explorer or the Cipher console utility.
In order to encrypt a directory from within Windows Explorer, the user simply needs to select one or more directories and check the encryption box in the directory's advanced properties window. All files and subdirectories created later in this directory will also be encrypted. Thus, you can encrypt a file simply by copying (or moving) it to an "encrypted" directory.
Encrypted files are stored on disk in encrypted form. When reading a file, the data is automatically decrypted, and when writing, it is automatically encrypted. The user can work with encrypted files in the same way as with regular files, that is, open and edit documents in the Microsoft Word text editor, edit drawings in Adobe Photoshop or the Paint graphics editor, and so on.
It should be noted that in no case should you encrypt files that are used at system startup - at this time, the user's private key, with which decryption is performed, is not yet available. This may cause the system to be unable to start! EFS provides a simple protection against such situations: files with the "system" attribute are not encrypted. However, be careful: this can create a "hole" in the security system! Check if the file attribute is set to "system" to make sure the file will actually be encrypted.
It is also important to remember that encrypted files cannot be compressed using Windows 2000 and vice versa. In other words, if a directory is compressed, its contents cannot be encrypted, and if the contents of a directory are encrypted, then it cannot be compressed.
In the event that data decryption is required, you just need to uncheck the encryption boxes for the selected directories in Windows Explorer, and the files and subdirectories will be automatically decrypted. It should be noted that this operation is usually not required, since EFS provides a "transparent" operation with encrypted data for the user.
Data recovery
EFS provides built-in support for recovering data in case it needs to be decrypted, but for some reason this cannot be done normally. By default, EFS will automatically generate a recovery key, install an access certificate in the administrator account, and store it on first login. Thus, the administrator becomes a so-called recovery agent, and will be able to decrypt any file in the system. Of course, the data recovery policy can be changed, and a special person responsible for data security, or even several such persons, can be appointed as a recovery agent.
A bit of theory
EFS encrypts data using a shared key scheme. The data is encrypted with a fast symmetric algorithm using the file encryption key (FEK). FEK is a randomly generated key of a certain length. The key length in the North American version of EFS is 128 bits, in the international version of EFS a reduced key length of 40 or 56 bits is used.
The FEK is encrypted with one or more shared encryption keys, resulting in a list of encrypted FEKs. The list of encrypted FEK keys is stored in a special EFS attribute called DDF (data decryption field). The information that is used to encrypt data is hardwired to this file. The shared keys are derived from the user's X509 certificate key pairs, with the additional option of using "File encryption". The private keys from these pairs are used to decrypt the data and the FEK. The private part of the keys is stored either on smart cards or in another secure place (for example, in memory, which is secured using CryptoAPI).
The FEK is also encrypted using one or more recovery keys (obtained from the X509 certificates recorded in the Encrypted Data Recovery Policy for this computer, with the "File recovery" option added).
As in the previous case, the common part of the key is used to encrypt the FEK list. The list of encrypted FEK keys is also stored along with the file in a special EFS area called DRF (data recovery field). Only the common part of each key pair is used to encrypt the FEK list in DRF. Only shared recovery keys are needed for normal file operations. Recovery agents can store their private keys in a secure location off the system (for example, on smart cards). The figure shows diagrams of the processes of encryption, decryption and data recovery.
Encryption process
The unencrypted user file is encrypted with a randomly generated FEK. This key is written with the file, the file is decrypted using the user's public key (recorded in the DDF) and also using the recovery agent's public key (recorded in the DRF).
Decryption process
First, the user's private key is used to decrypt the FEK - for this, the encrypted version of the FEK is used, which is stored in the DDF. The decrypted FEK is used to decrypt the file block by block. If blocks are not read sequentially in a large file, then only readable blocks are decrypted. The file remains encrypted.
Recovery process
This process is similar to decryption, with the difference that the recovery agent's private key is used to decrypt the FEK, and the encrypted version of the FEK is taken from the DRF.
Implementation in Windows 2000
The figure shows the EFS architecture:
EFS consists of the following components:
EFS driver
This component sits logically on top of NTFS. It interacts with the EFS service, obtains file encryption keys, DDF, DRF fields, and other key management data. The driver passes this information to the FSRTL (file system runtime library) to transparently perform various file system operations (for example, open a file, read, write, append data to the end of a file).
EFS Runtime Library (FSRTL)
FSRTL is a module within the EFS driver that makes external NTFS calls to perform various file system operations such as reading, writing, opening encrypted files and directories, as well as encryption, decryption, recovery operations when writing to disk and reading from disk. Although the EFS driver and FSRTL are implemented as a single component, they never interact directly. They use the NTFS call mechanism to exchange messages with each other. This ensures that NTFS participates in all file operations. Operations implemented using file management mechanisms include writing data to EFS file attributes (DDF and DRF) and passing EFS-computed FEK keys to the FSRTL library, since these keys must be set in the file open context. This file open context then allows silent encryption and decryption of files when files are written to and read from disk.
EFS service
The EFS service is part of the security subsystem. It uses the existing LPC communication port between the LSA (Local security authority) and the kernel-mode security monitor to communicate with the EFS driver. In user mode, EFS interacts with the CryptoAPI to provide file encryption keys and generate DDF and DRF. In addition, EFS provides support for the Win32 API.
Win32 API
Provides a programming interface for encrypting open files, decrypting and restoring closed files, receiving and transmitting closed files without first decrypting them. Implemented as a standard system library advapi32.dll.
A little practice
To encrypt a file or directory, do the following:
- Launch Windows Explorer, right-click on the directory, select Properties.
- On the General tab, click the Advanced button.
- Check the box "Encrypt contents to secure data". Click OK, then click Apply in the Properties dialog. If you have chosen to encrypt an individual file, the following dialog box will additionally appear:
The system offers to encrypt the directory containing the selected file as well, otherwise the encryption will be automatically canceled the first time such a file is modified. Always keep this in mind when encrypting individual files!
This completes the data encryption process.
To decrypt the directories, simply deselect the "Encrypt contents to secure data" box. The directories, as well as all subdirectories and files contained in them, will be decrypted.
conclusions
- The EFS system in Windows 2000 provides users with the ability to encrypt NTFS directories using a strong, pre-shared key cryptographic scheme, with all files in the private directories encrypted. Single file encryption is supported, but not recommended due to unpredictable application behavior.
- EFS also supports encryption of remote files that are accessed as shared resources. If there are user profiles for the connection, the keys and certificates of the remote profiles are used. In other cases, local profiles are generated and local keys are used.
- EFS provides a way to set a data recovery policy so that encrypted data can be recovered using EFS if required.
- The data recovery policy is built into the Windows 2000 General Security Policy. Enforcement of the recovery policy can be delegated to authorized individuals. Each organizational unit can have its own data recovery policy configured.
- Data recovery in EFS is a private operation. The recovery process decrypts the data, but not the user key with which the data was encrypted.
- Working with encrypted files in EFS does not require the user to take any special steps to encrypt and decrypt data. Decryption and encryption occur transparently to the user in the process of reading and writing data to disk.
- The EFS system supports backing up and restoring encrypted files without decrypting them. NtBackup supports backing up encrypted files.
- The EFS system is built into the operating system in such a way that it is impossible to leak information through swap files, while guaranteeing that all copies created will be encrypted
- Numerous precautions are in place to ensure the security of data recovery, as well as protection against leakage and loss of data in the event of a fatal system failure.
21.06.2011 Vladimir Bezmaly
A lot has been written about the benefits of switching to Office 2010, and I think it's not worth repeating all the arguments. Today I would like to talk about the benefits of such a transition in terms of the security of encrypted documents.
To begin with, let's recall how Microsoft Word documents were protected in Microsoft Office.
The past and present of encryption in Office
In Office, up to and including version 6.0, the first encryption algorithm was plain XOR. Of course, such a simple encryption algorithm did not provide any protection, and any passwords were recovered almost instantly. It is quite natural that the corresponding programs for hacking Microsoft Word and Microsoft Excel appeared almost immediately. Moreover, as one of the authors of such programs noted, a false sense of security is much worse than its absence. And he asked Microsoft to improve the protection in Office.
This was done in subsequent versions of Microsoft Office 97 and 2000. These products used strong MD5 and RC4 cryptographic algorithms. However, due to the US export restrictions on strong cryptography at the time, cryptographic algorithms used outside the US could not use keys longer than 40 bits. This led to an artificial limitation of RC4 keys to 40 bits, and, therefore, out of 16 bytes received at the output of MD5, 11 were simply overwritten to 0, and the RC4 key was formed from 5 significant bytes and 11 zeros. This led to the possibility of organizing a brute force attack. To decrypt a MS Word/Excel 97/2000 file, you need to enumerate a maximum of 240 keys.
Given the appearance of key tables (Rainbow tables), the desired attack can be performed in a limited time (from several seconds to several minutes). Moreover, Internet sites have appeared that provide such services, such as www.decryptum.com (the cost of decrypting one file is $29); software Guaranteed Word Decrypter (GuaWord) 1.7, Guaranteed Excel Decryptor (GuaExcel) 1.7 (manufacturer PSW-soft), Advanced Office Password Breaker (AOPB), Advanced Office Password Recovery (AOPR) (manufacturer Elcomsoft).
In Microsoft Office XP/2003, the same algorithm with a 40-bit key was left as the default encryption algorithm. However, the following changes have been made:
- hashing algorithm SHA1 (instead of MD5);
- the RC4 key can be up to 128 bits long;
- password length increased from 16 to 255 characters.
Another thing is that in any case, the encryption and password verification scheme used allows for a high brute force rate (up to 1,000,000 passwords per second), as shown in Figure 1.
Office 2007 introduced a new encryption scheme to combat high password brute force rates. It has fundamental differences from the previous version:
- the RC4 algorithm was replaced by the AES encryption algorithm with a key length of 128 bits;
- instead of hashing once, the password is hashed cyclically 50 thousand times;
- use of third-party encryption algorithms is possible.
As a result of the measures taken, the password brute force rate is no more than 200 passwords per second, which makes it possible to guess passwords no longer than 5–6 characters in a reasonable time.
At the same time, it is worth emphasizing that with the advent of software that uses the resources of a video card, the brute force speed increases to 5 thousand passwords per second, which in any case is clearly not enough for a full-fledged brute force attack (screen 2).
.jpg) |
| Figure 2. Brute-force attack based on graphics card resources |
As for the format of protected files, it cannot be called simple and understandable. After all, if a password is set to open a file, then in fact the file is an OLE container consisting of information about encryption, an encrypted stream, and auxiliary information. However, despite the fact that, like the encryption block in Office XP/2003, it contains the name of the cryptographic provider, the names of the hashing and encryption algorithms, as well as the key length and data for password verification and decryption, the following parameters are hard-coded in Office 2007:
- AES encryption algorithm with a key length of 128 bits;
- SHA-1 hashing algorithm.
At the same time, encryption and hashing are provided by the Microsoft Enhanced RSA and AES Cryptographic Provider. At the same time, it should be taken into account that during a brute-force attack, the brute-force speed drops catastrophically.
The algorithm for checking passwords for protecting a document from changes with read-only access, as well as workbooks and Excel sheets, has also changed. Previously, the password hash was stored in the document, consisting of 2 bytes. Accordingly, it was possible to reverse it to the first suitable password. Now the hashing algorithm is defined by an entry in the XML file and the number of hash iterations is also defined there.
Document protection options
Document protection settings allow you to change how files and text are encrypted using the password protection feature. There are two types of document protection options:
- global settings that apply to Office Excel 2007, Office PowerPoint 2007, and Office Word 2007. The two global document protection settings are described in Table 1;
- Application-specific settings that apply only to Microsoft Office OneNote 2007.
These settings can be found either on the Edit User Settings page of the OCT, under 2007 Microsoft Office System, Security Options, or under the User Configuration/Administrative Templates Group Policy Object Editor node, under Microsoft System Office 2007/Security Options".
Privacy settings
Privacy settings help protect private and sensitive information. We can use four main categories of privacy settings in Office 2007. The settings can be configured in the OCT or through Group Policy. The four categories of privacy settings are described below.
The Document Inspector setting is shown in Table 2.
The CLSID for the inspector module can be found in the registry entries found in the following registry keys:
HKEY_LOCAL_MACHINE/Software/ Microsoft/Office/12.0/Excel/ Document Inspectors HKEY_LOCAL_MACHINE/Software/ Microsoft/Office/12.0/PowerPoint/ Document Inspectors HKEY_LOCAL_MACHINE/Software/ Microsoft/Office/12.0/Word/ Document Inspectors
The Document Inspector option can be found on the Edit User Options page of the Office Customization Tool: 2007 Microsoft Office System (Computer)/Other.
Alternatively, you can find this setting in the Group Policy Object Editor: Computer Configuration/Administrative Templates/Microsoft Office 2007 (Computer)/Other.
Encryption in Office 2010. The encryption algorithms used in Microsoft Office 2010 depend on the algorithms that can be accessed through APIs in the Windows operating system. Office 2010, in addition to supporting the Cryptography API (CryptoAPI), also supports the CNG (CryptoAPI: Next Generation) interface, which was first made available in Microsoft Office 2007 Service Pack 2 (SP2).
It is worth considering that using CNG, you can achieve more dynamic encryption and use third-party modules. When Office uses the CryptoAPI, the encryption algorithms depend on the algorithms available in the Cryptographic Service Provider (CSP) that is included with the Windows operating system.
The list of cryptographic service providers installed on the computer is contained in the following registry key:
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Cryptography/Defaults/Provider
In Office 2010 and Office 2007 SP2, you can use the following CNG encryption algorithms and other CNG cryptographic extensions installed on your system: AES, DES, DESX, 3DES, 3DES_112, and RC2. CNG hash algorithms and other CNG cryptographic extensions can be used: MD2, MD4, MD5, RIPEMD-128, RIPEMD-160, SHA-1, SHA256, SHA384, and SHA512.
When encrypting documents in Open XML format (DOCX, XSLX, PPTX, etc.), the default encryption algorithm is AES (the encryption algorithm chosen by the National Security Agency (NSA) as the standard for the U.S. government is supported on operating systems Windows XP with Service Pack 2 (SP2), Windows Vista, Windows 7, Windows Server 2003 and Windows Server 2008) with a key length of 128 bits, the hashing algorithm is SHA1.
Cryptography and encryption options. Table 3 lists the options that allow you to change the encryption algorithms when using versions of Microsoft Office that use the CryptoAPI.
In Office 2010, if you want to change the Encryption Type setting for password-protected Office Open XML files, you must first enable the Set Encryption Compatibility option and select the Use Legacy Format option. The Set Encryption Compatibility option is available in Access 2010, Excel 2010, PowerPoint 2010, and Word 2010.
Table 4 lists the options that allow you to change encryption algorithms when using Office 2010. These options apply to Access 2010, Excel 2010, OneNote 2010, PowerPoint 2010, Project 2010, and Word 2010.
In addition to the CNG options listed in the previous table, for Excel 2010, PowerPoint 2010, and Word 2010, you can configure a CNG option named "Use new key when changing password" that lets you specify whether to use the new encryption key when changing the password. By default, when changing a password, the new key is not used.
The Disable Password to Open UI option can be used to prevent passwords from being added to documents and thereby disable document encryption. This setting controls whether Office 2010 users can add passwords to documents. By default, users can add passwords.
Compatible with previous versions of Office. If you want to encrypt Office documents, we recommend that you save them in the Open XML format (DOCX, XLSX, PPTX, etc.) instead of the Office 97-2003 format (DOC, XLS, PPT, etc.). When encrypting binary documents (DOC, XLS, PPT), the RC4 algorithm is used, which is not recommended! Since the default number of rehash cycles is 100,000, the default password brute-force rate is half that of illegal access to Office 2007 documents.
Thus, we can draw a simple conclusion: in terms of resistance to brute-force attacks, document passwords in Microsoft Office 2010 are by far the most effective.
Vladimir Bezmaly ( [email protected]) - security specialist, MVP Consumer Security, Microsoft Security Trusted Advisor
