Weekly Edition
Return to the Security page
| |||||||||||||
OpenOffice and document encryption portabilityStriking 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 linkSeveral 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 supportA 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 issue.
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?
Hamilton replied 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. (Log in to post comments)
Correct in principle, wrong in practice Posted Mar 29, 2012 9:57 UTC (Thu) by epa (subscriber, #39769) [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....which illustrates nicely the dangers of making decisions on technical grounds only. For all the evils that marketing departments have brought into the world, and for all the stupid anti-features incorporated into proprietary software, no commercial office package would take such a bone-headed attitude to the current user base - even in a beta release. Luckily sane voices prevailed in this case.
Multiple encryption algorithms Posted Mar 29, 2012 13:04 UTC (Thu) by david.a.wheeler (subscriber, #72896) [Link]
I'm glad they've switched to a more measured approach.
In the long term, it's wise for programs to support reading and creating multiple encryption algorithms. These algorithms are constantly attacked, and you never know when a break will occur. Having multiple algorithms available means that people can quickly switch if needed. That said, you need to modify systems so that everyone can read those multiple formats, then enable writing the formats, or you have interoperability disasters.
OpenOffice and document encryption portability Posted Mar 29, 2012 19:01 UTC (Thu) by jmorris42 (subscriber, #2203) [Link]
What a boneheaded move that was averted. Adding new crypto options is good. But adding a new one AND making it the default in the same release was actually considered as an option? Really? And then compound the stupid by not even having a UI to change the default? Wow. That a debate even happened says bad things about the future of the project.
Introduce new crypto. Wait until most of the installs in the field have upgraded to version supporting it. THEN flip the default. If an exploit is seen in the wild you might have to push that schedule and/or lean hard on users to upgrade as in the case of any other security problem actually causing problems.
OpenOffice and document encryption portability Posted Mar 30, 2012 10:29 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]
Worst than that... Not only was it going to be the new default, but also it wasn't going to be possible to change it without recompiling AOO, if I read the article correctly. o_O
OpenOffice and document encryption portability Posted Apr 3, 2012 1:54 UTC (Tue) by BradD (subscriber, #83895) [Link]
Why the need to jump to AES, in any case? There adenoid know weaknesses to blowfish (besides the always present brute-force) are there?
OpenOffice and document encryption portability Posted Apr 3, 2012 2:05 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link]
Blowfish has key-dependent S-boxes. This makes it much harder to optimize.
OpenOffice and document encryption portability Posted Apr 3, 2012 2:14 UTC (Tue) by BradD (subscriber, #83895) [Link]
Doesn't that make brute-force more time consuming too -- potentially a good thing?
OpenOffice and document encryption portability Posted Apr 3, 2012 3:49 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] I wouldn't argue against that. It seems like in general it would offer more security as long as you could also prove there were no categorically bad S-boxes. (I believe that to be true for Blowfish, but I'm no cryptographer.) In the original context of "bitslice optimizing an encryption algorithm," though, it appears Blowfish does not lend itself to this technique with a generic loop kernel. You might have to dynamically generate a kernel based on the specific S-boxes. And, of course, bitslice algorithms can't help you at all with modes like cipher block chaining (CBC) or cipher feedback mode (CFB), where one encrypted block feeds into the next. Am I dreaming, or did Schneier also develop a tree-like structure for chaining that sought to keep the security but also allowed for more parallelism than CBC or CFB?
OpenOffice and document encryption portability Posted Apr 3, 2012 4:07 UTC (Tue) by BradD (subscriber, #83895) [Link]
I believe Schneier mentioned interleaved cipher block chaining or the ideas behind it, but I don't think they are part of Blowfish.
OpenOffice and document encryption portability Posted Apr 3, 2012 5:09 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link]
I wasn't saying it was part of Blowfish or even its follow-on, Twofish; rather I was just remembering that somebody (possibly Schneier) also tried to address the parallelism question of chaining modes at some point.
In other interesting news, while trying to research the topic of interleaved chaining modes further on Google, I discovered it has already updated its index to include your reply above in this thread.
OpenOffice and document encryption portability Posted Mar 29, 2012 21:11 UTC (Thu) by robert_s (subscriber, #42402) [Link]
I've never quite understood the point of encryption built into file formats.
Seems to me it just inhibits flexibility and encourages poor key management practices / weak passwords.
OpenOffice and document encryption portability Posted Mar 29, 2012 21:41 UTC (Thu) by gerdesj (subscriber, #5446) [Link]
>>I've never quite understood the point of encryption built into file formats.
>>Seems to me it just inhibits flexibility and encourages poor key management practices / weak passwords.
That's because you are almost certainly a sysadmin.
To most users of a system a document is the important thing not its method of storage or handling as a bunch of bytes. It is a thing in and of itself.
If an end user wants to make their document "eyes only" then the feature needs to be built in.
Remember, we generally run these things for users 8)
I agree with your assertion that it generally results in poor passwords. Perhaps integration with system provided password managers (KWallet/Gnome's err whatever its called/Windows probably has one as well) would be a useful extension. Chrom{e|ium} does this nicely.
Cheers
OpenOffice and document encryption portability Posted Mar 30, 2012 11:22 UTC (Fri) by patrick_g (subscriber, #44470) [Link]
>To most users of a system a document is the important thing not its method of storage or handling as a bunch of bytes. It is a thing in and of itself.
Then use ccrypt. It can encrypt/decrypt all documents (not only ODF files) and it's very easy to use with a Nautilus script (just right click on the file and choose to encrypt or decrypt it).
OpenOffice and document encryption portability Posted Mar 30, 2012 20:21 UTC (Fri) by Creideiki (subscriber, #38747) [Link] How does it do that without leaving the plaintext around on disk? From a quick skimming of its web page, there is no obvious answer - it seems the program just does stdin/stdout streaming. Is there some GNOME magic to hook that into opening files?
OpenOffice and document encryption portability Posted Apr 2, 2012 16:40 UTC (Mon) by patrick_g (subscriber, #44470) [Link]
>How does it do that without leaving the plaintext around on disk?
It overwrite the existing plaintext file.
>Is there some GNOME magic to hook that into opening files?
I use a Nautilus script (I'm not the author, I found it on the web):
#!/bin/bash
OpenOffice and document encryption portability Posted Apr 2, 2012 17:59 UTC (Mon) by anselm (subscriber, #2796) [Link] It overwrite the existing plaintext file. The problem with that sort of approach is that, depending on the nature of the file system you're using, there is no guarantee that, when overwriting a file, the new data will actually end up in the same place on the disk that the old data occupied. This may hold for older systems such as ext2, but with modern journaling or copy-on-write file systems it may no longer be the case. What may well happen here is that, although it looks as if the file was overwritten in place, the ciphertext actually ended up elsewhere on the disk and the plaintext data can still be found if one knows where to look (or has a lot of patience).
OpenOffice and document encryption portability Posted Apr 2, 2012 18:48 UTC (Mon) by khim (subscriber, #9252) [Link] And even if your filesystem overwrites file in place your SSD firmware will most definitely keep plaintext version around. Sure, you may need some soldering skills to pull this information from the chips but it's not that hard.
OpenOffice and document encryption portability Posted Apr 2, 2012 19:02 UTC (Mon) by patrick_g (subscriber, #44470) [Link]
>What may well happen here is that, although it looks as if the file was overwritten in place, the ciphertext actually ended up elsewhere on the disk and the plaintext data can still be found
Of course (and ccrypt author admit it in the FAQ). But here we are talking about **document** security: I encrypt a file with ccrypt and send it to someone, he can decrypt it with ccrypt. Perfect security and no need for encryption built into file formats (like with ODF).
If you want **physical** security obviously you must use something like full disk encryption (encfs or another solution).
OpenOffice and document encryption portability Posted Mar 30, 2012 10:42 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] I can think of good reasons why you might want encryption within a file. You may actually want to expose certain metadata to the world, and only want to encrypt the sensitive bits, for example. I don't know if ODF supports that usage, mind you, but saying encryption has to be "whole file or nothing" is itself inflexible, just in a different way. I assume that's the model you're considering -- ie. use GPG to encrypt/decrypt the file separately of the application that uses the file. Another issue I can think of is the presence of plaintext on disk. If you separate the decryption from the application manipulating the file, then you have a separate plaintext version after decryption. (Again, I'm assuming a flow where you GPG decrypt, and then fire up the application, whether it be OO or something else.) For many people this might be OK, but some that might not be acceptable. Sure, the counterargument is that OO or whatever should just decrypt it via a pipe and avoid the on-disk cleartext. That may work, until the file gets too big to read into memory reasonably. While PCs may be getting absurd amounts of RAM, people do sometimes try to read documents on phones and tablets, and I only see that trend growing. It also starts to not look too terribly different to the user than building encryption into the file format. So why not go all the way? Once you say "encryption is part of the file format", then you can also start to do things like segment the file into separately decryptable chunks and leave those on disk until needed. Again, I don't know if that's something ODF lets you do, but it's certainly an axis of freedom available to someone designing a file format.
OpenOffice and document encryption portability Posted Apr 8, 2012 2:20 UTC (Sun) by blujay (guest, #39961) [Link]
IMHO it's issues like this that hold back FOSS adoption. Developers who only care about technical issues, who don't see their position of power over the code as also being a position of responsibility to the users, should not be allowed to make release decisions. Thankfully, in this case the release manager "gets it" and had the ability to overrule with the correct decision. But this is not always the case (e.g. GNOME).
Sometimes I wish Linus could have veto power in a lot of FOSS projects and distros, because he "gets it": "Don't break userspace! Ever!"
FOSS developers who work on substantial projects should aspire to a higher standard, one that's not selfishly about just doing what's fun or making the code elegant, but about ensuring that the software is useful, and that its functionality remains fully functional from one release to the next, regardless of underlying changes.
It only takes one blunder to lose trust, and then users will move on. Sadly, that may sometimes mean moving back to proprietary software. What a shame when such opportunities to further FOSS are lost due to selfishness or foolishness.
|
|||||||||||||