Striking the delicate balance between usability and secure default
options has surfaced as an unexpected issue for the Apache OpenOffice (AOO)
project in the closing days of its 3.4 development cycle. An AOO developer
opened a bug
report on March 18 forecasting trouble with the office suite's new
encryption settings. The problem is that recent AOO builds switched from
Blowfish to AES as the default cipher. Since no previous releases of
OpenOffice or most other ODF-reading applications support AES (LibreOffice
added it as a feature in LO 3.5), encrypted files created with the new builds were unreadable in other programs. Complicating matters is ambiguity about how to interpret the ODF standard, how to expose new encryption options in the interface, and whether or not file encryption is implemented securely to begin with.
The ODF document format supported by AOO, LibreOffice, and other office
suites, allows users to password-encrypt any file (via the "Save with
Password" option). Up until recently, Blowfish was the default choice in
every ODF application. But, as original bug reporter Dennis Hamilton
noted, starting with revision 1293550,
AOO produces AES256 Cipher-block chaining (CBC) encrypted documents by
default — which are then unreadable by LibreOffice 3.3 and 3.4 (prior
to 3.4.5), the last stable release of OpenOffice, and by Lotus Symphony. Exacerbating matters, all three programs report that the encrypted file is malformed, rather than reporting that it uses a different encryption method.
The encryption algorithm used in a compliant ODF file is specified in
the manifest, which is an XML
file stored in the ODF ZIP-archive-based file format. Section
4.8.1 of the OpenDocument 1.2 specification defines only one value as
compliant: Blowfish, in 8-bit cipher feedback (CFB) mode. However, the
specification allows "extended" ODF 1.2 files to support other algorithms,
and mandates a W3C-standardized syntax
for identifying them. Thus, strictly speaking, the other ODF applications are failing to recognize a correctly-formatted ODF 1.2 "extended" file, which could hardly be construed as a bug in AOO.
Defaults, standards, and the weakest link
Several AOO developers observed that AOO was not to
blame for other applications failing to understand the algorithm identifier
in the file manifest and consequently voted that the bug did not qualify as
a blocker to hold up the upcoming 3.4 release. Rob Weir, co-chair of the
ODF 1.2 specification committee, said the problem was a
security-versus-interoperability trade-off, that could be handled by user
education. Users can be told about the interoperability issue and manually
select the Blowfish cipher if desired. Furthermore, Weir argued that
Blowfish needed to be replaced by AES anyway, both because it is a newer
cipher, and because it is a US government recommended standard.
Hamilton disagreed on both points. First, he said,
the AOO builds do not offer the user any way to select the
encryption algorithm: they use AES automatically. Rather than serving as a
"default" (which implies that a setting is available), the encryption
algorithm used is fixed at build time — consequently AOO appears to
produce corrupted ODF files, which will result in "a support
nightmare" if released. Second, using AES encryption instead of
Blowfish may not really
increase security, he added in a follow-up, because ODF provides message digests based on the same start key used to encrypt the file, and because ODF does not properly salt digests. That provides attackers with a much easier target than the encrypted message body, making it irrelevant which encryption cipher is used.
Furthermore, Hamilton argued
that ODF's XML contains extensive "boilerplate" text that can aid attackers
in discovering a password, regardless of the cipher used:
There are gratuitously-included known-plaintext files in every ODF package
produced by the well-known OpenOffice lineage implementations. Some of
these are relatively short and their sizes and compressed values are known
in advance. That makes these files easy to spot in an encrypted ODF
package. That makes them interesting as aids to discovery of the password
(or its digest) as well.
Not everyone agrees with his analysis, but Hamilton has submitted formal proposals for ODF 1.3 to fix the digest problems, and proposes introducing "chaff" into the known-plaintext files to further deflect attack. More immediately, however, he attached a short patch to restore Blowfish as the encryption algorithm in AOO.
Interoperability and user support
A discussion thread on the AOO development list ran in parallel to the one on the bug tracker. However, different facets of the issue cropped up on the list. There, Weir noted that LibreOffice, too, had enabled AES encryption, which should significantly increase the number of users who should be able to decrypt AES-based files, and pointed to the lack of complaints or confusion from users of either office suite.
T.J. Frazier reiterated that the root issue was not that AES was a bad default choice, but that AOO did not present any UI for the user to select an encryption cipher. He also argued that introducing an incompatibility with older releases was a problem in and of itself. "It is *wrong* to break compatibilities as this does, without long lead-time, and opt-in possibilities, unless there exists some drastic need. That has not been shown. Improvement, yes; crucial, no." Finally, he proposed several methods of enabling knowledgeable users to manually select AES, and volunteered to do the UI work.
In response to the compatibility-breaking issue, Weir replied
that he simply did not see that the problem met the project's established
guidelines for a release-blocking
The encryption has been set to AES since 3.4 Beta, 9 months ago. I have not
seen any user complaints. LO has made the same choice. I have not seen
any user complaints there either. And now we're going to hold up the
release for this? Really?
that there had been complaints in the LibreOffice community, and observed
that the LibreOffice project had back-ported
AES support into its 3.4 release series (starting with 3.4.5) in order to
restore compatibility. It should also be noted that the problem is only
for users of the older tools trying to read password-protected files
created with the newer — reading Blowfish-encrypted files is still
supported in the new versions.
Ultimately, however, release manager Jürgen Schmidt had the final say, and he accepted the issue as critical enough to warrant reverting back to Blowfish in the AOO 3.4 release, and favored implementing a user-selectable encryption setting for the 4.0 series. As he added in a subsequent message, "most users don't care about the technical details and they will be simply confused if it won't work any more." Weir concurred with that plan, saying, "users who are smart enough to know they want AES will be smart enough to set that option."
That may be true, but of course introducing user-configurable encryption settings will be a UI challenge of its own. For its part, the LibreOffice team is also planning to institute a UI review for the next release cycle. As Michael Meeks pointed out, the changes affect document signing as well as password-encryption.
Meeks did not elaborate, but considering Hamilton's comment in the bug tracker outlining several different attacks on the encrypted files and digests, there may be no shortage of options. Some of those may require changes to the ODF format to fix completely, but all of them require a carefully-considered interface. After all, the "smart" users may be counted on to get it right more often than not, but making it difficult for the inexpert users to choose poor settings is also important. The more complexity users are presented with, the more of them are likely to simply stick with the defaults.
to post comments)