| State: | Draft |
|---|---|
| Original Date: | 2011-10-04 |
| Last revised: | 2012-06-13 working draft 9 |
| ODF version(s): | 1.0, 1.1, 1.2 |
|---|---|
| Issue: | OFFICE-3703 |
| Case(s): | n/a |
Summary: Password-associated protection locks on ODF documents are insecure. There is assurance neither of password confidentiality nor of integrity for the protected material. Furthermore, the digital hash used to authenticate the password is usable in forgery and misuse with the same or other documents. This advisory provides means by which users can avoid risky use of passwords while also being able to use protection settings safely.
ODF documents use password hashes as settings for protection-keys. When a protection is locked, the document author specifies a password that is used to discourage removal of the lock. The protection can be removed or reset at a future time by presenting the password again.
The ODF document does not retain the password. Instead, a digital hash of the password is recorded in the document as a protection-key value. A future password entry is accepted if its digital hash matches the one stored as the protection-key value. There is no security around the digital hash values. The hashes can be extracted and also replaced without difficulty. The hash lends no integrity to the lock itself.
The appeal of digital hashes is that the cryptographically-based ones make it difficult to determine the original text the hash is produced from by cryptographic means. It is also extremely unlikely that two texts that have the same digital hash are discoverable by practical means. The digital hash is intended solely to impede discovery of the actual password by some sort of decryption.
However, the password used in creation of an ODF protection-key digital-hash value is vulnerable to discovery because the hash is not itself kept secret. An attacker can use a variety of schemes involving dictionaries of known password+hash combinations, brute-force guessing, and other often-successful schemes for discovering the password. Since the digital hash is in plain sight, it can be attacked repeatedly without interruption using high-performance tools that are crafted for that purpose.
It is important to understand that protection settings are not document-security provisions. Circumvention of document-protection locks is trivial. Furthermore, a password that has a serious security usage must be considered compromised if it is ever used to set document-protection locks. The simple digital hashes used provide an opening to discovery of the valuable password.
The digital hash values that are recorded are also usable in forgery of protected material. The protection-key can be removed, protected material can be altered, and the protection-key and its digital-hash value restored. The digital-hash can also be used to forge protection locks on entirely different documents. No improvement in password confidentiality is of any value in these cases; misappropriation of the digital-hash and alteration of the protection do not depend on knowing the password at all.
The "Save with Password" feature of ODF applications is a document-security provision. It is the only one. However, if the same password is used to also set a protection, the digital hash from that protection can be used to decrypt the same-password-saved document without ever knowing the password. That digital hash can also be used directly in forging encrypted documents (as if they were encrypted by someone knowing the protection password) . The encryption methodology (Blowfish, AES, or anything else) has no bearing. The attack is at a point where a password's digital hash is used as the secret key on which all further stages of the encryption depend.
When creating documents in which protection features are applied, avoid password compromise: do not use a password that is ever used for any other purpose at any other time. Then forget the password:
If the software will create a random protection lock, use that feature. It is unlikely that the lock can be released by entering any password, and guessing will be fruitless. Have an unprotected copy or have a means to break the lock without using a password.
There are many software products that can be used for generating random "strong" passwords. These should be set to generate a reasonably long password (20 characters or more) and the complete range of keyboard-enterable characters should be allowed. Paste a newly-generated password into the password form for setting the lock. Paste again to confirm, if necessary. Then forget.
Alternatively, generate a long password by typing erratically into a plain-text note. Use numbers and special characters. Use something that you are unlikely to type the same way ever again. Don't include any aspect of a memorable password known to you. To avoid inadvertent patterns in the choice of passwords, copy text from a randomly-chosen source, such as a place on a web page or in a book, even a dictionary.
It is probably not worthwhile to invest any more effort in creating a lock than it takes someone to bypass it completely (below). In that case, use a trivial password for which compromise is not an issue because it is never worthy as a true password. Something like "***." Be creative and not so predictable though.
If a document has protections and the password has been lost or was never known, it is possible to remove the protections on the document a number of ways.
First, save the document in an alternative format. Then bring it back. In many cases of conversion (such as from .ods to .xls and back, .odt to .rtf and back), the protection locks are simply removed. This is expedient because the digital hashes used in these separate formats are created by incompatible means; they are not translatable.
If the first technique is unreliable for preserving essential aspects of the document, it is possible to remove locks directly by manipulating the ODF document format. If you are not comfortable with this level of manipulation, find a colleague or family member who has the expertise. They will need
In this procedure, the content.xml file within the Zip is searched and the protection-key attributes are simply renamed. They must be renamed to something that preserves the XML structure. For example, change ":protection-key=" to ":protection-key-xyz="; the ':' and '=' characters are important here. This will remove the locks in all of the places where they are set.. (Note: If the document has text of that form, it may be changed as well, although this is very unlikely, except in a document such as this one represented in ODF.)
It is generally safe to perform a search-replace-all operation. Although the result is not a strictly-valid ODF document, most software will ignore the occurrence of unknown attributes having local name protection-key-xyz. If the substitution fails, it will be necessary to remove all protection-key attributes and their attribute values. That requires more expertise or a utility program designed for this specific purpose.
When the content.xml is modified in this manner, the document can then be opened and the locks will not be set. After making any necessary modifications, the protection can be re-established by setting the locks again using the same procedure recommended for first-time protection; use a new throw-away password..
Note: Some products implement additional protections beyond those offered in the ODF format itself. Examples include "Save as Read-Only" options and locking of tracked-changes settings. These are generally implemented with protection keys in settings.xml. To bypass those protections, simply delete settings.xml in the Zip packaging of the document.