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


While table/cell protection is an expected "feature," I am not sure how 
far we should go in terms of warnings to users. In part because any 
warning we give will be of necessity incomplete. Should we point out 
that digitally signed documents are only meaningfully "secure" as part 
of an overall security system? Do we specify at least the common 
components of such systems?

One of the things we can say in a standard is what we are not 

Perhaps we should say that while ODF can be used in "secure" systems and 
that there are aspects of ODF, such a digital signatures, that may be 
useful in building such systems, that security is beyond the purview of 
the standard. That is we provide the hooks for such systems but your 
actual mileage will vary.

Hope you are at the start of a great new year!


Dennis E. Hamilton wrote:
> Forgot to address this to the list 
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
> Sent: Friday, January 02, 2009 16:04
> To: 'Bob Jolliffe'
> Subject: RE: [office] Table Protection: Uselessness of table:protection-key
> I like your suggestion about a warning in the specification and I included
> that in the final part of my analysis on what needs to be specified if
> table:protection-key-digest-algorithm is going to be useful.
> In addition, I just realized that worrying about coming up with hash
> collisions is actually a misplaced concern and the strength of the message
> digest algorithm is irrelevant.  The weakness here is that keys are short
> compared to the kinds of messages that digests work well for.
> Because keys are short and usually memorable, one can simply attack the key
> directly.  That is, start with strings of length 1, then length 2, etc., and
> compute their SHA-1 hashes.  This is a little taxing and one might want to
> use other techniques for choosing likely keys of various lengths (like
> dictionary attacks or a published set of billions of SHA-1 hashes of known
> values).  These attacks are well-known and will uncover the keys that most
> people will use with incredibly high reliability.  Using a stronger digest
> algorithm is not much help.  One simply attacks the key rather than the hash
> in any case.
> I think the basic caveat applies: Don't use a key that is also used to
> protect a more-valuable asset that would be exposed upon the key's
> compromise as a table-protection lock.  Making the key unique to the
> document and used for no other purpose is also a good idea, especially if
> the key is really not going to be shared with anyone.  
> Thanks for your thoughts.  They were inspirational.  (I suspect this is old
> hat to David Wheeler and expect he'll be amused by our struggles here.)
>  - Dennis
> -----Original Message-----
> From: Bob Jolliffe [mailto:bobjolliffe@gmail.com] 
> Sent: Friday, January 02, 2009 13:26
> To: ODF TC List
> 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
> convenience.
> Regards
> Bob
> 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
> ---------------------------------------------------------------------
> 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 

Patrick Durusau
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

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