OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only

  • 1.  RE: [office] Table Protection: Uselessness of table:protection-key

    Posted 01-03-2009 00:19 
    Forgot to address this to the list


  • 2.  Re: [office] Table Protection: Uselessness of table:protection-key

    Posted 01-03-2009 13:24 
    Dennis,

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 
standardizing.

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!

Patrick

Dennis E. Hamilton wrote:
> Forgot to address this to the list 
>
> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 3.  Re: [office] Table Protection: Uselessness of table:protection-key

    Posted 01-03-2009 18:17 
    Hi

2009/1/3 Patrick Durusau


  • 4.  RE: [office] Table Protection: Uselessness of table:protection-key

    Posted 01-03-2009 19:14 
    Bob, I think that's right.

Perhaps the way to say it is this:

(1) the table-cell protection feature is provided as a safeguard against
accidental alteration of cells that must be kept fixed in order to achieve
the intended purpose, such as use of tables as part of a form for data
collection and reporting.

(2) the locking of table-cell protection is provided as a safeguard against
careless over-riding of the table-cell protections.  Cell locking is not a
secure protection against unauthorized and undetected alteration of the
protected table cells.  Knowledge of the password is not required in order
for a knowledgeable party to over-ride the locking by manipulation of the
XML document directly.  

(3) The hash code is a barrier against casual discovery of the password by
inspection of the XML.  Hash codes of short texts such as memorable
passwords are easily attacked regardless of the strength of the hash code.
To limit the consequences of password compromise, passwords used for locking
the table-cell protection should not be used for any other purpose.

 - Dennis


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 5.  RE: [office] Uselessness of table:protection-key - perfect key safety

    Posted 01-03-2009 21:47 
    I looked over my earlier statement and have revised it to be entirely
descriptive with no use of normative terms (other than "may" in the sense of
possibility as used by JTC1).

But, before going on to more serious subjects, I also came upon a hilarious
way to use the table:protection-key in a way that will never be subject to
key compromise because the key is not known to anyone and it is unlikely
that there is a possible, let-alone guessable, input sequence that leads to
the hash value. 

Here's the drill:

1. Before protecting the document, save a copy with the lock not set, for
use in making future versions, modifications, etc.  (Or obtain the handy
utilities described in (4).)

2. Now, for the copy that is going to be distributed for people to use,
directly set the table:protection-key attribute using the following
procedure:
   2.1 Using a cryptographic random number generator, generate a 160-bit
random sequence stored in 20 octets.
   2.2 Convert the 20-octet sequence to a (30-character) Base64 encoding.
   2.3 Insert the table:protection-key attribute with the Base64 value on
the


  • 6.  Re: [office] Table Protection: Uselessness of table:protection-key

    Posted 01-05-2009 13:29 
    Dennis, all,

On 03.01.09 14:26, Patrick Durusau wrote:
> Dennis,
> 
> 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 
> standardizing.
> 
> 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.

I agree to this, and in particular would like to point out that a 
digital signature for a piece of a document and a protected piece of a 
document in the sense that the editing applications does not allow 
modifications to it are two different things.

A digital signature ensures that modifications to an ODF document can be 
noticed. But it does not prevent that modifications can be made. It is 
entirely up to the application whether it allows modification of a 
signed documents (or document piece) or not, and what happens to the 
signature information if a document is changed.

The "protection" features again simply says that a piece of a document 
should not be editable. Maybe the name "protection" is not the best, 
although "protect" is a very general term. It is not a terms like 
"secure", "signature" or "encryption" which have their predefined 
meaning in the IT world. And "protect" is only the term we use in the 
ODF specification. Applications may call this feature whatever they want 
to if they believe the term  "protect" leads to wrong expectations.

Two more remarks:
- Even if protected content would get signed, it still would be possible 
to remove the signature itself. That means, the existence of signature 
itself does not protect a document from getting edited.
- We have a lot of other features that have similar issues. Take for 
instance a control for a fixed text. An application that has a mode for 
filling out the form data probably will not allow to change that text. 
But a form editor will by intention do so. And in any case, it is 
possible to change the text in the ODF document itself.

Best regards

Michael




-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering


  • 7.  RE: [office] Table Protection: Limitation of table:protection-key hash values

    Posted 01-06-2009 04:57 
    Michael, 

By the way, I agree that the discussion of table:protection-key and
table:table:protection-key-digest-algorithm is unrelated to the proposal
about Table Protection that is part of the final five proposals.

I agree with your and Patrick's observation about our limited ability to say
much about the security regime that might be employed around ODF documents.
I also think there also needs to be a declaration with regard to
table:protection-key not being a security measure.

With regard to digital signatures, I think we should keep in mind that a
document in which the signature has been removed or replaced by that of
another can always be repudiated by the person who is alleged to have
produced it.  With the digital signature retained, it is difficult to
repudiate the signature on that which is signed.  

In contrast, any ODF document having only table cell protection, with or
without table:protection-key, can always be repudiated and, in fact, can be
altered and "forged" to use the same table:protection-key attribute value.
That is, table:protection-key is a weak deterrent and not a security or
authenticity measure.  For the degree that table:protection-key is useful,
the quality of the message digest algorithm is irrelevant.  That is so
stark, I believe there is a professional, ethical responsibility to say
something about it, especially when there is currently encouragement of the
idea that stronger cryptographic hashing methods are somehow better and to
be preferred with respect to table:protection-key.

The text that I offer to explain this for the table:protection-value
attribute is near the end of
http://lists.oasis-open.org/archives/office/200901/msg00010.html and
extracted here:

[[
The table-cell protection feature is provided as a safeguard against
accidental alteration of cells that are kept fixed in order to achieve an
intended purpose, such as use of tables as part of a form for data
collection and reporting.

The locking of table-cell protection is provided as a safeguard against
careless over-riding of the table-cell protections.  Cell locking is not a
secure protection against unauthorized and un-noticed alteration of the
protected table cells.  Knowledge of the password is not required in order
for a knowledgeable party to over-ride the locking by manipulation of the
XML document directly.  Knowledge of the password is not required in order
to deleted the table:protection-key attribute nor to use it for the
locking of protected cells of other tables. 

The hash code protects against casual discovery of the password by
inspection of the XML.  Hash codes of short texts such as memorable
passwords are easily attacked regardless of the strength of the hash code.
The consequences of password compromise can be limited by not using a
table-cell protection password for any other purpose.  The compromise of
passwords can be prevented entirely by generating random hash-code values
without choosing any password at all.
]]
 


 


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content