backend encryption / security

[Derek Atkins]

"Michalis Kamprianis" <michalis at linuxmail.org> writes:

> Hi all,
> thank you for the valuable feedback. 
>
> Let me start by saying that programming is not something I'm current
> at - I haven't written anything longer than 10 lines, for more than 8
> years so you get an idea. On the other hand, security (design,
> architecture, consulting) is what I'm really good at, and some of the
> comments that I read do not make much sense from a security
> perspective.

I, however, am a programmer, *AND* I've been in the Internet Security
Industry for over 20 years, so I'd like to think that I know what I'm
talking about both from an architecture/design standpoint *AND* from the
practicality of implementation standpoint.

> I'll try to elaborate as much as I can without getting too technical -
> but I'm willing to do so if required. 

Well, this *is* the -devel list, so getting technical is certainly an
option and not necessarily out of scope.

> a) Why: for one, because users want it. It has 100 votes in uservoice,
> and I personally believe something like that should be standard in any
> financial application no matter what we think about other people's
> data sensitivity.

Users historically really don't know what they want.  They will "want"
things that aren't reasonable, or "want" things that sound cool.  But
really, users just don't make good judgements.  I've seen this over and
over and over again in the security field.  Users just don't know enough
to make good choices; they don't understand the tradeoffs that need to
be made.  "Oh, I'd like to use 4096-bit RSA with 512-bit AES and
SHA3-768."  (Yes, I know that this doesn't exist).

> b) Why not encrypted filesystem: There are several reasons, some of
> which are that encrypting a whole filesystem for a single file is an
> overkill, that one might use gnucash in his work pc not having the
> option to encrypt the filesystem, that one might use the portable
> version, again not having the option to encrypt the filesystem, that
> one might carry between systems the datafile on a usb, again without
> encryption, backing up the file on a usb, a tape, a cloud service and
> so on. 

GnuCash doesn't create just a single file; it creates dozens or hundreds
of files (c.f. backup files, log files, metadata files, config files,
etc).

There are many ways to set up encrypted file systems.  For example I'd
recommend EncFS on FUSE-compatible systems which doesn't encrypt the
whole filesystem but instead provides for an "encrypted directory tree"
where everything under the EncFS root gets encrypted on an
inode-by-inode basis.

There is also TrueCrypt, PGP Whole Disk Encryption, and many other
options as well that let you set up encrypted partitions (again, you
don't need to encrypt the whole filesystem, just provide a "protected
space").

All of these options still provide the possibility of protected backups.
Moreover, all of these systems are implemented by people who generally
understand security and it is their core competency.

> e) implementing encryption should be left to encryption specialists: I
> totally agree, that's why I researched and suggest to use aescrypt
> code. it is there, cross platform widely used, based on standards, so
> it's much more better than anything I could (and I believe any gnucash
> developer not involved in secure programming) implement. In an
> essense, the suggestion is not to write encrypt/decrypt functions, but
> rather to use existing ones and integrate them.

The problem here is the interpretation of the term "implement".  You're
defining it as the implementation of the AES algorithm.  I'm defining it
as the implementation of the *application*.  Encryption is more than
just providing confidentiality..  There is a huge key management
problem.  I certainly do not want to be the person at the end of the
phone (or email) when a frantic user who hasn't used GnuCash in 3-6
months can't get into their data because they forgot their password!

> f) log files, backup files etc: as I said, I am not sure if I can pull
> it off due to my limited programming skills. I can tell you how it
> should be done though: The key should be provided by the user
> on loading a  file, be kept in program memory, and be used for any
> load/save function. That should take care of all relevant files in
> disk (the profile is a different thing). Actually, this is as secure
> as it can get wr to data at rest, because data is never
> written unencrypted - it's only on system memory. Now, taking the
> user's key and storing it somewhere in software memory, to be there
> for as long as the file is open, is something that I don't know how to
> do (yet). 

Keeping the key around in memory is usually SOP (although sometimes it
gets kept around in an obfuscated manner to prevent cold-boot memory
scraping attacks).  It's definitely necessary to have it around when you
click save, and I suspect users would not want to have to re-enter it
every time they re-save their work.

However there may be a lot of places to hook to properly get backups,
logs, metadata, etc.  Also, what about SQL?  You're only thinking about
the XML data but ideally that will be going away before the end of the
decade.

> Having said all that, I'm not really dying to implement it!
> I just thought it would be a nice addition that a user might choose to
> use or not - I definitely would. If you don't agree, no harm done,
> I'll drop it and move to the next target :)
>
> Kind regards
> Michalis 

-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