Table Protection: Uselessness of table:protection-key

["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. SUMMARY

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. ANALYSIS - QUESTIONABLE USE CASE FOR TABLE PROTECTION KEYS

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