OASIS Open Document Format for Office Applications (OpenDocument) TC

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,

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

Hi

2009/1/3 Patrick Durusau 

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-----
From: Bob Jolliffe [mailto:bobjolliffe@gmail.com] 
http://lists.oasis-open.org/archives/office/200901/msg00008.html
Sent: Saturday, January 03, 2009 10:17
To: office@lists.oasis-open.org
Subject: Re: [office] Table Protection: Uselessness of table:protection-key

Hi

2009/1/3 Patrick Durusau 

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 

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

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-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
http://lists.oasis-open.org/archives/office/200901/msg00016.html
Sent: Monday, January 05, 2009 05:29
To: dennis.hamilton@acm.org
Cc: Patrick Durusau; ODF TC List
Subject: Re: [office] Table Protection: Uselessness of table:protection-key

Dennis, all,

On 03.01.09 14:26, Patrick Durusau wrote:
http://lists.oasis-open.org/archives/office/200901/msg00007.html
> 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

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