RE: MokSec - The Security Framework

[Knight Walker]

Apologies for the tardiness of this post.

On Mon, 2008-07-14 at 10:57 -0400, Crane, Matthew wrote: 
> I would think on a phone the primary concern is protecting the user
> data.  
> 
> E.g. sms, contacts, history. 
> 
> If somebody was able to malicously install software on the phone, your
> pretty much already [EMAIL PROTECTED]'ed.  Not letting it call out helps, but 
> it's
> already defeated.  I'm assuming we're not installing a lot of new
> unknowns on a secure device, and anything trying to make network
> connections is evol. 

You're forgetting a large attack vector: social engineering. It doesn't
require someone being able to maliciously install something for it to
get on your system, especially once Moko repositories start to flourish
and organizations setup their own for specific apps/purposes.

Additionally, having used several mobile phones (Smart and otherwise)
often it is helpful to be able to decide what abilities a piece of
downloaded software will have (e.g. a game doesn't need to look at my
address book).

You're also assuming that it's a "secure device" and that the owner will
know how to keep it that way. From experience, I can tell you that as
soon as non-geeks get a hold of this phone (Presumably sometime this
fall) device security will go out the window.

> I've been picturing running an encrypted rootfs image off an SD card.
> There could be multiple encrypted rootfs images, only one would be the
> real one, or they all could be used for different reasons.

Not a bad idea. I had to do something similar with my Zaurus 5500
several years ago because 14M of storage is not enough. However with the
FreeRunner, I do actually want to keep my rootfs on the rootfs and use
the card(s) for different data sets.

> Once the system boots it's up to the user to unlock the keys to the
> encrypted image to be used and that gets booted from the already running
> kernel. 

Then what happens if you leave the system in sleep mode and accidentally
leave it somewhere and it "wanders off"? You've unlocked the rootfs
already, so as long as the attacker doesn't reboot the phone, they've
got access.

-KW


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Henrik Andreasson]

On Mon, 14 Jul 2008, Adrian-Ken Rueegsegger wrote:

I'm in posession of such a smartcard and a neo.
Anybody want to join up in a effort to get it working ?


> Jan de Haan wrote:
>> On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen <[EMAIL PROTECTED]> wrote:
>>> But there are places where
>>> you can get SIM cards with built in encyption/decryption keys, and a
>>> certificate (PKI).
>>
>> I agree. Would you care to elaborate (link)?
>
> There's a manufacturer of a microSD smartcard [1] in Germany, which
> looks quite promising. Such a smartcard could be used in many security
> applications.
>
> Cheers,
> Adrian
> __
> [1] - http://www.certgate.com/web_de/produkte/
>
> ___
> 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

Re: MokSec - The Security Framework

[Adrian-Ken Rueegsegger]

Jan de Haan wrote:
> On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen <[EMAIL PROTECTED]> wrote:
>> But there are places where
>> you can get SIM cards with built in encyption/decryption keys, and a
>> certificate (PKI).
> 
> I agree. Would you care to elaborate (link)?

There's a manufacturer of a microSD smartcard [1] in Germany, which 
looks quite promising. Such a smartcard could be used in many security 
applications.

Cheers,
Adrian
__
[1] - http://www.certgate.com/web_de/produkte/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: MokSec - The Security Framework

[Crane, Matthew]

 
There's apps that do this, like kdewallet. 
 
I was thinking of a picture pin entry.  You display a small set of
pictures with lots of detail, user must tap 1 or more points on each
pictures. 
 
Quick entry, good number of bits of encryption, easy to remeber.
 
Plus, when the phone comes up with a picture, to anybody else it just
looks like it's stuck booting or broken.




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of thomasg
Sent: Monday, July 14, 2008 12:19 PM
To: List for Openmoko community discussion
Subject: Re: MokSec - The Security Framework


On Mon, Jul 14, 2008 at 6:13 PM, Kalle Happonen <[EMAIL PROTECTED]>
wrote:



I had some thoughts about that, too.
Would be cool if it wasn't necessary to have a PIN at all - you
enter the PIN in the "first-run-wizard", that will store it.
After that you only have one password (of your choise) that does
all - the security daemon would lookup in a key/password-database and
use your password for all things, like decrypting the other containers
(phonebook, messages, e.g.), authing you on the network with the stored
pin, unlocking the phone screen, .


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Tilman Baumann]

Kalle Happonen wrote:
>> Well, off topic... Congrats Finland. ;)
>>
>>   
> Well it looks cool, but in practice... there's maybe 1 service that 
> accepts these.. maybe. And the operators are clueless about it. I agree, 
> it's great to have this infrastructure, but without services, it's just 
> a virtual finnish penis

Well, then congrats for the largest virtual penis.
Who needs real success in times of the internet where fame is 
everything. *g*
-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Kalle Happonen]

thomasg wrote:
> On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen <[EMAIL PROTECTED] 
> > wrote:
>  
>
> What an insult! *slap* :P. No I'm not a windows user. and I can
> set the
> root password on my device, but defaults matter. And they matter a lot
> if openmoko will become more mass-market. A firewall migth be a bit
> heavy, I agree, every watt and cycle should try to be saved, but
> making
> dropbear just listen to the usb interface would be a pretty good
> compromise, if that is possible.
>
>  
> Ok, sorry, that was a too mean joke :P
I forgive you :)
> The situation with no root password set is of course not bearable, but 
> I'm pretty sure that this issue will be solved in a consumer-ready 
> release.
> What I'd imagine would be a kind of "first-run-guide", that "forces" 
> (or allows, however you want :) ) the user to do all the important 
> settings at the first run of the phone (could be used for backup 
> purposes, too, e.g. load an xml-file with the settings).
> Would make the life way easier for newbies.
>
That would make sense yes. And since it's a pretty complex device, a 
first-run setup is almost needed anyway.
>
> However, later on an easily configurable firewall would be almost
> essential imho. Connecting to the phone (any port) over the wifi
> should
> (almost?)never be allowed as default. Even if the point with the phone
> is that users can do what they want, it doesn't mean that the apps
> they
> install shouldn't be protected. And a firewall is almost the only
> viable
> way. There's no easy way of making all the apps listen to just one
> interface, and while host.allow/deny is more lightweight than a
> firewall, those don't allow distinguishing of interface.
>
>  
> A firewall is always a more or less big piece of software, always not 
> the best for performance, and always a security risk (if it's not 
> dedicated). It also is not possible to do a easy and _good_ 
> configuration, so however it's done, it's always suboptimal.
> There are not too much services running, and all of them are open 
> source software, so that is imho not that a big deal.
>
iptables fits into a small kernel, that's not big software :). It might 
have some performance hits, but with these traffic amounts it shouldn't 
matter. The big but is of course the frontend to it. And open source 
software isn't immune to vulnerabilities :). Security patches help, but 
if possible, I'd still go for a firewall.
>
>
> >
> > 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

Re: MokSec - The Security Framework

[thomasg]

On Mon, Jul 14, 2008 at 6:13 PM, Kalle Happonen <[EMAIL PROTECTED]>
wrote:

> thomasg wrote:
> > On Mon, Jul 14, 2008 at 5:22 PM, arne anka <[EMAIL PROTECTED]
> > > wrote:
> >
> > > Of course you can create another user, as you are used to on any
> > unix
> > > system.
> > > It just doesn't ship with one because the distro comes in
> > ready-to-deploy
> > > images, not with a installer like the binary-distro-people are
> > used to.
> >
> > sure? i think it possible that some things won't work when
> > non-root ...
> >
> >
> > Of course some things won't work - if they would, there would be no
> > need for a special root account.
> > Basically all the tools someone would use without a terminal should
> > work (dialer, contacs, ...) no matter what stack is used.
> > The daemons that need root access run in background and can be
> > controlled by userspace-programs without root-access.
> >
> > If of course would take a loginmanager or similar to use a user with
> > password at startup, because currently the user root is automatically
> > logged in. Should be easy to "fix".
> Even running only critical things as root, and most stuff on a
> no-password unprivileged account would be better. But an user account
> with a password a would of course be better. The I'd say that the PIN
> could almost be saved somewhere, to avoid the need for a double log-in.


I had some thoughts about that, too.
Would be cool if it wasn't necessary to have a PIN at all - you enter the
PIN in the "first-run-wizard", that will store it.
After that you only have one password (of your choise) that does all - the
security daemon would lookup in a key/password-database and use your
password for all things, like decrypting the other containers (phonebook,
messages, e.g.), authing you on the network with the stored pin, unlocking
the phone screen, .
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Jay Vaughan]

> I've only had my freerunner for a week or so, so I'm not too into the
> security aspects yet. One thing I did notice was of course  
> passwordless
> root login. Now over usb this can be acceptable, but if this is  
> possible
> over wifi (I haven't actually tested), it needs the firewall / make it
> listen only to the usb.
>

Set your own root password.  Fixed.


;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Kalle Happonen]

thomasg wrote:
> On Mon, Jul 14, 2008 at 5:22 PM, arne anka <[EMAIL PROTECTED] 
> > wrote:
>
> > Of course you can create another user, as you are used to on any
> unix
> > system.
> > It just doesn't ship with one because the distro comes in
> ready-to-deploy
> > images, not with a installer like the binary-distro-people are
> used to.
>
> sure? i think it possible that some things won't work when
> non-root ...
>
>
> Of course some things won't work - if they would, there would be no 
> need for a special root account.
> Basically all the tools someone would use without a terminal should 
> work (dialer, contacs, ...) no matter what stack is used.
> The daemons that need root access run in background and can be 
> controlled by userspace-programs without root-access.
>
> If of course would take a loginmanager or similar to use a user with 
> password at startup, because currently the user root is automatically 
> logged in. Should be easy to "fix".
Even running only critical things as root, and most stuff on a 
no-password unprivileged account would be better. But an user account 
with a password a would of course be better. The I'd say that the PIN 
could almost be saved somewhere, to avoid the need for a double log-in.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Kalle Happonen]

Tilman Baumann wrote:
> Kalle Happonen wrote:
>   
>> Jan de Haan wrote:
>> 
>>> On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen <[EMAIL PROTECTED]> wrote:
>>>   
>>>   
 But there are places where
 you can get SIM cards with built in encyption/decryption keys, and a
 certificate (PKI).
 
 
>>> I agree. Would you care to elaborate (link)?
>>>
>>> Sincerely,
>>>
>>>   
>>>   
>> Sure, the only one I know about directly is this, it's coordinated by 
>> the Finninsh government, and naturally only available in finland.
>> http://www.vrk.fi/vrk/home.nsf/pages/FE039B4246B8FED9C22572450036E7E6?opendocument
>> 
>
> I wish more governments would be so progressive. *g*
> We in Germany are botching around on this idea for years with apparently 
> no result. But at least our politicians have the will to implement 
> anonymous signatures, which is rather cool.
> Sometimes you just want to prove that you are real, and not who you 
> actually are.
>
> Well, off topic... Congrats Finland. ;)
>
>   
Well it looks cool, but in practice... there's maybe 1 service that 
accepts these.. maybe. And the operators are clueless about it. I agree, 
it's great to have this infrastructure, but without services, it's just 
a virtual finnish penis




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Steven Kurylo]

On Mon, Jul 14, 2008 at 7:02 AM, Kalle Happonen <[EMAIL PROTECTED]> wrote:
> arne anka wrote:
>>> wouldn't think it's too much. How often do you reboot the phone?
>>>
>>
>> with a battery uptime of about 8h -- at least once a day, because the fr
>> usually silently shuts down.
>> on weekends more frequently because i play around and something crashes or
>> so.
>>
> Well, this wasn't available now, was it? :). Since these are only plans,
> and afaik the powersave functionality will be vastly improved, that
> argument is hopefully invalid when the encryption is available.

And if you're not willing to have the inconvenience of a long password
on boot up, use an easier one.  You're slightly less secure, but still
more secure than having no encryption.

-- 
Steven Kurylo

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Tilman Baumann]

Kalle Happonen wrote:
> Jan de Haan wrote:
>> On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen <[EMAIL PROTECTED]> wrote:
>>   
>>> But there are places where
>>> you can get SIM cards with built in encyption/decryption keys, and a
>>> certificate (PKI).
>>> 
>> I agree. Would you care to elaborate (link)?
>>
>> Sincerely,
>>
>>   
> Sure, the only one I know about directly is this, it's coordinated by 
> the Finninsh government, and naturally only available in finland.
> http://www.vrk.fi/vrk/home.nsf/pages/FE039B4246B8FED9C22572450036E7E6?opendocument

I wish more governments would be so progressive. *g*
We in Germany are botching around on this idea for years with apparently 
no result. But at least our politicians have the will to implement 
anonymous signatures, which is rather cool.
Sometimes you just want to prove that you are real, and not who you 
actually are.

Well, off topic... Congrats Finland. ;)


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[thomasg]

On Mon, Jul 14, 2008 at 5:22 PM, arne anka <[EMAIL PROTECTED]> wrote:

> > Of course you can create another user, as you are used to on any unix
> > system.
> > It just doesn't ship with one because the distro comes in ready-to-deploy
> > images, not with a installer like the binary-distro-people are used to.
>
> sure? i think it possible that some things won't work when non-root ...


Of course some things won't work - if they would, there would be no need for
a special root account.
Basically all the tools someone would use without a terminal should work
(dialer, contacs, ...) no matter what stack is used.
The daemons that need root access run in background and can be controlled by
userspace-programs without root-access.

If of course would take a loginmanager or similar to use a user with
password at startup, because currently the user root is automatically logged
in. Should be easy to "fix".
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[arne anka]

> Of course you can create another user, as you are used to on any unix
> system.
> It just doesn't ship with one because the distro comes in ready-to-deploy
> images, not with a installer like the binary-distro-people are used to.

sure? i think it possible that some things won't work when non-root ...


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Kalle Happonen]

Jan de Haan wrote:
> On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen <[EMAIL PROTECTED]> wrote:
>   
>> But there are places where
>> you can get SIM cards with built in encyption/decryption keys, and a
>> certificate (PKI).
>> 
>
> I agree. Would you care to elaborate (link)?
>
> Sincerely,
>
>   
Sure, the only one I know about directly is this, it's coordinated by 
the Finninsh government, and naturally only available in finland.
http://www.vrk.fi/vrk/home.nsf/pages/FE039B4246B8FED9C22572450036E7E6?opendocument


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[thomasg]

On Mon, Jul 14, 2008 at 5:08 PM, arne anka <[EMAIL PROTECTED]> wrote:

> > And to give my 2 Eurocents to the everything as root discusion.
> > Running user apps as root must end, better soon.
>
> what exactly speaks against creating a regular user? did anyone try it
> already?
> and where exactly is "root" as default user stored?


In /etc/passwd :)
Of course you can create another user, as you are used to on any unix
system.
It just doesn't ship with one because the distro comes in ready-to-deploy
images, not with a installer like the binary-distro-people are used to.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[thomasg]

On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen <[EMAIL PROTECTED]>
wrote:


> What an insult! *slap* :P. No I'm not a windows user. and I can set the
> root password on my device, but defaults matter. And they matter a lot
> if openmoko will become more mass-market. A firewall migth be a bit
> heavy, I agree, every watt and cycle should try to be saved, but making
> dropbear just listen to the usb interface would be a pretty good
> compromise, if that is possible.
>

Ok, sorry, that was a too mean joke :P
The situation with no root password set is of course not bearable, but I'm
pretty sure that this issue will be solved in a consumer-ready release.
What I'd imagine would be a kind of "first-run-guide", that "forces" (or
allows, however you want :) ) the user to do all the important settings at
the first run of the phone (could be used for backup purposes, too, e.g.
load an xml-file with the settings).
Would make the life way easier for newbies.

However, later on an easily configurable firewall would be almost
> essential imho. Connecting to the phone (any port) over the wifi should
> (almost?)never be allowed as default. Even if the point with the phone
> is that users can do what they want, it doesn't mean that the apps they
> install shouldn't be protected. And a firewall is almost the only viable
> way. There's no easy way of making all the apps listen to just one
> interface, and while host.allow/deny is more lightweight than a
> firewall, those don't allow distinguishing of interface.


A firewall is always a more or less big piece of software, always not the
best for performance, and always a security risk (if it's not dedicated). It
also is not possible to do a easy and _good_ configuration, so however it's
done, it's always suboptimal.
There are not too much services running, and all of them are open source
software, so that is imho not that a big deal.


> >
> > 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).
> >
> 

Re: MokSec - The Security Framework

[Jan de Haan]

On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen <[EMAIL PROTECTED]> wrote:
> But there are places where
> you can get SIM cards with built in encyption/decryption keys, and a
> certificate (PKI).

I agree. Would you care to elaborate (link)?

Sincerely,

Jan.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[arne anka]

> And to give my 2 Eurocents to the everything as root discusion.
> Running user apps as root must end, better soon.

what exactly speaks against creating a regular user? did anyone try it  
already?
and where exactly is "root" as default user stored?


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: MokSec - The Security Framework

[Crane, Matthew]

I would think on a phone the primary concern is protecting the user
data.  

E.g. sms, contacts, history. 

If somebody was able to malicously install software on the phone, your
pretty much already [EMAIL PROTECTED]'ed.  Not letting it call out helps, but 
it's
already defeated.  I'm assuming we're not installing a lot of new
unknowns on a secure device, and anything trying to make network
connections is evol. 

I've been picturing running an encrypted rootfs image off an SD card.
There could be multiple encrypted rootfs images, only one would be the
real one, or they all could be used for different reasons.

Once the system boots it's up to the user to unlock the keys to the
encrypted image to be used and that gets booted from the already running
kernel. 



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tilman
Baumann
Sent: Monday, July 14, 2008 10:38 AM
To: List for Openmoko community discussion
Subject: Re: MokSec - The Security Framework


Kalle Happonen wrote:

> However, later on an easily configurable firewall would be almost 
> essential imho. Connecting to the phone (any port) over the wifi
should 
> (almost?)never be allowed as default. Even if the point with the phone

> is that users can do what they want, it doesn't mean that the apps
they 
> install shouldn't be protected. And a firewall is almost the only
viable 
> way. There's no easy way of making all the apps listen to just one 
> interface, and while host.allow/deny is more lightweight than a 
> firewall, those don't allow distinguishing of interface.

SELinux comes to mind. Or at least the capabilites framework.
This way i could choose to allow a app to open sockets. (Little bit like

java sandboxes)
As far as i know we could even have a popup asking for permission.

And to give my 2 Eurocents to the everything as root discusion.
Running user apps as root must end, better soon.
If apps need things only root can do (not much comes to my mind) we 
could use sudo wrapper or SELinux rules.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

___
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

Re: MokSec - The Security Framework

[Kalle Happonen]

Tilman Baumann wrote:
> Paul Jimenez wrote:
>   
>> Alex Oberhauser wrote:
>> 
>>> Bumbl wrote:
>>>   
>>>   
 It would be more important to not run everything as root I think
 
 
>>> This will be also a main focus. When we receive the Freerunners, we will see
>>> how fast we can change this bad state.
>>>
>>>   
>>>   
>> Personally, I'd be more interested in an encrypted filesystem so that I 
>> can worry less about snoopy people getting access to my personal data if 
>> I lose my phone or it's stolen.  How many 'main focuses' are you allowed 
>> ? :)
>> 
>
> Can we use the SIM-Card to decrypt stuff?
> It's after all a smart card. :)
>
> Would be cool if we could store a crypto key on the SIM, which it will 
> only release if you provide the right SIM.
>   
I don't think that's doable with normal SIMs. But there are places where 
you can get SIM cards with built in encyption/decryption keys, and a 
certificate (PKI). This is possible at least in Finland, but not widely 
used.  If you had the PKI enabled SIM, I'd say it wouldn't only be cool, 
it would be THE way to go, as far as security and ease of use goes. :)


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Tilman Baumann]

Kalle Happonen wrote:

> However, later on an easily configurable firewall would be almost 
> essential imho. Connecting to the phone (any port) over the wifi should 
> (almost?)never be allowed as default. Even if the point with the phone 
> is that users can do what they want, it doesn't mean that the apps they 
> install shouldn't be protected. And a firewall is almost the only viable 
> way. There's no easy way of making all the apps listen to just one 
> interface, and while host.allow/deny is more lightweight than a 
> firewall, those don't allow distinguishing of interface.

SELinux comes to mind. Or at least the capabilites framework.
This way i could choose to allow a app to open sockets. (Little bit like 
java sandboxes)
As far as i know we could even have a popup asking for permission.

And to give my 2 Eurocents to the everything as root discusion.
Running user apps as root must end, better soon.
If apps need things only root can do (not much comes to my mind) we 
could use sudo wrapper or SELinux rules.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Tilman Baumann]

Paul Jimenez wrote:
> Alex Oberhauser wrote:
>> Bumbl wrote:
>>   
>>> It would be more important to not run everything as root I think
>>> 
>> This will be also a main focus. When we receive the Freerunners, we will see
>> how fast we can change this bad state.
>>
>>   
> 
> Personally, I'd be more interested in an encrypted filesystem so that I 
> can worry less about snoopy people getting access to my personal data if 
> I lose my phone or it's stolen.  How many 'main focuses' are you allowed 
> ? :)

Can we use the SIM-Card to decrypt stuff?
It's after all a smart card. :)

Would be cool if we could store a crypto key on the SIM, which it will 
only release if you provide the right SIM.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Kalle Happonen]

arne anka wrote:
>> wouldn't think it's too much. How often do you reboot the phone?
>> 
>
> with a battery uptime of about 8h -- at least once a day, because the fr  
> usually silently shuts down.
> on weekends more frequently because i play around and something crashes or  
> so.
>   
Well, this wasn't available now, was it? :). Since these are only plans, 
and afaik the powersave functionality will be vastly improved, that 
argument is hopefully invalid when the encryption is available.

Kalle

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: MokSec - The Security Framework

[Crane, Matthew]

Once the device is powered, and the correct key entered, I would expect
it would remain in memory until the phone is powered off.  Parnoid types
would of course disable network access.  

Nearly all phones have a secured access mode, where you enter a pin
every time you access the phone.  That's a must for some.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of arne anka
Sent: Monday, July 14, 2008 9:26 AM
To: List for Openmoko community discussion
Subject: Re: MokSec - The Security Framework


> How would being root help somebody decrypt a filesystem?  Accessing an
> encrypted filesystem should depend only on having the correct key.

well, to be really usefull the fs should be mounted transparently
(hacking  
in the passphrase on every access seems utterly tedious with that tiny  
keyboard -- and would probably add to the exposure risk).
or you need to store the passphrase somewhere on the fr and access it by

some automatic.
in both cases somebody finding or stealing your fr would be able to read

your encrypted data.

please, correct me, if i am wrong.

___
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

Re: MokSec - The Security Framework

[arne anka]

> wouldn't think it's too much. How often do you reboot the phone?

with a battery uptime of about 8h -- at least once a day, because the fr  
usually silently shuts down.
on weekends more frequently because i play around and something crashes or  
so.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Kalle Happonen]

arne anka wrote:
>> How would being root help somebody decrypt a filesystem?  Accessing an
>> encrypted filesystem should depend only on having the correct key.
>> 
>
> well, to be really usefull the fs should be mounted transparently (hacking  
> in the passphrase on every access seems utterly tedious with that tiny  
> keyboard -- and would probably add to the exposure risk).
depends on what you mean "on every access". If it's once per startup, I 
wouldn't think it's too much. How often do you reboot the phone?


Cheers,
Kalle

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Kalle Happonen]

thomasg wrote:
> On 7/14/08, *Kalle Happonen* <[EMAIL PROTECTED] 
> > wrote:
>
> Hello,
> I've only had my freerunner for a week or so, so I'm not too into the
> security aspects yet. One thing I did notice was of course
> passwordless
> root login. Now over usb this can be acceptable, but if this is
> possible
> over wifi (I haven't actually tested), it needs the firewall / make it
> listen only to the usb.
>
>  
> There's no need for a firewall at all (in fact it's probably the worst 
> idea).
> Just set a root password (you're probably a win user, the command is 
> simply "passwd") and it'll be fine.
>  
What an insult! *slap* :P. No I'm not a windows user. and I can set the 
root password on my device, but defaults matter. And they matter a lot 
if openmoko will become more mass-market. A firewall migth be a bit 
heavy, I agree, every watt and cycle should try to be saved, but making 
dropbear just listen to the usb interface would be a pretty good 
compromise, if that is possible.

However, later on an easily configurable firewall would be almost 
essential imho. Connecting to the phone (any port) over the wifi should 
(almost?)never be allowed as default. Even if the point with the phone 
is that users can do what they want, it doesn't mean that the apps they 
install shouldn't be protected. And a firewall is almost the only viable 
way. There's no easy way of making all the apps listen to just one 
interface, and while host.allow/deny is more lightweight than a 
firewall, those don't allow distinguishing of interface.

>
> 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 automat

Re: MokSec - The Security Framework

[arne anka]

> How would being root help somebody decrypt a filesystem?  Accessing an
> encrypted filesystem should depend only on having the correct key.

well, to be really usefull the fs should be mounted transparently (hacking  
in the passphrase on every access seems utterly tedious with that tiny  
keyboard -- and would probably add to the exposure risk).
or you need to store the passphrase somewhere on the fr and access it by  
some automatic.
in both cases somebody finding or stealing your fr would be able to read  
your encrypted data.

please, correct me, if i am wrong.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: MokSec - The Security Framework

[Crane, Matthew]

How would being root help somebody decrypt a filesystem?  Accessing an
encrypted filesystem should depend only on having the correct key.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of arne anka
Sent: Monday, July 14, 2008 4:58 AM
To: List for Openmoko community discussion
Subject: Re: MokSec - The Security Framework


> Personally, I'd be more interested in an encrypted filesystem so that
I

what use is encryption if the user always is root and no password is  
required?

___
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

Re: MokSec - The Security Framework

[arne anka]

> Personally, I'd be more interested in an encrypted filesystem so that I

what use is encryption if the user always is root and no password is  
required?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[thomasg]

On 7/14/08, Kalle Happonen <[EMAIL PROTECTED]> wrote:
>
> Hello,
> I've only had my freerunner for a week or so, so I'm not too into the
> security aspects yet. One thing I did notice was of course passwordless
> root login. Now over usb this can be acceptable, but if this is possible
> over wifi (I haven't actually tested), it needs the firewall / make it
> listen only to the usb.


There's no need for a firewall at all (in fact it's probably the worst
idea).
Just set a root password (you're probably a win user, the command is simply
"passwd") and it'll be fine.


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 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).
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.
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).

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

Re: MokSec - The Security Framework

[Kalle Happonen]

Hello,
I've only had my freerunner for a week or so, so I'm not too into the 
security aspects yet. One thing I did notice was of course passwordless 
root login. Now over usb this can be acceptable, but if this is possible 
over wifi (I haven't actually tested), it needs the firewall / make it 
listen only to the usb.

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?

In addition to that, I'd say all linux security administration best 
practices should be at least considered, including automatic security 
updates.

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! :)

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

Re: MokSec - The Security Framework

[Paul Jimenez]

Alex Oberhauser wrote:
> Bumbl wrote:
>   
>> It would be more important to not run everything as root I think
>> 
>
> This will be also a main focus. When we receive the Freerunners, we will see
> how fast we can change this bad state.
>
>   

Personally, I'd be more interested in an encrypted filesystem so that I 
can worry less about snoopy people getting access to my personal data if 
I lose my phone or it's stolen.  How many 'main focuses' are you allowed 
? :)

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

MokSec - The Security Framework

[Alex Oberhauser]

Bumbl wrote:
> It would be more important to not run everything as root I think

This will be also a main focus. When we receive the Freerunners, we will see
how fast we can change this bad state.

Robert Schuster wrote:
> Hi,
> this is perhaps not directly in the scope of your project but perhaps it
> inspires someones else: A spam filter for SMS. :)

Why not? We can add this feature to the phone firewall. Shouldn't be a big
problem. It's also possible that you add this feature to phone-firewall or you
make a new project.

I found this a very good idea and should be part of the security framework.

Regards

Alex Oberhauser

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Robert Schuster]

Hi,
this is perhaps not directly in the scope of your project but perhaps it
inspires someones else: A spam filter for SMS. :)

Regards
Robert



signature.asc
Description: OpenPGP digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Bumbl]

It would be more important to not run everything as root I think
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

MokSec - The Security Framework

[Yorick Moko]

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