[Freedombox-discuss] Security Services

James Vasile vasile at freedomboxfoundation.org
Mon Mar 5 15:27:47 UTC 2012


On Mon, 5 Mar 2012 07:28:30 -0700, Jack Wilborn <jkwilborn at gmail.com> wrote:
> Hello all,
> 
> New to this, hope this goes to the correct place...
> 
> I worked for a financial institution a number of years ago where we faced
> similar problems with data security.  What I seem to notice is there is no
> specific direction of what you want to secure.  I've seen it go around the
> file system, stolen boxs and to USB keys, where they are on the machine or
> someone has to put them is doesn't seem workable.  Has it been set as to
> what level we are trying to protect?  I.E. is the file system, in tact in
> the system or do we worry about the removal of the system disk, by
> perpetrators?  Are you just trying to stop a thief getting to the stuff via
> a reboot and then the normal brute force tactic to break in?  I seem to get
> the hint that you want to encrypt everything you can.  How fast is the
> crypto mechanism in the ARM processor?

There are many ways to lose private control of your data.  A stolen box
is one.  Insecure network access is another.  The USB key is more of a
way to carry the Santiago access software than a way to auth.

I worry about removal of the system disk and brute forcing the data.
I'm not sure how to protect to that level, though.  That's why I'm
always interested in people who have ideas on how we might do that.

We do want to encrypt where we can.  There are hardware limits, as you
suggest, but right now speed isn't an issue on encryption.

> 
> Have you thought about the public key being kept by another system and
> required when booting.  This key doesn't have to be labeled as 'public',
> but kept and used as normal security keys are kept.  This makes the key,
> required when booting but not available unless the connection to another
> machine is made properly.  Another shot is boot to a certain point and wait
> until you authenticate another user and that user is also authenticated,
> before standard use returns.  Also, the number of attempts to get in is
> also notification of an attempt to breach the system security.

Yes, those are all good thoughts.  Assembling them into a working system
is the obstacle.  I don't see how to keep a key off site and maintain
security (not to mention user friendliness).

> 
> If I remember correctly, we authenticated a machine connection, but stopped
> short of bringing it up until a known user was authenticated.  There is a
> time delay when the first user logs in, but it's minimal.  Another
> difference is that we didn't have to worry about someone taking the
> hardware, ours was in a facility that was always locked down.  But the
> communications lines were vulnerable, so the machine was in a state of
> recovery for a number of minutes.

I'm not quite sure how a scheme like that addresses the current concern
over physical custody.

> 
> The only real difference is how far do you want to boot before security
> comes into scope?  Maybe just enough to get a connection, then
> authenticate, load or fail.

What is the authentication in the FreedomBox case?  What does successful
auth prove (and to whom)?

> 
> Please, if I'm totally off, let me know and I won't bug you about it.  I
> was only responsible for a few trillion dollars that could disappear in a
> few minutes....

I'm sure your experience has value.  I'm struggling a bit to connect
your thoughts to our specifics, but I do want to hear more.

Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20120305/21931913/attachment-0001.pgp>


More information about the Freedombox-discuss mailing list