"correcting" transactions

[Derek Atkins]

Mark Rousell <markr at signal100.com> writes:

> This is an interesting issue, isn't it.
>
> I don't know the answer to this question: Has there been any thought
> given (either in GnuCash specifically or in general) to finding ways of
> 'locking' a file that an application program cannot arbitrarily remove
> later?

Only by use of a trusted third party.  You could effectively get data
"notarized", which would create a signature on the data that would let
you know if the data changed.  However anyone who has access to the
notary key could re-notarize that.  Which means you cannot do it
yourself, because you would have the key (which means you could
re-notarize it).

> One possible approach that occurs to me is to use public key
> cryptography. This approach is plausible but has obvious limits (which
> I'll outline below). Here is the approach I have in mind:
>
> (1) The application encrypts each block of new records (a 'section' of
> records) being written to the data file with a private encryption key
> that it then forgets. This is done for all new data being written to the
> data file.
> (2) So as to be able to read the section of encrypted data, the app
> keeps the corresponding public key (this could perfectly well be kept in
> plaintext in the data file).
> (3) Each section encrypted as per (1) above could include a hash of
> previously written data sections so as to make sure that individual
> sections of the data could not be trivially swapped out.
> (4) A particular public-private key pair would last for a definable
> period of time or number of new records. (E.g. 10 new records, one hour,
> one day, or whatever is preferred).
>
> The advantage of this approach is that old records written with a
> forgotten private key can be read but cannot be altered.

The fact remains that someone could recreate the whole shebang.  You
don't know whether the data should start with Key0 or Key0' -- so an
attacker could just start over.  Same with the hashes.  Remember that
GnuCash writes out the whole XML data file every time.  (it's different
in SQL, but that has other issues with protecting contents).

[snip]

> Thoughts, anyone? I imagine this approach has been considered before but
> I feel it is worth mentioning.

This style of protocol works great for communication of data, data
streams.  It works best when there are multiple parties so there is
ready detection of misuse.  It doesn't work well for "documents".
GnuCash is more of a document than a data stream.  All the keys would
necessarily need to be stored with the data file, which means anyone
could replace those keys with otherwise replacement keys.  There's no
good way to bootstrap the system securely.

Moreover, it's just too convoluted for the perceived benefit.  If you
want to prove that data hasn't changed then put it onto a read-only
media like a CD-ROM and place it into a vault.  Voila, you now have
proof of content at a particular time.

Just a reminder that GnuCash is NOT an ERP system.  It's not an
Enterprise Accounting Package.  It's designed for the personal (and
small office) environment.  If you need auditing, GnuCash is not for
you.  Sorry.  Having said that, GnuCash has the ability (in 2.6) to
prevent you from making silly mistakes by entering transactions before a
date you set.  However that's no guarantee it CANNOT be done, just a way
to prevent you from accidentally doing it.

Intent is important; we cannot (and do not try to) protect against an
intended adversary, only an accidental one.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available