[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Health-dev] Build encyption example into live-CD?

From: Emilien Klein
Subject: Re: [Health-dev] Build encyption example into live-CD?
Date: Mon, 24 Nov 2014 05:24:25 -0600

2014-11-21 3:40 GMT-06:00 Axel Braun <address@hidden>:
> But back to the original question....obstacles against a demo-key?

Shipping crypto keys, in particular if private keys is involved, isn't
good practice.
It should be shipped only if it would render the system unusable out
of the box, as e.g. the RaspberryPi image's keys for the SSH server.
If they didn't ship the keys with the image, you wouldn't be able to
connect to it via SSH the first time you boot, and for people that run
headless/keyboardless installs (as I do) it would render the system
unreachable. The recommended approach is to regenerate the keys after
the first log in [0].

For GNU Health's live CD, if possible the keys should be generated on
the fly the first time it is run.

Would something like this be possible?
A script is set up to run when the system starts up (using @reboot in
cron), which will check if the keys exist.
If keys do not exist, the key generation command is launched.
If keys exist, do nothing.

This will have a very minimal performance impact starting with the
second boot sequence, and ensures everyone has unique keys.

Reason why shipping keys wouldn't be a good idea:
Even if this only a demo system, you can be assured that at least
someone, somewhere, maybe with limited sysadmin skills or knowledge of
encryption, will test the demo live-CD, be so enthused by it that it
will use that as the basis for their production system.
As in "Hey, what the heck, if it works nicely out of the box, and I've
read that this "Linux" thing is secure, since I don't know much about
it I'll just run the Live CD that is officially published. It has to
be secure, right?".

And then when patient information is stolen from their PRD system, the
only thing we'll be able to help with is send reproaches: "you
shouldn't have done that, haven't you followed all the instructions on
the wiki?" (once it's updated ;) ) That's not very helpful to our
users, and even less to their patients who have their private medical
information floating around.

Better be safe than sorry. If it's difficult for us, but easy for
them, we should take the extra step and have the keys be generated on
the fly instead of shipping the same keys to everybody.

Let me know if you think this doesn't make sense.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]