OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Table Protection: Uselessness of table:protection-key

Hello Dennis

The analysis you layout below is, at least in my opinion, correct.
The way table cells (and other aspects of documents) have been
"protected" by office applications historically is, at best, naive
and, at worst, fraudulent.  Perhaps some sort of warning is required
in the specification to prevent the latter charge.  The only reason
one can think of to maintain such a feature is to have backward
compatibility as well as interoperability with other applications
which do something similar.  I have, over time, become reluctantly
persuaded that these are sufficiently valuable aims to maintain the
"feature" though I would not compromise over using a known weak
algorithm to protect the password - Florien will remember long
arguments over a similar "feature" in ooxml.  As you point out, the
password is the only thing being protected here.  Of course in time
other algorithms become weak (and some even become known to be so) but
that's another matter.

That some of the resulting problems can be overcome by applying a
signature to the "protected" part was one of the use cases I had in
mind when I suggested that we should provide explicit support for the
signing of XML document fragments in the original DSIG proposal
submitted by Jomar and myself (the other use case was to provide for
visible signature graphics).  For a couple of reasons, we chose not to
pursue this for the moment:

(1)  there is actually nothing in the specification which prevents
applications calculating such signatures anyway.  So if the integrity
of protected cells in a table is really important to you, you can sign
them.  But for the specification to effectively require some form of
PKI is probably not appropriate.

(2)  there is a wide range of other possible signature scenarios
involving different types of signatures, different combinations of
signed content etc etc.  We need to have a fairly rich and well
thought out means to say things about these signatures.  Current
thinking seems to suggest that the ODF metadata mechanism will be the
correct way to do this.  I agree and I see this as a high priority
next/requirements issue rather than something we should try to get
right in a hurry.

For the moment I don't think that any implementors are unaware of the
issue.  Of course the hapless users are another matter.  Perhaps we
should recommend that implementations provide a warning to users that
cell-protection is not a security feature - simply an application


2009/1/2 Dennis E. Hamilton <dennis.hamilton@acm.org>:
> While researching the Table Protection proposal I noticed an interesting thing.
> It seems that the table:protection-key feature is of no great value in protecting table cells against unauthorized alteration.
> This suggests that tightening up the specification of the new ODF 1.2 attribute table:protection-key-digest-algorithm may be wasted effort compared with avoiding it altogether.
> Before we go to the trouble to clean up the table:protection-key-digest-algorithm attribute so that it is well-specified, I suggest we consider whether we are better off without it, deprecating and removing table:protection-key instead.
>  - Dennis
> 1.1 In the existing OASIS Standards for ODF, a <table:table> table:protection-key attribute is identified and specified to contain a cryptographic hash that is made from an user-chosen key.  However, this hash, whatever the algorithm for it happens to be, only protects the key from disclosure.  It does not protect the <table:table> table:protected attribute (see the analysis, below).  Since it is near trivial to defeat the table:protected attribute, it is a terrible waste to entrust the document with an encrypted key that is apparently far more valuable than its utility for protecting table cells against unauthorized changes.
> 1.2 The addition of the companion attribute table:protection-key-digest-algorithm provides a way to identify the message digest technique used to create a cryptographic-quality hash of a secret key.  The default is the SHA-1 method currently defined in US FIPS Pub 180-3 which replaces the earlier FIPS Pub 180-2 and its predecessor FIPS Pub 180-1.  This provision has two difficulties:
>   1.2.1 The XML Digital Signature (DSIG) W3C Specifications only identifies SHA-1 method for use as a Message Digest algorithm (where the message, in this case, is text of a private key as a sequence of bits).  The default is the only currently-recognized specific value as well, but this connection is not asserted in the specification for table:protection-key-digest-algorithm in the current draft of ODF 1.2.  (The ODF 1.2 specification refers to a non-existent section of this specification and there are no URIs for the recommended digest methods other than SHA-1.  As pointed out in the analysis, using SHA-256 or something stronger is completely pointless except for promoting a false sense of security.]
>   1.2.2 Since no digest method is specified in earlier ODF specifications, this represents a peculiar breaking change.  Because earlier implementations, if they made use of table:protection-key at all, must have used an implementation-determined algorithm, if any, there is not assurance that the default for ODF 1.2 will correspond.  I don't think this is serious, but it is something that has to be accounted for.  It seems to me that there should not be a default value for ODF 1.2, making the SHA-1 URI explicitly required, and making that attribute required when table:protection-key is present.
> 2.1 It needs to be understood that the use of a message digest as the table:protection-key does not protect cells of the table from unauthorized alteration.  The use of a message digest (a cryptographic hash) of the key simply protects the key from disclosure.  Unfortunately ...
> 2.2 Knowledge of the key is completely unnecessary in order to defeat the table:protected attribute.  Although this might discourage an ordinary office-document user, anyone capable of accessing the XML <table:table> element and manipulating it by direct means can disable the protection, make any alterations, and then restore the protection.  That is to say, the protection against alteration afforded by use of the message digest is simply not at the level that the effort to protect the key would suggest is accomplished.  (The ceremony involved becomes what Bruce Schneier would likely identify as "security theatre.")
> 2.3 The only effective way to protect the table against unauthorized alterations is to provide a digital signature that covers all of the protected elements in such a way that their alteration will cause the signature to become unverifiable.  So long as the signature is that of a recognized principle and the private key for that principle is not compromised, unauthorized alteration will be revealed as an inability to verify the alleged signing of the document (or, specifically, of its protected content).  Although substitution of an imposter's signature (a form of phishing) might deceive an user of the table information, it would not survive a claim by the authentic signer that the document is fraudulent.  The document is repudiable.  (This applies whether the W3C XML Digital Signature recommendation is used or whether a non-W3C digital signature technique is applied that works at the entire package or single file level rather than on a signable abstraction of the XML document.)
> 2.4 Because the table:protection-key is such a weak feature, cleaning up the introduction of table:protection-key-digest-algorithm into ODF 1.2 may actually require more effort than simply deprecating table:protection-key.  Instead we could simply promote the use of digital signatures in combination with the basic <table:table table:protected="true"> (or <table:table-cell table:protected="true">) case for protecting cells against alteration of the protected content.
>  - Dennis
> Dennis E. Hamilton
> ------------------
> NuovoDoc: Design for Document System Interoperability
> mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430
> http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> --
> This message has been scanned by DST MailScanner

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]