Open Document Format (ODF): guidance for UK government

From
Cabinet Office
Updated
, see all updates

Privacy and security

How to ensure your organisation's privacy and security when using ODF document solutions.

Minimise risks to the security of documents

Working with and sharing office documents poses potential risks to the privacy and security of both documents and user systems and accounts.

Threats to document security include:

  • unauthorised interception of an emailed document
  • unauthorised access to a document on a computer, information media or network
  • compromises to content integrity

The main threat to user systems and accounts posed by documents involves macros, which can be used by attackers to take over a user’s computer system and should be avoided.

Open Document Format (ODF) offers 3 ways to minimise risks:

  • document encryption
  • protection locks - ie passwords to restrict certain activities
  • digital signatures that verify a message is authentic - ie sent by the named author and not altered in transit (often used in monetary transactions)

Document encryption

Document encryption completely locks a document from unauthorised users. Users employ the recipient’s public key when composing a message, which they’ll then decrypt using their private key.

When an ODF document is password protected the file structure of the bundle remains the same, but contents (of XML files in package) are encrypted using the following algorithm:

  1. The user-created alphanumeric password is converted into a digest, a single string of digits generated by applying a formula called a one-way hash function to the password.
  2. The local time on the computer is used as seed (ie initialisation) for the production of a random 8-byte initialisation vector (the number used along with the secret key to encrypt data).
  3. This process also produces a 16-byte salt - an additional piece of random data used with the hashed password to create a unique key for each file.
  4. This unique key is then used together with the initialisation vector to encrypt the file in cipher-feedback (CFB) mode (a particular algorithm used to enable encryption). The initialisation vector and salt are both stored in the manifest file.

ODF versions before 1.2 used SHA-1 (a secure hash algorithm) and Blowfish (a symmetric-key block cipher). This combination fails to meet several government security standards (eg FIPS-140).

ODF 1.2 allows other algorithms to be used. For example, Apache OpenOffice (as of version 3.4) and LibreOffice (as of version 3.5) can also use SHA-256 and AES (Advanced Encryption Standard) for encryption. As of early 2015, this combination is considered reasonably secure, as unless someone has the password the document can’t be opened. If you lose or forget the password it’s extremely difficult, if not impossible to recover the document’s contents.

Protection locks

You can also lock specific parts of text with a password to prevent activities such as editing. Once you lock a section, any user attempting to access it will be asked for the password. This is called a protection lock. Protection locks offer only a low level of security because someone with know-how could edit the XML files to bipass the password and access the document. They can, however, prevent users from accidentally altering the text.

Digital signatures

Digital signatures in ODF verify:

  • the authorship of a document
  • the integrity of a document - ie that it hasn’t been modified without authorisation

ODF supports digital signatures using public key technology, so no private passwords need to be exchanged. The author of an ODF document uses their private key to sign it. The recipient uses the author’s public key to check its authorship and integrity.

Digital signatures are reliable, especially when the same software product is used to verify a document as the one used to sign it. Digital signatures in the ODF 1.2 specification are different from the non-standard signatures introduced as extensions by implementations of earlier ODF specifications.

Signing by ODF implementations is performed on the saved document. Any number of signatures can be affixed, by different parties at different times, providing a form of counter-signing.

The standard implementation of digital signatures only confirms authorship and integrity. XAdES (XML Advanced Electronic Signatures) extensions used in ODF digital signatures carry further information about the role of the signer and the purpose of the signature. While few implementations support specification and presentation of the XAdES data, such signatures remain verifiable and XAdES should be used wherever support is available.

Again, consult the guidelines and policies for official documents for:

  • the use of public-key certificates
  • required signing techniques (such as the use of time-stamp systems)
  • the treatment of digitally-signed materials

Save with password

Some ODF-compliant applications allow documents to be saved with an associated password, which must then be entered to view or access the document. This ‘save with password’ feature uses digital encryption as defined in the ODF specification. This offers limited security that’s useful for preventing accidental disclosure of personal documents to others. ‘Save with password’ does not protect related documents, auto-saved files and related files. To protect these files, consider encrypting the hard drive or the section of it containing them.

Protecting individual documents with a password has several weaknesses:

  • if the document creator doesn’t choose a good password it could be guessed or determined using software
  • sharing a password-protected document involves separately sharing the password with the intended viewer/editor; if this isn’t done securely the password could be intercepted.
  • the password could be inadvertently disclosed in another way by the recipient
  • the document’s plaintext could be disclosed by the recipient

Passwords should:

  • not be reused for other purposes - even repeated for the encryption of other documents
  • be strong
  • be created using password-generation utilities if possible

Encryption for ODF documents is inherently insecure because someone with sufficient knowledge of encryption might be able to determine the encryption key (different than but derived from the password) just through access to the encrypted document. With this key and enough determination, an expert in encryption methods could decrypt the document.

Because of these limitations of ODF encryption, sensitive documents (even those graded ‘official’) that are shared or otherwise might be available to third parties should be secured using other measures.

Choose a good password

It’s important to choose a good encryption password. It must be both:

  • complex and not obvious for others to guess
  • simple enough to remember

Don’t use words from any language. If you use a word found in a dictionary, your security will be susceptible to what’s known as a ‘dictionary attack’. Include numbers, punctuation and other symbols throughout your password to improve its security. Longer passwords are more complex and better able to withstand malicious software that systematically checks all possible keys or passwords until the correct one is found.

Work safely in the cloud

Cloud computing involves storing and accessing data and programs over the internet instead of on your computer’s hard drive. If your documents are stored on the server unencrypted or (as is the case with solutions like Google Docs) if your keystrokes leave your browser, their contents should be considered insecure.

The cloud can, however, offer security if you can control where you store the content and can encrypt everything before it leaves the browser. The RemoteStorage open protocol allows users to choose where to house their data, whether with a trusted provider or their own storage server.