[Freedombox-discuss] freedombox & blackhats
Am Dienstag, den 01.03.2011, 11:29 +0000 schrieb Matt Willsher:
> On 1 March 2011 11:11, Florian Hofmann <florian at fhaust.de> wrote:
> > [this should have gone to the whole list but i messed it up]
> > 2011/3/1 Matt Willsher <matt at monki.org.uk>:
> >> On 28 February 2011 23:54, Florian Hofmann <florian at fhaust.de> wrote:
> >>> My first thought on that title was that it is as easy to install a plug
> >>> server as it is to snatch and make a run with it...
> >>> As pointed out before data security is the prime objective in this case. And
> >>> imho this means full disc encryption and stuff... which in return brings the
> >>> inconvenience of unlocking the discs at boot.
> >> Given the devices are cheap, maybe repudiation is an option? If the
> >> plug goes missing the user has a way of invalidating that plug so it
> >> can be used to access their data on it or its backups.
> >> As a key for decryption of the disks a usb pen is an obvious choice
> >> but then that's also a physical form so not ideal - if someone swipes
> >> the plug perhaps they will also get the users usb drive.
> > I don't believe attachable media is the key here. Even if you'd only
> > had to plug a usb stick in at boot it would be inconvenient. On the
> > default encryption mode is ecrypt
> fs which is unlocked at the moment
> > you log into the machine. Maybe it would be possible to integrate a
> > similar solution into the authentication of private services. Eg you
> > try to get your mails over IMAP but the related folders are encrypted.
> > The system takes your Imap credentials and uses them to unlock the
> > ecryptfs encrypted folders. Once unlocked they would stay this way
> > until the next reboot.
> Good point. A PAM module would be a good starting point for this kind
> of thing. I think that's the way Ubuntu does the encrypted home
> directory. If PAM is used for all authentications, any authentication
> could unlock the data store.
> What about cases were new data is in bound? It would need to be stored
> unencrypted or reject until sure a time as the encrypted store became
You're right, all the work on the PAM has been done by the Ubuntu guys.
The whole setup isn't hard either (i set it up on our server before it
was implemented in Ubuntu by default).
The problem is to have several services with potentially different user
names and passwords. Maybe a multitier approach would be needed here:
Tier 1 is the users password which is used to decrypt the userrelated
stuff _and_ a key for the second tier which would be the service related
Then this system would have to be implemented for every service in
> > Another approach would be a webbased unlock screen where you'd have to
> > type in your encryption password once after boot. But i guess this
> > would encourage people to set an empty password cause most of us are
> > lazy aren't we? ;)
> This could be an option but the PAM module would take care of the
> mounting of the storage.
Just pointing out an easy alternative to the above ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part