I've given some of the technical considerations behind security and protection
provisions for ODF 1.0/1.1/1.2 documents.
I think for usability and UX, there are the following considerations:
1. Choices offered to users are ones for which informed decisions can be made
and there is clear guidance on the consequences of the choices.
2. The Choices concerning encryption of documents (those associated with "Save
with Password") that are security and privacy related need to be clearly
separated from those that are unrelated to both security and privacy (i.e., the
various protection options).
3. Since the use of message digests (SHA1, SHA256, and others that are allowed
in ODF 1.2 documents) is employed in both protection and encryption, there
should be no options about the message digests used. The user choices should
be with respect to the actual situations.
SUGGESTIONS
1. FOR ENCRYPTION
1.1 Currently on Save with Password (where folks know to find it already),
there should be nothing but Save with Password dealt with on the dialog that
comes up when a Save starts.
1.2 The choice should be between
o ODF 1.0/1.0/1.2 Compatible (Blowfish)
o ODF 1.2 Exclusive (AES256)
If the document is being saved as ODF 1.0/1.1, no choice should be offered.
This is on the same panel that requests a password (though it might be
preset).
There should be a way to confirm/cancel encryption separate from cancelling
the save.
1.3 There can be a default radio-button preset when saving as ODF 1.2
[extended].
The default might be a configuration option for the ODF 1.2 case, but the
choice should
still be offered. (Forcing an user to make a major configuration decision
for occasional
variations is undesirable.)
1.4 When enterprise configuration/customization is provided for, there
might be ways to force
the choice in 1.2 as well as limiting Save As ... format choices. I am
assuming that is
out-of-scope for this simple public user consideration.
1.5 It might be desirable to also have provisions for encryption in the
Document Properties
dialog, on its own tab there. (Protections should be on a separate tab.)
It can then be
possible to set and to reset encryption, and a password could be elicited
on setting, although
in that case it should still be cancellable at Save or Save As ... time.
(See above.)
[The principle is to not take users down blind alleys.]
1.6 NO MATTER WHAT: The warnings about the document not being recoverable
if the password is
lost or forgotten need to be prominent in all places where a choice is
offered in the matter.
2. FOR PROTECTION
2.1 Protection dialogs already exist in various places. Some
whole-document protections are not in the same places. There are UX
considerations around when the protections are set and when they are
implemented in the document that is produced. Some can be set any time while
editing the document and have immediate effect. Some would prevent further
editing so tend to not be set until the document is saved. This requires more
cases to be worked out.
2.2 Generally, the choice is between ODF 1.0/1.1/1.2 compatibility and ODF
1.2 exclusive functionality. The difference in the SHA used is not a
meaningful consequence for the user's informed choice.
2.3 The current offering of document-level protections via an "Additional
Options" button on the Save with Protection dialog has to move. It's also done
there and elsewhere in a confusing way.
2.4 NO MATTER WHAT: Protections must be disavowed as security and integrity
features. Users should be informed, in some manner, that protections are
easily defeated and are mainly for safeguarding against accidental
modifications. In particular, users must be cautioned that the password used
is not itself protected in a secure way and a valuable password should not be
reused for this purpose.
- Dennis
-----Original Message-----
From: Dennis E. Hamilton [mailto:[email protected]]
Sent: Friday, December 07, 2012 10:26
To: [email protected]
Subject: RE: [UX] UI options for document encryption
Please see <https://issues.apache.org/ooo/show_bug.cgi?id=121141> in addressing
security vs protection in the UX also.
1. CHOICE OF ENCRYPTION ALGORITHM
It is important to appreciate that there is no recommendation about AES for the
ODF 1.2 manifest:algorithm-name. The only mandated algorithm for conformant
ODF 1.2 documents, producers, and consumers is Blowfish CFB. Other encryptions
defined in XML Encryption 1.0 are allowed in conforming documents but there is
no interoperability provision for them in ODF 1.2.
The choice for Save with Password should be simply whether to use ODF
1.0/1.1/1.2 Blowfish or (for ODF 1.2 only) AES-256.
2. HASHING THE START KEY
The only place where there is a meaningful SHA1 versus SHA256 determination for
encryption is in the choice of manifest:start-key-generation-name. This choice
is independent of the encryption used. It determines whether a 160-bit or a
256-bit password hash is provided to the PBKDF2 with HMAC-SHA-1 for derivation
of the actual encryption keys to be used. That hash is a secret and there is
some improvement in protecting the encryption when SHA256 is used.
For ODF 1.0/1.1/1.2 across the board, the common provision is with SHA1 as the
default. The use of SHA256 and provision of the optional
manifest:start-key-generation-name attribute applies only to ODF 1.2 documents.
IMPORTANT NOTE: When selecting 256 for ODF 1.2 encryptions (preferably only
with the use of AES in ODF 1.2 documents), the URI
<http://www.w3.org/2000/09/xmldsig#sha256> in the ODF 1.2 specification is
INCORRECT. It should be <http://www.w3.org/2001/04/xmlenc#sha256>. See
<https://tools.oasis-open.org/issues/browse/OFFICE-3795>.
If it is thought meaningful to feed an SHA256 into PDBKDF2 instead of starting
with an SHA1, by all means use it for ODF 1.2 documents when AES is the
encryption algorithm. There is probably no reason to make this an
user-selectable option since ODF 1.2 consumers must accept either case and it
is unclear what informed choice is to be expected of users.
2. OTHER HASH CHOICES DON'T MATTER MUCH FOR ENCRYPTION
There should be no user selection concerning SHA1 versus SHA256 with respect to
manifest:checksum. The manifest:checksum and manifest:checksum-type provisions
are neither security nor privacy related. They are to assist in checking
whether the decryption is succeeding. The mandated cases for consumers only
work on the first 1k bytes of the unencrypted file part and the choice between
SHA1-1k and SHA256-1k is insignificant. Only the SHA1-1k will work across all
of ODF 1.0/1.1/1.2. SHA256-1k must be supported by ODF 1.2 consumers, so it is
safe to use when producing an ODF 1.2-specific AES-256 encryption if desired.
In this particular application of digital hashes, there is however no advantage
of SHA256 over SHA1 and faster is better.
Note: Either way, these checksum values disclose information about the
*unencrypted* package file. In the future, it is desirable to use encryption
algorithms that allow manifest:checksum to be dropped while also verifying the
integrity of the encryption/decryption.
3. SELECTING HASHES FOR PROTECTION
Making a choice between SHA1 and SHA256 for *protections*, not encryptions, is
meaningful only when a document is saved as ODF 1.2. There is no choice when
saving as ODF 1.0/1.1/1.2 for legacy compatibility. The across-the-board
default is SHA1. Since protections are trivially defeated without any concern
for the digital hash value of the protection key, the only reason for SHA256 is
to make it slightly harder for someone to discover the password from the
protection key.
Since the protection key value is not a secret and it is easily extracted from
the document, SHA256 versus (160-bit) SHA1 is not a big improvement. Passwords
used for protection keys are vulnerable to compromise and exploitation.
See
<https://tools.oasis-open.org/version-control/svn/oic/Advisories/00009-ProtectionKeySafety/trunk/description.html>.
- Dennis
-----Original Message-----
From: Ariel Constenla-Haile [mailto:[email protected]]
Sent: Friday, December 07, 2012 08:39
To: [email protected]
Subject: [UX] UI options for document encryption
On Fri, Dec 07, 2012 at 05:19:11PM +0100, Jürgen Schmidt wrote:
> >> The "Encryption GUI" item has not attracted a sponsor. I added
> >> this per the resolution of a very long discussion in BZ [1].
> >> Subsequently, Jürgen wrote an extension to set "SHA256" mode, and
> >> I wrote a macro[2] to toggle the settings; both are still
> >> available. (I have no idea whether any or many users have used
> >> them.)
> >>
> >> [1] <https://issues.apache.org/ooo/show_bug.cgi?id=119090#c31>
> >>
> >> [2] <http://wiki.openoffice.org/wiki/User:TJFrazier/Encryption>
> >> (this page includes text suitable for release notes)
> >>
> >> If somebody wants to pick up on this, and implement a GUI
> >> (probably in Tools > Options, possibly on the Save and Save As
> >> dialogs), that's wonderful. Lacking all fu for SVN and C++, I
> >> can't volunteer for this.
> >
> > the best way is to start a new thread asking for UX advice where
> > to include the option. IMHO the Save dialogs are a no-go, the
> > average user will have no idea what this means.
> >
> > On the other hand, Tools > Options > Load/Save > General has almost
> > no space to add anything else, but may be a new "Encryption"
> > options page is an overhead...
> >
>
> Mmh, maybe directly over the "Size optimization ..." checkbox.
>
> I have thought initially about Tools -> Options -> OpenOffice.org ->
> Security. There should be enough place for a checkbox with some
> explanation.
Changing the subject so that Kevin et al. can find it.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
