[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OFFICE-4153) ODF password-based package encryption enhancements
[ https://issues.oasis-open.org/browse/OFFICE-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Stahl updated OFFICE-4153:
----------------------------------
Proposal:
The problems can only be solved with an incompatible change to the standard.
To preserve compatibility with existing ODF 1.4 or older documents, the existing elements and attributes should be preserved, and new features specified for new documents in ODF 1.5.
h1. Solutions:
1. produce an unencrypted ODF package, and store it as a single encrypted file entry in a wrapper ODF package
2. use an AEAD like AES-GCM for authenticated encryption
3. with authenticated encryption, SHA/1k checksums are obsolete, don't produce them
4. while we are making incompatible changes, use Argon2 instead of PBKDF2 to have a memory-hard KDF
h1. Proposal:
h2. 1.3 Normative References
Add:
[RFC9106] A. Biryukov, D. Dinu, D. Khovratovich, S. Josefsson, Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications, [https://www.ietf.org/rfc/rfc9106.txt], IETF, 2021
Replace [xmlenc-core] with (needed to reference AES-GCM):
[xmlenc-core] Donald Eastlake, Joseph Reagle, Frederick Hirsch, Thomas Roessler,XML Encryption Syntax and Processing Version 1.1, [http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/], W3C, 2013
h3. Add new section: 3.4.3 Wholesome Encryption
Fundamentally, there are 2 ways to encrypt an OpenDocument package. In every version of OpenDocument, it has been possible to encrypt every file entry in the package separately. With OpenDocument 1.5, it is now possible to encrypt the whole package at once, which is considered a better approach as it is both more efficient and more secure.
An OpenDocument package can be produced in the usual way (without encryption), and then wrapped in an outer OpenDocument package in an encrypted file entry with the special name "encrypted-package".
This is called wholesome encryption.
The encrypted wrapper package should contain only "mimetype", "encrypted-package", and files in "META-INF/".
Current best practice is to use wholesome encryption with SHA256 start key derivation, Argon2id key derivation function and AES-GCM authenticated encryption algorithm.
h2. 3.9 Interactions Between Encryption and Digital Signatures
(sort of obvious, but perhaps better add it explicitly: )
"If the encryption of the files is done first, the digital signatures files shall not be encrypted."
Append: "and in the case of wholesome encryption shall be placed in the outer wrapper package."
"If the files in the package are encrypted after applying the digital signatures, the digital signature files shall be encrypted."
Append: "and in the case of wholesome encryption shall be placed in the inner package."
h3. 4.16.1 manifest:algorithm-name
(should we add AES-GCM here? with updated reference, it is already allowed by the first bullet item, see [https://www.w3.org/TR/xmlenc-core1/#sec-AES-GCM] - is that enough?)
"Package producers that support encryption shall support the value Blowfish CFB.... "
(perhaps this doesn't make sense nowadays? should we replace it with a requirement for AES-GCM? there is no requirement for AES-CFB today? or leave everything optional?)
h3. 4.16.2 manifest:checksum
The proposal is to make this attribute optional.
Add:
The manifest:checksum attribute should not be produced if the algorithm referenced by manifest:algorithm-name provides authenticated encryption, e.g., AES-GCM.
(or/also deprecate it?)
h3. 4.16.3 manifest:checksum-type
The proposal is to make this attribute optional.
Add:
The manifest:checksum-type attribute should not be produced if the algorithm referenced by manifest:algorithm-name provides authenticated encryption, e.g., AES-GCM.
(or/also deprecate it?)
h3. 4.16.5 manifest:initialisation-vector
(The W3C [https://www.w3.org/TR/xmlenc-core1/#sec-AES-GCM] requires the IV to be stored as a prefix to the encrypted data - so it is redundant to store it in an attribute here too, but also harmless, perhaps best to leave it as it is?)
h3. 4.16.6 manifest:start-key-generation-name
(As discussed in OFFICE-3708 ODF uses a wrong URL for SHA256 so if we make an incompatible change we should use the opportunity to fix it.)
Replace "Package producers that support encryption should use the [http://www.w3.org/2000/09/xmldsig#sha256] algorithm."
with "Package producers that support encryption should use the [http://www.w3.org/2001/04/xmlenc#sha256] algorithm."
"Package consumers that support encryption shall support the values ..."
Add at the end: "and [http://www.w3.org/2001/04/xmlenc#sha256]";
h3. 4.16.7 manifest:key-size
Remove "For a <manifest:start-key-generation> element, the default value for this attribute is 20."
Replace in the first Note "The value used will need to be compatible with the result obtain" -> "The value used with the <manifest:start-key-generation> element will need to be one obtainable"
Remove "For a <manifest:key-derivation> element, the default value for this attribute is 16."
Replace in the second Note "The value used" -> "The value used with the <manifest:key-derivation> element"
(As the Note says, the default is dependent on the used encryption algorithm, so AES256 would have a default of 32. The attribute only makes sense in case an encryption algorithm doesn't have a fixed key size, or a start-key-algorithm doesn't have a fixed output size.)
h3. 4.16.9 manifest:key-derivation-name
Add bullet item:
* urn:oasis:names:tc:opendocument:xmlns:manifest:1.5#argon2id : The Argon2id algorithm as specified by [RFC9106]. From section 3.1. Argon2 Inputs and Outputs, the parameters "K" and "X" are not used. If this value is used, the attributes manifest:argon2-iterations, manifest:argon2-memory, and manifest:argon2-lanes shall be present to provide the "t", "m", and "p" parameters.
h3. Add new section: 4.16.x manifest:argon2-iterations
Specifies parameter "t" in [RFC9106], 3.1. Argon2 Inputs and Outputs.
h3. Add new section: 4.16.x manifest:argon2-memory
Specifies parameter "m" in [RFC9106], 3.1. Argon2 Inputs and Outputs.
h3. Add new section: 4.16.x manifest:argon2-lanes
Specifies parameter "p" in [RFC9106], 3.1. Argon2 Inputs and Outputs.
> ODF password-based package encryption enhancements
> --------------------------------------------------
>
> Key: OFFICE-4153
> URL: https://issues.oasis-open.org/browse/OFFICE-4153
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: New Feature
> Components: Packaging, Part 2 (Packages) [1.2: 3], Security
> Reporter: Michael Stahl
> Priority: Major
> Fix For: ODF 1.5
>
> Attachments: odf-manifest-schema-v2.diff, odf-manifest-schema-v3.diff, odf-manifest-schema.diff
>
>
> h3. Current situation
> Encryption is currently specified in ODF 1.4 Part 2, 3.4 "Encryption" and individual elements and attributes in 4.*.
> Currently for password-based encryption an ODF package, every file entry in the package is stored following these steps:
> 1. original size and checksum of first 1KiB of plain text are stored as attributes (to enable verifying the password on decryption)
> * manifest:size
> * <manifest:encryption-data>
> ** manifest:checksum, manifest:checksum-type
> 2. file data is compressed with "deflate"
> 3. password entered by user is hashed once (typically with SHA256)
> * <manifest:start-key-generation>
> ** manifest:start-key-generation-name
> ** manifest:key-size
> 4. salt is randomly generated, KDF is applied to result of step 3 (typically PBKDF2)
> * <manifest:key-derivation>
> ** manifest:salt
> ** manifest:iteration-count
> ** manifest:key-derivation-name
> ** manifest:key-size
> 5. initialization vector is randomly generated, file data is encrypted (typically AES256 CFB)
> * <manifest:algorithm>
> ** manifest:initialisation-vector
> ** manifest:algorithm-name
> 6. the encrypted file data is STORED (uncompressed) in the ZIP package
> h3. Problems
> There are problems with this approach:
> 1. deriving a new key for each file entry is wasteful and in practice a serious performance problem
> 2. PBKDF2 is susceptible to brute-forcing with GPUs, requiring large number of iterations to mitigate [https://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pbkdf2-sha256]
> 3. there is no authentication of the encrypted data
> 4. information is leaked, most importantly the SHA/1k checksums, and also names and sizes of file entries
> Problems 3 and 4 also affect PGP encrypted ODF packages.
--
This message was sent by Atlassian Jira
(v8.3.3#803004)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]