Data encryption

[Eric Maeker]

Le 26/07/2014 02:50, Jérôme Pinguet a écrit :
>>> >> Is there a plan to use the password to encrypt MySQL or SQLite
>>> >> databases? :-) Good candidate for sqlite: http://sqlcipher.net/
>> > Nop, the current option is to encrypt the hard drive or partition
>> > containing the databases (SQLite/MySQL/PostGre) instead of crypting
each
>> > entries in the db.
>> >
>> > May be someone can write a small doc for such a configuration on
the wiki?

> Encrypting the disk or the partition that contains the SQLite database
> is a very good idea indeed, probably far superior in terms of security
> to encrypting only the SQLite database itself.
>
> It can easily be done on Linux using either full disk encryption (an
> option available during installation of Debian or Ubuntu, using
> LUKS/cryptsetup) or transparent home encryption using the login password
> (ecryptfs). Both levels can be combined, and set up after installation.
>
> Full disk encryption is quite easy on MacOS X (FileVault) and can be
> also be used on Windows (BitLocker), despite recent proofs that every
> Microsoft encryption scheme is broken because of US government backdoors.

May be someone can create a wiki documentation here

http://freemedforms.com/en/manuals/freemedforms/install/data_encryption
http://freemedforms.com/fr/manuals/freemedforms/install/data_encryption

and add the link to the FMF table of contents

http://freemedforms.com/en/manuals/freemedforms/toc
http://freemedforms.com/fr/manuals/freemedforms/toc

> It can be applied to a MySQL server which would be on the same computer
> as FMF.
>
> The problem is different for a separate MySQL server used in a network
> setting. Full disk encryption means that any reboot (power failure,
> kernel security updates) requires the physical presence of the sysadmin
> to type the password on a keyboards directly connected to the server. A
> solution like Mandos https://wiki.recompile.se/wiki/Mandos can mitigate
> the need for full time sysadmin availability: the rebooting main server
> takes the GPG encrypted keys from another small server (could be a
> raspberry pi) in the same network through TLS. But it gets complicated
> and costly for small networks.
>
> Encryption at the MySQL server (full disk or AES_ENCRYPT inside MySQL)
> level only means that connections towards the MySQL server need to be
> encrypted too. One can use SSH tunnels to forward MySQL ports over a
> network. I've set this up on several networks for medical practices. The
> SSH tunnels allow for secure connections even during house calls, or
> enable the practitioner to access patient's data and work from home.
>
> So, for the separate MySQL server, encryption of database content could
> be a good feature worth adding to the roadmap.
>
> For SQLite, sqlcipher.net announces a loss of speed of only 5% to 15%.
>
> For MySQL, it would be wiser to implement encryption before data is even
> sent to the MySQL server. As we've seen with recent requests, lots of
> users will be tempted to use externalized MySQL servers rather than
> setting one up locally under locked doors. Thus, beginning to think
> about encryption is a good idea before FMF spreads to the whole world!
> ;-) It would also help us get approval by certification agencies.
>
> Eric, in your opinion, what would make it difficult to AES encrypt (with
> symmetric 128 bit key) data before it is sent and stored on MySQL (or
> SQLite) in the present state of FMF code? Is there a lot of work done at
> the database level, such as column ordering or row sorting? I admit it's
> a bit difficult to sort encrypted data at MySQL or SQLite level! :-)
>
> I hope I can advance my study of C++ and cryptography quickly enough to
> code such improvements myself. Maybe for version 1.1 in 2015? :-)

;) You are welcome!

--
Eric Maeker
GPG: C217 B1B7 80E8 0381 FD5B C3A5 75D4 AE85 B952 0933

[Eric Maeker]

Le 27/07/2014 12:19, Eric Maeker a écrit :
> Eric, in your opinion, what would make it difficult to AES encrypt (with
>> symmetric 128 bit key) data before it is sent and stored on MySQL (or
>> SQLite) in the present state of FMF code? Is there a lot of work done at
>> the database level, such as column ordering or row sorting? I admit it's
>> a bit difficult to sort encrypted data at MySQL or SQLite level! :-)

Yes, some database are accessed by models (patients table, PMHx...).
We can add a proxymodel with an encryption layer. But if I'm right the
private key should be shared between users, otherwise what user1 writes
user2 can not have any access to. So this key should be included inside
the code but this is a serious breach...

I think we can crypt patient names (usual name, first name...), using an
option. May be we can also crypt the date of birth. Then, it will not
be possible to rebuild the patient medical status without the private key.

My concerns are:
- how can I store this private key inside an open sourced code?
- is this really useful (if you keep in mind the breach)?

Thanks for your comments

[Jérôme Pinguet]

I have to look after this thoroughly, but one possibility that comes to
mind is using public key cryptography:

Each user has a GPG key pair automatically created when the user is created.
This user's GPG private key is encrypted with the user's login password.
All users' public keys are stored in the database and accessible by any
user.

Then, you have the possibility for user A to grant access to the data to
user B by encrypting the symmetric key with user B public key and
putting it in a shared table of the database.

Another possibility is to use Shamir's Secret Sharing.
http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing

This would be cool because then a user has total control about the data
he or she produces: you can decide not to share personal notes about a
particular patient with colleagues, but to share everything else (AFAIK
in France there is a subtle legal distinction between patient's own data
such as exam results, biological results, objectives measurements, and a
doctor's personal notes about the patient, that legally "belong" to the
physician).

The important thing to have in mind is that secret sharing is easy and
already implemented in various forms and programming languages (see ssss
Debian package): if a user is sick or incapacitated, we can build a
system where it's possible to retrieve the not personal data (in a group
medical office of 4 practitioners, the rule could be that 2 out of 4 can
have access to everything, so if 1 doctor is ill and the other is on
vacation, the remaining two can have access by joining their secret shares).

We can also imagine giving out to the patient (and to a trusted third
party: family, tutor, legal institution) a share of the secret so that
data is not lost if anything happens to one or more share holders. It
can be printed on a small piece of paper, so no tech knowledge is
necessary to hold the secret for long term. Companies are already in
this business for Bitcoin based stuff, testament, etc. It makes abuse of
socially owned values (public or company money) really difficult.

It's similar to old ideas about depositing all the data in professional
association's hands (such as Conseil de l'Ordre in France), but without
the need to rely on a central authority prone to abuse and curiosity.

With cryptography, everything that required a central authority can be
done without this central authority. That's "crypto magic". :-) It will
probably change many things in the way human societies organize themselves.

I guess we could have a look at other free software projects that
implement secure user access policy to databases.

Granting access could be automatic or manual. We could achieve precise
access control by using multiple symmetric keys. So accounting data
could be accessed by accounting people, but not medical data, because
the symmetric keys used are not the same.

I'll look into it more thoroughly next week, now I have to complete this
week's Stanford Cryptography I on-line course tests before the deadline
(https://www.coursera.org/course/crypto). ;-)

jérôme