"correcting" transactions

[Mark Rousell]

On 25/02/2014 15:49, Derek Atkins wrote:
> Mark Rousell <markr at signal100.com> writes:
> 
>> 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:
>>
[...]
> 
> 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, however, that what you describe here is not a problem unique
to GnuCash. Any closed source software suffers from the identical
problem. As I said in my earlier message (added text in square brackets):

	Admittedly, Bad Programmer can still try to hide those
	unalterable records or hard code the program to display
	different information in relation to them [in GnuCash], 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 ["it" being encryption
	of already-written GnuCash records to make them unalterable
	within an existing data file].

In other words, there is no need to try and fix every single problem
that might exist in *all* such software (both open and closed source)
from within GnuCash. The approach that I suggested merely brings GnuCash
into parity with closed source software in this context (i.e. preventing
alteration of earlier-written records).

> Remember that
> GnuCash writes out the whole XML data file every time.

This is not a problem. Previous data sections only need to be re-written
exactly as-is. I.e. They can be cached for re-writing as-is when the
file is saved.

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

As above, this is outwith the context of this issue. I.e. As per my
comments above and in my previous message, a theoretical attacker could
do the very same thing to the data files belonging to closed source
software.

> There's no
> good way to bootstrap the system securely.

Just as with closed source software, that is a matter of security
precautions outside of the software itself.

The only issue I have addressed here is how, *within* *an *existing*
*data* *file*, arbitrary changes of existing data can be prevented. My
approach seems to address that issue, thus bringing GnuCash into parity
with closed source software in this very specific respect (and possibly
improving on what I suspect is much closed source software's security by
obscurity model!).

Outside of that, it seems to me that the problems faced by GnuCash (e.g.
replacement of data files in their entirety) is identical to those faced
by closed source competitors and thus does not need to be fixed by GnuCash.

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

Fair point.

That I said, I don't see it as overly convoluted. But then I would say
that, wouldn't I. ;-)

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

Yup, GnuCash is not an enterprise system. But even quite small
businesses, i.e. those at whom GnuCash is targeted, can have a
reasonable need for auditability and non-editability *within* *an*
*existing* *data* *file*.

Yes, as you say and as I observed in my previous message, the data file
could be replaced in its entirety by an attacker but, as I have also
observed, this risk applies equally to closed source software and so
does not need to be fixed within GnuCash.

My encryption approach merely offers auditability and non-editability
*within* *an* *existing* *data* *file* which would put GnuCash on parity
with closed source software in this respect (and possibly put it ahead
in that it would use encryption rather than obscurity).

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

Fair enough, although I would say that 'locking' already written data in
an existing data file is more than about fighting an attacker (although
it has been discussed so far in those terms). It is also about helping
legitimate users ensure integrity of data within an existing data file,
and this is surely of interest to users of all sizes.

Yes, my suggested approach says nothing about the risk of entirely
replaced data files but, as I have discussed above, I think that is a
problem common to both closed source and open source accounting software
and the solution to that problem (which is a separate issue to that of
auditability and non-editability within a single data file) lies in
security procedures outside of the accounting software itself.


-- 
Mark Rousell

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