Difference between revisions of "Security/Encryption"

From Apache OpenOffice Wiki
Jump to: navigation, search
Line 10: Line 10:
  
 
In general, an encrypted document shouldn't have any non encrypted content. Exceptions are some files in the META-INF folder: manifest.xml, which is needed to get the encryption information, and the digital signature files also might not be encrypted, depending on the signature implementation.  
 
In general, an encrypted document shouldn't have any non encrypted content. Exceptions are some files in the META-INF folder: manifest.xml, which is needed to get the encryption information, and the digital signature files also might not be encrypted, depending on the signature implementation.  
 +
 +
OOo should show a warning when an encrypted document contains streams which should be encrypted, but aren't. Additionally, macros should be disabled for the document. (issue #XXXXX)
  
 
== Improving the Encryption Implementation in OOo 3.2  ==
 
== Improving the Encryption Implementation in OOo 3.2  ==

Revision as of 10:43, 10 July 2009

Encrypted documents shouldn't have any non encrypted content

Currently it is possible to add any non encrypted content into encrypted documents, simply by putting new streams into the zip archive.

This way, someone could for example add macro code into documents without the need to know the password.

The possibility to add content to an encrypted document is quite bad, and it becomes worse with macros, because passwords increase the level of trust the user has to a document, when it was encrypted by a person he knows.

OOo will detect the macros, and ask the user whether or not to execute them. The user might trust the author of the document, and because of the encryption normally nobody should have been able to manipulate it, so he will probably allow OOo to execute the macros. At least, it's not possible to bind the macros to some event, so it would get executed automatically.

In general, an encrypted document shouldn't have any non encrypted content. Exceptions are some files in the META-INF folder: manifest.xml, which is needed to get the encryption information, and the digital signature files also might not be encrypted, depending on the signature implementation.

OOo should show a warning when an encrypted document contains streams which should be encrypted, but aren't. Additionally, macros should be disabled for the document. (issue #XXXXX)

Improving the Encryption Implementation in OOo 3.2

For OOo 3.2, we plan to improve the document encryption, or better, the handling of documents which have issues like mentioned above (issue #XXXXX).

When OOo opens an encrypted document, it will check via the manifest if all files are encrypted. All encrypted files in a ODF zip archive must use the same encryption key. It is also necessary to check the actual file content, and not the manifest alone. This could be done on access, or in a background process for all files. When detecting not encrypted files, OOo will show a warning to the user, and will not execute any unencrypted macros in encrypted documents.

Enhancing the Encryption Specification for ODF 1.2

Currently the ODF specification specifies one way for encrypting ODF documents, and ODF applications can't chose different algorithms.

Choosing other encryption algorithms can be important, to comply with encryption rules from a company or Government using ODF.

The information about the used algorithms (for each step) need to be documented in the manifest.xml.

This is the latest draft of the proposal that we will send to the OASIS OpenDocument TC:

2.3 Encryption:
The encryption process takes place in the following multiple stages:
  1. The start key is generated and is provided to the package component.
  2. The derived key is generated by the component based on the start key.
  3. The files are encrypted based on the derived key and the encryption algorithm.
The implementation must support at least the described below default way for the mentioned steps. In addition it might support encryption, where algorithms different from the default are used for the steps. The information regarding used for each step algorithms has to be provided in the manifest.xml accordingly.
The default way is:
  1. The start key is generated. The byte sequence representing the password in UTF-8 is used to generate a 20-byte SHA1 digest (see [RFC3174]). The result star key is passed to the package component.
  2. The derived key is generated by the package component from the start key. The PBKDF2 algorithm based on HMAC-SHA-1 function (see [RFC2898]) is used for the key derivation. The random number generator initialized with the current time is used to generate 16-byte salt for each file. The salt is used together with the start key to derive a unique 128-bit key for each file. The default iteration count for the algorithm is 1024.
  3. The files are encrypted. The random number generator is used to generate the 8-byte initialization vector for the algorithm. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher feedback (CFB) mode (see [blowfish]).
Each file that is encrypted is compressed before being encrypted. To allow the contents of the package file to be verified, it is necessary that encrypted files are flagged as 'STORED' rather than 'DEFLATED'. As entries which are 'STORED' must have their size equal to the compressed size, it is necessary to store the uncompressed size in the manifest. The compressed size is stored in both the local file header and central directory record of the Zip file.
In an encrypted document all the document files should be encrypted. Non-document files, that are allowed to stay nonencrypted are the files that are recognized as a part of the package format: “mimetype”, “META-INF/manifest.xml” and the signature streams in “META-INF”.

Comply to the updated ODF 1.2 Encryption Specification in OOo 3.2

OOo 3.2 needs to comply with the updated encryption specification above. This mainly means that all algorithms used in the different steps needs to be documented in the manifest.xml. It does not mean that OOo would implement other algorithms now. (issue #XXXXX)

Missing Encryption of manifest.xml

To some people it looks surprising that the manifest.xml is not encrypted.

Actually, the manifest.xml contains the information that any ODF application needs to open the document, including the encryption and hash algorithms which have been used to encrypt the document...

Protecting the not encrypted manifest.xml in an encrypted document

Since the manifest.xml can't be encrypted, someone could make modifications to manifest.xml in encrypted documents.

It needs to be discussed if there needs to be some protection against this.

For example, we could generate some signature/hash for manifest.xml, store it in a separate stream in the META-INF folder, encrypted with the same key like the other files in the package.

This could be some OOo-only solution, and OOo would only warn when the signature is missing in documents written with OOo, or it could become part of some future version of the ODF specification.

This topic needs further discussions...

Public Key Document Encryption

It would be a nice feature to allow public key encryption for encrypting documents. People could encrypt the documents with their own and/or with other people's public key certificates, so only the owners of the corresponding private keys would be able to open the document. No need to exchange or remember passwords.

Digital Rights Management

OpenOffice.org could support DRM. The part "user can/can't open a document" makes sense, can be implemented reliable. Enhanced rights/restrictions like "can copy/print/..." can't be guaranteed, because they could be removed easily in an open source application.

See also my slides from Sun's Open Media Commons workshop.

Personal tools