RE: MokSec - The Security Framework
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
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
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
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
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
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
thomasg wrote: On 7/14/08, *Kalle Happonen* [EMAIL PROTECTED] mailto:[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 automatically. Again, defaults matter. If you need to log in, run
Re: MokSec - The Security Framework
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
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
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 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
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 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 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
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
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
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). The fact that it has package management doesn't mean much in itself. I think current linux distributions have a
Re: MokSec - The Security Framework
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
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
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
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 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
thomasg wrote: On Mon, Jul 14, 2008 at 5:22 PM, arne anka [EMAIL PROTECTED] mailto:[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
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
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] mailto:[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
thomasg wrote: On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen [EMAIL PROTECTED] mailto:[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 encrypted, that's just waste. But having a personal area decrypted at startup means that only you can access it at
Re: MokSec - The Security Framework
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
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
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
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
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
Re: MokSec - The Security Framework
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
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
