"correcting" transactions

[Mark Rousell]

On 21/02/2014 10:36, Maf. King wrote:
> But.... gnucash is open source.  there is nothing to stop the bad guys taking 
> a copy of the source code, modifying it to not check (or always accept) the 
> CRC on load, then calculating a new CRC on exit which would be valid for 
> "proper" gnucash, 
> 
> Then bad guy takes the data file, massages some figures (in a text editor if 
> need be, or with enough motivation, bit-banging directly on the hard-disk, 
> saves it and runs through the modified GC - how will joe honest user detect 
> that change.  The CRC will say that all is well. 
> 
> False security is worse than no security in some cases?  
> 
> I don't think there is a good answer to this - just because GC is open source 
> only makes the exploit easier to implement and detect.  With enough 
> motivation, the bad guys could subvert any accounting package in the same sort 
> of way, and how could you check if the version of whatever closed-source 
> program you had actually matched the good guys intended source code? (and I 
> don't want this to descend into open/closed source flame wars...)

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?

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.

However, it suffers from much the same problem outlined in Maf's message
above: That a 'Bad Programmer' could alter the program to remember all
its private keys or to cease using encryption at all. However, I still
perceive this approach to be an advance on the current situation in
that, no matter what Bad Programmer does, he or she *cannot alter
records that were written to the data file before the program was altered*.

Admittedly, Bad Programmer can still try to hide those unalterable
records or hard code the program to display different information in
relation to them, but I still see this approach as a potential
improvement. The same issue that a Bad Programmer could subvert the
display of data files belonging to a closed source program (by back
engineering the program or its data file format or producing a
lookalike) exists, so it is not a problem unique to open source, meaning
that it is not a reason not to pursue it.

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



-- 
Mark Rousell

PGP public key: http://www.signal100.com/markr/pgp
Key ID: C9C5C162