>
>
> >
> > In addition to that, a separate encrypted partition for
> /root (or
> > /home
> > if the account will changed to a non-privileged user) could be
> > nice, but
> > maybe too heavy and battery draining?
> >
> >
> > Imho it's not needed to encrypt the whole system.
> > Would be the better choice to have some crypto-containers for the
> > files that really need to be secured (phonebook, messages, important
> > documents). We had some discussion in IRC a while ago and my
> idea would
> No, not the whole system. But well the user homedir would be basically
> what we want to protect, and if it was on it's own partition, there is
> kernel support for it already.
> > be to have that containers and a daemon in background who handles
> > encryption/decryption, asks for passwords if needed and makes sure
> > that applications who want access to a encrypted container get it
> > (e.g. dialer wants to look up a number in the phonebook).
> > This way the containers can stay decrypted while the phone is on and
> > access is granted dynamically (as needed).
> I think completely dynamic decryption would be too cumbersone to
> use. If
> you mean that it would need an unlock for every received sms (to
> get the
> contact behind the number) and phone call, it's just unfeasible.
> If you
> want to protect the en/decryption key, it needs a passphrase that is
> long enough to be of any benefit. The other option is a PKI
> enabled SIM,
> which would be cool. Hence it should be unlocked only once, at bootup.
> The sim pin could also be saved on the encrypted partition (maybe the
> pin itself again encrypted with the passphrase, so it's not accessible
> easily at runtime) so that the user only needs to authenticate once to
> use the phone. There could be then options to forget the
> encryption key
> either locally or via a "magic sms".
> > Yeah, it's a little much effort, but there is no security
> without it.
> > If you'd encrypt the whole rootfs you'd have it decrypted the whole
> > time the phone is on (otherwise nothing would work), what means, the
> > security is gone.
> No it doesn't. Everything NEEDS to be decrypted automagically when the
> phone is on. Otherwise it's just unusable. The whole system
> shouldn't be
> encrypted, that's just waste. But having a personal area decrypted at
> startup means that only you can access it at bootup, and one can
> add the
> option of remotely disabling access to it. That is very much security,
> way more than phones usually have nowadays, even more than
> laptops/desktops, but not too much to make it hard/annoying to use.
> > Well, that's only a part of a possible security framework, but this
> > are only some thoughts.
> >
> >
> > In addition to that, I'd say all linux security
> administration best
> > practices should be at least considered, including automatic
> security
> > updates.
> >
> >
> > It's a standard linux system with a lightweight, but still standard,
> > packet management, so that's how it already is handeled (well,
> without
> > the automatic, but I don't like automatic updating anyway).
> >
> The fact that it has package management doesn't mean much in itself. I
> think current linux distributions have a pretty good model. A separate
> security updates repo, which just releases security patches, and since
> these are an security update of the recommended version, they don't
> (well shouldn't) break anything, so they can even be pretty safely
> applied automatically. Again, defaults matter. If you need to log in,
> run opkg update; opkg upgrade I bet that most of the phones never get
> patched.
>
> Cheers,
> Kalle
> >
> > After the basic security is in good shape, one could move on
> to fun
> > things like phone lock/unlock/shutdown with an sms, personal
> data
> > backups / remote removal... the possibilities! :)
> >
> >
> > Possibly to be implemented in a (modular) "security-daemon", as
> > mentioned before.
> >
> > Cheers,
> > Kalle
> >
> > Yorick Moko wrote:
> > > This mail was posted on the devel list
> > >
> >
> (
http://lists.openmoko.org/pipermail/openmoko-devel/2008-July/003594.html).
> > > Thought it would interest a lot of people who are not
> subscribed to
> > > that list:
> > >
> > >
> > > Hi Guys,
> > >
> > > a few months ago we have planned to improve the security
> of our
> > beloved
> > > Neo, after we have read about desires of the community
> regarding
> > to the
> > > security issue.
> > >
> > > And here we are. Today I will present you our project MokSec.
> > >
> > > What is MokSec?
> > > ===============
> > >
> > > MokSec is framework which target is to improve the security of
> > the mobile
> > > devices which are based on OpenMoko (and other frameworks
> which
> > are running on
> > > Neos)
> > >
> > > What is our main focus at the moment?
> > > =====================================
> > >
> > > The main focus is the encryption over GSM. This is very
> > complicated issue and
> > > for this we searching developer which are willing to work with
> > us on this
> > > interesting project.
> > >
> > > What are the other components?
> > > ==============================
> > >
> > > At the moment we only working on a phone firewall, which
> will be
> > > blocking/accepting incoming calls. Later one we will add other
> > projects or
> > > developer will be able to add their projects.
> > >
> > > Were you can find more informations?
> > > ====================================
> > >
> > >
http://moksec.networld.to : The
> main page
> > >
http://moko.networld.to : The git
> > repositories
> > >
http://networld.to/mailman/listinfo/moksec-public : The
> mailinglist
> > >
> > > We hope that a lot of people will work with us on the security
> > issue.
> > >
> > > Happy programming
> > >
> > > Alex Oberhauser
> > >
> > > _______________________________________________
> > > Openmoko community mailing list
> > >
community@lists.openmoko.org
>
> >
> > >
http://lists.openmoko.org/mailman/listinfo/community
> > >
> >
> >
> > _______________________________________________
> > Openmoko community mailing list
> >
community@lists.openmoko.org
>
> >
> >
http://lists.openmoko.org/mailman/listinfo/community
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Openmoko community mailing list
> >
community@lists.openmoko.org
> >
http://lists.openmoko.org/mailman/listinfo/community
> >
>
>
> _______________________________________________
> Openmoko community mailing list
>
community@lists.openmoko.org
>
http://lists.openmoko.org/mailman/listinfo/community
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Openmoko community mailing list
>
community@lists.openmoko.org
>
http://lists.openmoko.org/mailman/listinfo/community
>
