The best way to ensure document integrity is to digitally sign the documents.

But most people won't do it, or even don't have the infrastructure for this, so there should be some light weight mechanism for checking the document integrity

== ODF conformance clause ==

The ODF specification should have some conformance clause, that all files, except package meta data in META-INF folder (signature streams for example) and the mimetype stream, must be registered in manifest.xml.

With the current ODF specification, the META-INF folder should only contain manifest.xml, and might contain some signature streams (*signatures.xml).

When this is defined, an ODF application should not load any files which are not registered in manifest, or show a warning to the user.

== Make sure OOo 3.2 would adhere to the ODF conformance clause ==

Independently from whether or not the conformance clause above will make it into the ODF specification, OpenOffice.org should create documents adhering to the definition above. (isse #XXXXX)

== Check ODF integrity in OOo 3.2 ==

Assuming that the conformance clause above will be added to the ODF specification, OOo should warn when loading documents containing streams not registered in manifest.xml.(issue #XXXXX) 

The check/warning is not necessary when the document has a broken signature.

This shouldn't be a problem for older documents (written with OOo), because OOo is already registering all files in manifest.xml

Maybe the check should only be done for ODF 1.2 (and newer) documents, to avoid interop problems with documents written by other applications.

Security

2009-07-10T10:54:53Z

Mt:

{{Security}}

== The security project ==

This wiki page is the collaboration entry point for the [http://security.openoffice.org/ OOo security project].

For questions and discussions, please use the new mailing list from the security project: [mailto:discuss@security.openoffice.org discuss@security.openoffice.org]

When you plan to file an issue with regard to security, please make sure to add the keyword <tt>security</tt>.

== General Topics ==

[[Security/Digital Signatures|Digital Signatures]]

[[Security/Encryption|Encryption]]

[[Security/Document Integrity|Document Integrity]]

== Current Activities ==

*Digital Signature:
**[[Security/Digital Signatures#Digital_Signature_Specification_for_ODF_1.2|Improving the Digital Signature Specification for ODF 1.2]]
**[[Security/Digital Signatures#Improving_the_Digital_Signature_Implementation_in_OOo_3.2|Digital Signature Implementation in OOo 3.2]]
**[[Security/Digital Signatures#Inform_the_user_that_OOo.27s_Digital_Signatures_have_no_legal_value|Inform the user that OOo's Digital Signatures have no legal value]]
**[[Security/Digital Signatures#Show_a_warning_for_not_signed_macro_streams_in_documents_signed_with_OpenOffice.org_2.x|Show a warning for not signed macro streams in documents signed with OpenOffice.org 2.x]]
*Encryption:
**[[Security/Encryption#Encrypted_documents_shouldn.27t_have_any_non_encrypted_content|Encrypted documents shouldn't have any non encrypted content]]
**[[Security/Encryption#Improving_the_Encryption_Implementation_in_OOo_3.2|Improving the Encryption Implementation in OOo 3.2 ]]
**[[Security/Encryption#IEnhancing_the_Encryption_Specification_for_ODF_1.2|Enhancing the Encryption Specification for ODF 1.2 ]]
**[[Security/Encryption#Comply_to_the_updated_ODF_1.2_Encryption_Specification_in_OOo_3.2|Comply to the updated ODF 1.2 Encryption Specification in OOo 3.2 ]]
*Document Integrity:
**[[Security/Document Integrity#ODF_conformance_clause|ODF conformance clause]]
**[[Security/Document Integrity#Make_sure_OOo_3.2_would_adhere_to_the_ODF_conformance_clause|Make sure OOo 3.2 would adhere to the ODF conformance clause]]
**[[Security/Document Integrity#Check_ODF_integrity_in_OOo_3.2|Check ODF integrity in OOo 3.2]]

== Open Discussions ==

[[Security/Encryption#Protecting_the_not_encrypted_manifest.xml_in_an_encrypted_document|Protecting the not encrypted manifest.xml in an encrypted document]]

== Notes and Ideas - nothing we currently work on ==

[[Security/Notes and Ideas#Different_ways_of_doing_encryption_and_signatures|Different ways of doing encryption and signatures]]

[[Security/Encryption#Public_Key_Document_Encryption|Public Key Document Encryption]]

[[Security/Encryption#Digital_Rights_Management|Digital Rights Management]]

[[Security/Digital Signatures#Digital_Signatures_Framework|Digital Signatures Framework]]

[[Security/Digital Signatures#Digital_Signatures_for_Extensions|Digital Signatures for Extensions]]

[[Security/Encryption#Password length and password pattern |Password length and password pattern ]]

== Other Pages ==

[[SecurityFAQ|Frequently Asked Questions]]. Please help us improve the content by editing these pages.

[[Category:Security]]

Mt:

== 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.

== 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: 
<blockquote>2.3 Encryption: </blockquote><blockquote>The encryption process takes place in the following multiple stages: 
#The start key is generated and is provided to the package component.
#The derived key is generated by the component based on the start key.
#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. </blockquote><blockquote>The default way is: 
#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.
#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.
#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”. </blockquote>

== 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 [http://www.slideshare.net/Malte.Timmermann/openofficeorgstaroffice-drm-omc-workshop-2006-presentation my slides] from Sun's [http://www.openmediacommons.org/ Open Media Commons] workshop.

[[Category:Security]]

Security/Document Integrity

2009-07-10T10:20:07Z

Mt:

Security/Document Integrity

2009-07-10T10:18:16Z

Mt:

2009-07-10T09:55:11Z

Mt:

Security/Encryption

2009-07-10T09:54:51Z

Mt:

Security/Document Integrity

2009-07-10T09:37:07Z

Mt:

Security/Digital Signatures

2009-07-10T09:35:32Z

Mt:

== Digital Signature Specification for ODF 1.2 ==

Digital Signatures have already been specified in an ODF 1.2 draft from 2007 ([http://www.oasis-open.org/committees/download.php/25264/compact_OpenDocument-v1.2-draft6.odt OpenDocument-v1.2-draft6.odt]). 

However, after [http://blogs.sun.com/malte/entry/comments_on_the_black_hat studying the Black Hat 2009 OOo Security Briefing], we feel that the final ODF 1.2 specification needs to be improved, so that the manifest.xml will also be part of a document signature. 

It's not clear whether or not the document signature file itself should also always been signed, because it depends on the use case, so we want to leave this as optional. 

This is the latest draft of the proposal that we will send to the OASIS OpenDocument TC: 
<blockquote>Document and Macro Signatures</blockquote><blockquote>An OpenDocument document that is stored in a package may have one or more digital signatures applied to the package. A document signature is a digital signature that is applied to all files contained in a package, regardless whether they are defined by this specification or are application specific extensions. This also includes files which carry meta information used by the package itself, such as manifest.xml, additional signature files, but might exclude the signature file itself. Because the signature is applied to every file, applications can detect if additional files were added after the document had been signed. This applies also for additional signature files contained in META-INF, such as macrosignatures.xml. If files were added after the document signature had been created, then applications must inform the user, for example, by indicating that the signature is broken. Document signatures are stored in a file called META-INF/documentsignatures.xml in the package as described in section 2.4 of the OpenDocument specification part 3. A document signature shall be considered to be valid only if the 'XML-Digital Signature' contained in documentsignatures.xmlisvalid itself, if it is applied to all filesof thpackage, which may include the signature file itself, and if no files were added after the signature was created.A macro signature is a digital signature that is applied to macro code and other executable code that may be contained in a package. Macro signatures are stored in a file called META-INF/macrosignatures.xml in the package as described in section 2.4 of the OpenDocument specification part 3. Since macro code and executable code is application specific, this specification does not define to which files a macro signature applies. However, an application shall consider a macro signature as invalid if a package contains files to which the macro signature is not applied, and which contain macro or executable code that the application is able to execute. Since a document signature is applied to all files, it includes the files to which a macro signature is applied. A document may have document and macro signatures applied simultaneously, and may have further applications specific signatures applied to its package. </blockquote><blockquote>2.4 Digital Signatures</blockquote><blockquote>Document files and package files, that is the files which carry meta information for the package, such as manifest.xml,imay have a digital signature applied.Digital signatures are stored in one or more files within the META-INF folder. The names of these files shall contain the term "signatures". Each of these files contains a <dsig:document-signatures> root element that serves as a container for an arbitrary <Signature> element as defined by the [xml-dsig] specification. If the <dsig:document-signatures> element contains multiple <Signature> elements, then there should be a relation between the digital signatures they define, for instance, they may all apply to the same set of files. Applications may require that a digital signature includes a certain set of files. That is, they may consider a digital signature to be valid if, and only if, the digital signature itself is valid, and if the <Reference> child elements of the <Signature> element reference a certain set of files. In particular, application may require that a digital signature references all files contained in a package. The schema for digital signatures is: ... </blockquote>

== Improving the Digital Signature Implementation in OOo 3.2 ==

The implementation of the digital signatures need to be changed to match the updated [[Security/Digital Signatures#Digital_Signature_Specification_for_ODF_1.2|Digital Signature Specification for ODF 1.2]]. The manifest.xml needs to be included in the document signature, as well as other streams in META-INF except signature streams. (issue #XXXXX).

For ODF 1.0/1.1 documents, some special handling for not signed macro streams in a signed document is needed ([[#Show_a_warning_for_not_signed_macro_streams_in_documents_signed_with_OpenOffice.org_2.x|see below]]), because the implementation was different than what is specified in ODF 1.2 now (issue #XXXXX).

Older versions of OOo with a document signature only check for not signed files when these are not located in the META-INF folder. With OOo 3.2, this check will be enhanced to also check for not signed content in the META-INF folder. (issue #XXXXX).

== Encryption of Digital Signatures in Encrypted Documents ==

Currently OOo doesn't encrypt digital signatures in encrypted documents. This doesn't make the signatures less reliable, and there are arguments for encrypting the signatures as well as arguments for not doing so.

No encrypting the signatures can be a privacy issue. because someone could see who has signed a document. But on the other side, some automatic processes can't verify the signature when it's encrypted.

For now, we don't have any plans to change the current implementation. In the future, additional signature implementations might handle it differently.

== Show a warning for not signed macro streams in documents signed with OpenOffice.org 2.x ==

The first implementations of digital signatures in OpenOffice.org 2.x completely separated signing document content from signing scripting content. Macros have not been included in the document signatures, so they could be manipulated in a signed document. This behavior changed in OpenOffice.org 3, where the macros are now also signed when the document is signed (without having the same status like explicitly signed macros).

For compatibility reasons, OOo should show a warning (and not a broken signature) when a signed document contains macros which are not signed, but only for documents created with OpenOffice.org 2.x.

The warning will not contain any extra explanation text that the issue can have happened for legacy reasons - signed ODF documents with macros are probably not used that much. 

== Inform the user that OOo's Digital Signatures have no legal value ==

While the digital signatures help for author authentication and for ensuring document integrity, the implementation in OOo is not a certified solution, so the signatures won't have any legal value in most countries.

OOo should inform the user about this when he starts to add a digital signature to a document. There should be a configuration item to disable the warning. (issue #XXXXX)

== Digital Signatures Framework ==

There are some ideas for a digital signature framework, so other (3rd party) implementations can be used in OpenOffice.org. See the [http://wiki.services.openoffice.org/wiki/Improving_The_Digital_Signature_Feature description in the Wiki] and [http://marketing.openoffice.org/ooocon2008/programme/friday_1419.odp Jochen's presentation].

== Digital Signatures for Extensions ==

It would be good if OpenOffice.org extensions could be digitally signed, for publisher authentication as well as for integrity verification.

[[Category:Security]]

Security/Digital Signatures

2009-07-10T09:31:23Z

Mt:

== Digital Signature Specification for ODF 1.2 ==

Digital Signatures have already been specified in an ODF 1.2 draft from 2007 ([http://www.oasis-open.org/committees/download.php/25264/compact_OpenDocument-v1.2-draft6.odt OpenDocument-v1.2-draft6.odt]). 

However, after [http://blogs.sun.com/malte/entry/comments_on_the_black_hat studying the Black Hat 2009 OOo Security Briefing], we feel that the final ODF 1.2 specification needs to be improved, so that the manifest.xml will also be part of a document signature. 

It's not clear whether or not the document signature file itself should also always been signed, because it depends on the use case, so we want to leave this as optional. 

This is the latest draft of the proposal that we will send to the OASIS OpenDocument TC: 
<blockquote>Document and Macro Signatures</blockquote><blockquote>An OpenDocument document that is stored in a package may have one or more digital signatures applied to the package. A document signature is a digital signature that is applied to all files contained in a package, regardless whether they are defined by this specification or are application specific extensions. This also includes files which carry meta information used by the package itself, such as manifest.xml, additional signature files, but might exclude the signature file itself. Because the signature is applied to every file, applications can detect if additional files were added after the document had been signed. This applies also for additional signature files contained in META-INF, such as macrosignatures.xml. If files were added after the document signature had been created, then applications must inform the user, for example, by indicating that the signature is broken. Document signatures are stored in a file called META-INF/documentsignatures.xml in the package as described in section 2.4 of the OpenDocument specification part 3. A document signature shall be considered to be valid only if the 'XML-Digital Signature' contained in documentsignatures.xmlisvalid itself, if it is applied to all filesof thpackage, which may include the signature file itself, and if no files were added after the signature was created.A macro signature is a digital signature that is applied to macro code and other executable code that may be contained in a package. Macro signatures are stored in a file called META-INF/macrosignatures.xml in the package as described in section 2.4 of the OpenDocument specification part 3. Since macro code and executable code is application specific, this specification does not define to which files a macro signature applies. However, an application shall consider a macro signature as invalid if a package contains files to which the macro signature is not applied, and which contain macro or executable code that the application is able to execute. Since a document signature is applied to all files, it includes the files to which a macro signature is applied. A document may have document and macro signatures applied simultaneously, and may have further applications specific signatures applied to its package. </blockquote><blockquote>2.4 Digital Signatures</blockquote><blockquote>Document files and package files, that is the files which carry meta information for the package, such as manifest.xml,imay have a digital signature applied.Digital signatures are stored in one or more files within the META-INF folder. The names of these files shall contain the term "signatures". Each of these files contains a <dsig:document-signatures> root element that serves as a container for an arbitrary <Signature> element as defined by the [xml-dsig] specification. If the <dsig:document-signatures> element contains multiple <Signature> elements, then there should be a relation between the digital signatures they define, for instance, they may all apply to the same set of files. Applications may require that a digital signature includes a certain set of files. That is, they may consider a digital signature to be valid if, and only if, the digital signature itself is valid, and if the <Reference> child elements of the <Signature> element reference a certain set of files. In particular, application may require that a digital signature references all files contained in a package. The schema for digital signatures is: ... </blockquote>

== Improving the Digital Signature Implementation in OOo 3.2 ==

The implementation of the digital signatures need to be changed to match the updated [[Security/Digital Signatures#Digital_Signature_Specification_for_ODF_1.2|Digital Signature Specification for ODF 1.2]] (issue #XXXXX).

For ODF 1.0/1.1 documents, some special handling for not signed macro streams in a signed document is needed ([[#Show_a_warning_for_not_signed_macro_streams_in_documents_signed_with_OpenOffice.org_2.x|see below]]), because the implementation was different than what is specified in ODF 1.2 now (issue #XXXXX).

Older versions of OOo with a document signature only check for not signed files when these are not located in the META-INF folder. With OOo 3.2, this check will be enhanced to also check for not signed content in the META-INF folder. (issue #XXXXX).

== Encryption of Digital Signatures in Encrypted Documents ==

Currently OOo doesn't encrypt digital signatures in encrypted documents. This doesn't make the signatures less reliable, and there are arguments for encrypting the signatures as well as arguments for not doing so.

No encrypting the signatures can be a privacy issue. because someone could see who has signed a document. But on the other side, some automatic processes can't verify the signature when it's encrypted.

For now, we don't have any plans to change the current implementation. In the future, additional signature implementations might handle it differently.

== Show a warning for not signed macro streams in documents signed with OpenOffice.org 2.x ==

The first implementations of digital signatures in OpenOffice.org 2.x completely separated signing document content from signing scripting content. Macros have not been included in the document signatures, so they could be manipulated in a signed document. This behavior changed in OpenOffice.org 3, where the macros are now also signed when the document is signed (without having the same status like explicitly signed macros).

For compatibility reasons, OOo should show a warning (and not a broken signature) when a signed document contains macros which are not signed, but only for documents created with OpenOffice.org 2.x.

The warning will not contain any extra explanation text that the issue can have happened for legacy reasons - signed ODF documents with macros are probably not used that much. 

== Inform the user that OOo's Digital Signatures have no legal value ==

While the digital signatures help for author authentication and for ensuring document integrity, the implementation in OOo is not a certified solution, so the signatures won't have any legal value in most countries.

OOo should inform the user about this when he starts to add a digital signature to a document. There should be a configuration item to disable the warning. (issue #XXXXX)

== Digital Signatures Framework ==

There are some ideas for a digital signature framework, so other (3rd party) implementations can be used in OpenOffice.org. See the [http://wiki.services.openoffice.org/wiki/Improving_The_Digital_Signature_Feature description in the Wiki] and [http://marketing.openoffice.org/ooocon2008/programme/friday_1419.odp Jochen's presentation].

== Digital Signatures for Extensions ==

It would be good if OpenOffice.org extensions could be digitally signed, for publisher authentication as well as for integrity verification.

[[Category:Security]]