Re: Proposal: Personal Data Encryption (maybe SoC?)
On Thursday 22 March 2007 20:48:44 Joe Pfeiffer wrote: It's not necessary (which was one of my goals) -- if the pefs is mounted, any time the application reads or writes an encrypted file the Right Thing Happens. An encryption-aware application can request its databases be saved encrypted; the encryption manager would handle encrypting databases for unaware applications, after which the encryption would happen without any help from the application. I'm not entirely sure why one would need a new FUSE driver then. Can't you just use encfs (I gather you don't want LUKS because it needs setting Filesystem size in advance and I can see why one would want to avoid that [1]) and tell the apps to either use the encrypted tree or not? Then any app can be made to use the encryption features by virtue of providing it with proper paths. Things like unmounting on inactivity etc can easily be handled by a small user space daemon running besides FUSE then. And if you want to provide different levels of security, simply add more trees... [1] From a purely technicaly point of view, I much prefer LUKS to encfs though. I wonder if one could have dynamically growing LUKS volumes inside normal files? pgprpKxtPlMMM.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Gabriel Ambuehl writes: Can't you just use encfs (I gather you don't want LUKS because it needs setting Filesystem size in advance and I can see why one would want to avoid that [1]) and tell the apps to either use the encrypted tree or not? Then any app can be made to use the encryption features by virtue of providing it with proper paths. Yes, but I want to be able to have both an encrypted /home/pfeiffer/file1.txt and an unencrypted /home/pfeiffer/file2.txt ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Friday 23 March 2007 17:17:50 Joe Pfeiffer wrote: avoid that [1]) and tell the apps to either use the encrypted tree or not? Then any app can be made to use the encryption features by virtue of providing it with proper paths. Yes, but I want to be able to have both an encrypted /home/pfeiffer/file1.txt and an unencrypted /home/pfeiffer/file2.txt ~/file1 and ~/encrypted/file2 seems a lot easier to implement AND use to me... pgpHoxbJtnUi0.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Gabriel Ambuehl writes: On Friday 23 March 2007 17:17:50 Joe Pfeiffer wrote: avoid that [1]) and tell the apps to either use the encrypted tree or not? Then any app can be made to use the encryption features by virtue of providing it with proper paths. Yes, but I want to be able to have both an encrypted /home/pfeiffer/file1.txt and an unencrypted /home/pfeiffer/file2.txt ~/file1 and ~/encrypted/file2 seems a lot easier to implement AND use to me... Implement, yes (since it's already been done). Use? I don't think so. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Friday 23 March 2007 18:01:09 Joe Pfeiffer wrote: ~/file1 and ~/encrypted/file2 seems a lot easier to implement AND use to me... Implement, yes (since it's already been done). Use? I don't think so. You can actually use it right now, with almost every app (except for those broken enough to use hardcoded filenames), without any hacking. Most of the neat features mentioned above are app level anyhow which is very well possible... Now, for a (IMHO) truly useful extension: find a way to cache writes and encrypt them with a public key so that creating new files (for example because you just received a SMS) can work while the phone is locked. Once the phone is unlocked, decrypt the data and store it in the encrypted FS. Maybe it's just me, but pefs seems vastly over engineered. Which is generally a bad thing when it comes to encryption... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Gabriel Ambuehl writes: On Friday 23 March 2007 18:01:09 Joe Pfeiffer wrote: ~/file1 and ~/encrypted/file2 seems a lot easier to implement AND use to me... Implement, yes (since it's already been done). Use? I don't think so. You can actually use it right now, with almost every app (except for those broken enough to use hardcoded filenames), without any hacking. Most of the neat features mentioned above are app level anyhow which is very well possible... Now, for a (IMHO) truly useful extension: find a way to cache writes and encrypt them with a public key so that creating new files (for example because you just received a SMS) can work while the phone is locked. Once the phone is unlocked, decrypt the data and store it in the encrypted FS. I'll need a phone to explore that... Maybe it's just me, but pefs seems vastly over engineered. Which is generally a bad thing when it comes to encryption... Hmmm... I don't see a lot of over-engineering there; just what's needed to support the use case that best matches my intuition of what a user will find most straightforward (well, OK, allowing keys other than a single password, maybe). But then, as the guy who wrote the description, I wouldn't be likely to. Beyond that, I think we're at a real YMMV point; what I see as the most straightforward approach for a user is something you see as too much work to implement for not much (if any) benefit; what you see as a straightforward way to work and an easy interface for a user I see as awkward. And since we're both spouting opinions, there's no way to do a real comparison without a prototype. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Flemming Richter Mikkelsen wrote: There is many good solutions out here. From my point of view, I would like something like this: - launch apps-security - check the check boxes you like: x encrypt phonebook [...] I think this would be possible since each of these groups is stored in separate places. Usually the user should not need to encrypt more than 100MB. Oops.. 640k is enough for everyone, right? ;) With a 512MB SD card, we have enough space to make an encrypted partition (maybe inside a file) if we want but I don't know if this is a good solution or not. What I'd like to see is an easy way of storing *all* important data (phonebook, SMS, addresses, pictures, music, you name it) on the microSD card instead of the internal flash. Then I can just make one large encrypted 2GB LUKS partition on the microSD card and everything is encrypted. When the phone is rebooted or the microSD card is removed, the data is safe until the passphrase is provided. One remaining question is if the user manually wants to lock the phone during use (usually with a PIN). We can't really unmount the microSD card because then the phonebook is unavailable and incoming calls can't tell who is calling (and thus how to treat the call). So I guess it remains mounted all the time, which considerably lowers security of course. Perhaps the phone should unmount the card after you enter the wrong PIN a few times, or enter a special PANIC-PIN. -Sven ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Flemming Richter Mikkelsen wrote: There is many good solutions out here. From my point of view, I would like something like this: - launch apps-security - check the check boxes you like: x encrypt phonebook [...] I think this would be possible since each of these groups is stored in separate places. Usually the user should not need to encrypt more than 100MB. 640k are enough for everyone, right? ;) With a 512MB SD card, we have enough space to make an encrypted partition (maybe inside a file) if we want but I don't know if this is a good solution or not. What I'd like to see is an easy way of storing *all* important data (phonebook, SMS, addresses, pictures, music, you name it) on the microSD card instead of the internal flash. Then I can just make one large encrypted 2GB LUKS partition on the microSD card and everything is encrypted. When the phone is rebooted or the microSD card is removed, the data is safe until the passphrase is provided. One remaining question is if the user manually wants to lock the phone during use (usually with a PIN). We can't really unmount the microSD card because then the phonebook is unavailable and incoming calls can't tell who is calling (and how to treat the call). So I guess it remains mounted all the time. -Sven ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On to, 2007-03-22 at 11:31 +0100, Sven Neuhaus wrote: One remaining question is if the user manually wants to lock the phone during use (usually with a PIN). We can't really unmount the microSD card because then the phonebook is unavailable and incoming calls can't tell who is calling (and thus how to treat the call). So I guess it remains mounted all the time, which considerably lowers security of course. Well, I wouldn't say considerably, if you lock it down so that it'll only be able to receive calls without the PIN (and a few false PINs will unmount the encrypted microSD, as you say; perhaps even just turn the phone off, accomplishing the same). You still leak a bit of information from incoming calls (caller ID, caller ringtone, etc), but I wouldn't call that considerable. Of course, a severe security bug in the lockdown program would in this case compromise the whole encrypted microSD; the code where such a thing can happen should be isolated and under extra scrutiny. Perhaps the phone should unmount the card after you enter the wrong PIN a few times, or enter a special PANIC-PIN. Yeah, a short panic code would be good too. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Thu, 22 Mar 2007 10:17, Joe Pfeiffer wrote: Thoughts? From what I remember of the discussions so far, that seems to meet the majority of requirements for encrypted file storage and also manages many of the things related to authentication that we have been discussing. Now, if we can specify the manner in which the password is entered (gesture, pin, etc.) then maybe its just this 'easy' ? Lol. Easy being relative because its already built. IMHO that would work pretty well. At least for what I am interested in. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tim Newsom writes: On Thu, 22 Mar 2007 10:17, Joe Pfeiffer wrote: Thoughts? From what I remember of the discussions so far, that seems to meet the majority of requirements for encrypted file storage and also manages many of the things related to authentication that we have been discussing. Now, if we can specify the manner in which the password is entered (gesture, pin, etc.) then maybe its just this 'easy' ? Lol. Easy being relative because its already built. IMHO that would work pretty well. At least for what I am interested in. Good to know I'm not completely out to lunch! Time to start learning fuse well enough to work with it... Thanks. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Thu, 22 Mar 2007 12:13, Tim Newsom wrote: On Thu, 22 Mar 2007 10:17, Joe Pfeiffer wrote: Thoughts? From what I remember of the discussions so far, that seems to meet the majority of requirements for encrypted file storage and also manages many of the things related to authentication that we have been discussing. In a semi related note, how would we enable this ability for things like the contacts database? Or any other application database for that matter? Any ideas? --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tim Newsom writes: On Thu, 22 Mar 2007 12:13, Tim Newsom wrote: On Thu, 22 Mar 2007 10:17, Joe Pfeiffer wrote: Thoughts? From what I remember of the discussions so far, that seems to meet the majority of requirements for encrypted file storage and also manages many of the things related to authentication that we have been discussing. In a semi related note, how would we enable this ability for things like the contacts database? Or any other application database for that matter? It's not necessary (which was one of my goals) -- if the pefs is mounted, any time the application reads or writes an encrypted file the Right Thing Happens. An encryption-aware application can request its databases be saved encrypted; the encryption manager would handle encrypting databases for unaware applications, after which the encryption would happen without any help from the application. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Hi, Am Tue, 20 Mar 2007 13:31:56 +0100 schrieb Sven Neuhaus: Tobias Gruetzmacher wrote: Partitions are a major usability nightmare IMHO. That is the reason my proposal focused on encfs/ecryptfs, which both are layered encryption file systems. This removes the requirement to set a fixed size for the encrypted space and makes it easy to use standard tools to backup the encrypted data. It doesn't have to be complicated, check out this screencast http://people.freedesktop.org/~david/crypto/ showing LUKS integration into Gnome. I know of this integration. I have setup many devices with LUKS encryption. But I really don't want to ask the user How big should your encrypted space be? on a mobile device. It should just work when the user selects the Please encrypt my personal data checkbox... When repartitioning, one has to do ugly stuff to preserve the existing data. ecryptfs/encfs is just as easy as mounting into an empty directory and moving the data there. No low-level fiddling with the partitions to do at all. Greetings, Tobi -- GPG-Key 0xE2BEA341 - signed/encrypted mail preferred My, oh so small, homepage: http://portfolio16.de/ http://www.fli4l.de/ - ISDN- DSL-Router on one disk! Registered FLI4L-User #0003 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tobias Gruetzmacher writes: It doesn't have to be complicated, check out this screencast http://people.freedesktop.org/~david/crypto/ showing LUKS integration into Gnome. I know of this integration. I have setup many devices with LUKS encryption. But I really don't want to ask the user How big should your encrypted space be? on a mobile device. It should just work when the user selects the Please encrypt my personal data checkbox... When repartitioning, one has to do ugly stuff to preserve the existing data. ecryptfs/encfs is just as easy as mounting into an empty directory and moving the data there. No low-level fiddling with the partitions to do at all. Right -- these look like good approaches, but to a different problem. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Wed, 21 Mar 2007 9:34, Joe Pfeiffer wrote: Tobias Gruetzmacher writes: Right -- these look like good approaches, but to a different problem. /please excuse my direct manner.. Its just how I write (smile) What do you mean by different problem? Maybe I don't fully understand. The way I see it you have a few interoperating components... Dbus can be the primary transport mechanism, some reader plugin which abstracts the actual source of the data.. Be it the filesystem or a file which sits on the filesystem that has its own filesystem.. Or a dbfile system (I have not heard much about that recently)... A writer plugin which does pretty much the same thing, but for writing and not reading.. Maybe they are even the same plugin.. /shrug Then you have some authenticating system which allows various methods of authenticating a user.. Be it fingerprint reader or pincode or whatever based on the currently selected provider/plugin... And you have the application. At the lowest level is the encryption/decryption system.. Right above the filesystem somewhere. Now, when the phone is idle long enough or locked and a user tries to do something, the currently configured login / unlock / whatever you want to call it authentication plugin is activated and asks for the required information / gesture / whatever. Once obtained the user is granted whatever rights they configured for that action.. By default it can be nothing or a pincode and the default level can also be set to wide open, no encryption and full access. That's the state of almost every phone on the market right? Ok.. So an advanced users phone may have 3 or 4 levels of authentication and access / encryption.. Maybe even different algorithms are used. Who knows? When they log in they probably set it to the lowest level of access.. The notes application can read plain text with no problems and any unsecured data is visible.. Including contacts, notes, pictures, music, whatever. Now suppose this individual decides to read an encrypted file or runs an application configured to access an encrypted file or file system.. The authentication system would then ask for additional authentication and once granted handle the key pass to the decryption system / whatever to read the file. Now I don't have any experience with truecrypt or LUKS yet.. But they were mentioned along with encryptfs etc as a means of handling the encryption part. Maybe you can help me with where I missed out on the problem so that I can get my head around it? (Grin) I would love to make sure I fully understand what you are saying. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tim Newsom writes: On Wed, 21 Mar 2007 9:34, Joe Pfeiffer wrote: Tobias Gruetzmacher writes: Right -- these look like good approaches, but to a different problem. /please excuse my direct manner.. Its just how I write (smile) Likewise -- it's hard to see somebody smile by email, and I never intend to offend. What do you mean by different problem? Maybe I don't fully understand. Near as I can tell, these approaches require you to partition up your maching into an unencrypted area and an encrypted jail -- maybe through a physically separate device, maybe through a separate partition, maybe through a file that's mounted as a filesystem. I don't want that -- I want to be able to specify encryption on a file-by-file basis, in a manner that comes as close as possible to being generic across all applications without code changes to those applications. At the moment, I'm wandering around the source code for __libc_read() and __libc_write() to see if there's a good way to hijack a program's read() and write() calls, so if they are to a file that's marked as encrypted the data can go through encrypt() on the way The way I see it you have a few interoperating components... Dbus can be the primary transport mechanism, some reader plugin which abstracts the actual source of the data.. Be it the filesystem or a file which sits on the filesystem that has its own filesystem.. Or a dbfile system (I have not heard much about that recently)... A writer plugin which does pretty much the same thing, but for writing and not reading.. Maybe they are even the same plugin.. /shrug Then you have some authenticating system which allows various methods of authenticating a user.. Be it fingerprint reader or pincode or whatever based on the currently selected provider/plugin... And you have the application. At the lowest level is the encryption/decryption system.. Right above the filesystem somewhere. I think we agree here; I'm just trying to avoid having it filesystem-wide. Now, when the phone is idle long enough or locked and a user tries to do something, the currently configured login / unlock / whatever you want to call it authentication plugin is activated and asks for the required information / gesture / whatever. Agree completely. Once obtained the user is granted whatever rights they configured for that action.. By default it can be nothing or a pincode and the default level can also be set to wide open, no encryption and full access. That's the state of almost every phone on the market right? As far as I know... Ok.. So an advanced users phone may have 3 or 4 levels of authentication and access / encryption.. Maybe even different algorithms are used. Who knows? When they log in they probably set it to the lowest level of access.. The notes application can read plain text with no problems and any unsecured data is visible.. Including contacts, notes, pictures, music, whatever. Now suppose this individual decides to read an encrypted file or runs an application configured to access an encrypted file or file system.. The authentication system would then ask for additional authentication and once granted handle the key pass to the decryption system / whatever to read the file. Now I don't have any experience with truecrypt or LUKS yet.. But they were mentioned along with encryptfs etc as a means of handling the encryption part. Maybe you can help me with where I missed out on the problem so that I can get my head around it? (Grin) I would love to make sure I fully understand what you are saying. Hope my notes above are helpful... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Wed, 21 Mar 2007 13:03, Joe Pfeiffer wrote: Hope my notes above are helpful... Hehe that's great. At least I am certain that you and I are on the same page now. I thought from my very quick glance at truecrypt that it could encrypt individual files also but I have not had a hard look and so no definite answer there from me. I know there are many many solutions to encryption and it would be nice to have a mechanism to install and use whatever the user wanted to setup and configure. Say gpg provider where you specify your keyring.. Or Encryptfs, truecrypt, LUKS, name your encryption method, whatever and handle the technical issues only once at install/config time maybe with recommended parameters based on the device and expected use or something. /shrug. Your ahead of me on looking at the code. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tim Newsom writes: I know there are many many solutions to encryption and it would be nice to have a mechanism to install and use whatever the user wanted to setup and configure. That would be ideal! Right now I'm thinking about how to get it to match what *I* want to do. Other users can wait :) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Andreas Kostyrka writes: At the moment, I'm wandering around the source code for __libc_read() and __libc_write() to see if there's a good way to hijack a program's read() and write() calls, so if they are to a file that's marked as encrypted the data can go through encrypt() on the way Yes, you can in theory do that. E.g. use a LD_PRELOAD library. BUT, here come the pitfalls: a) you need to keep extreme exact file positions. Or use lseek on every read/write to get your place in the file. Worse, you get a (blocksize) granularity on file position, where (blocksize) is the block size of the encryption algorithm (and this assumes a block cipher with the blocks handled independently). b) mmap. I haven't come across many applications that use mmap for file i/o (now I'll bet you'll give some critical examples!) c) from my experience, stdio.h, C++ streams and unistd.h read/write reach a different site for the kernel syscall. That might have changed or have been an artifact of LD_PRELOADing into the app. This doesn't strike me as a biggy... So encryptfs sounds way more useful for that usage. But it has the encryption jail drawback. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Wed, 21 Mar 2007 14:35, Joe Pfeiffer wrote: But it has the encryption jail drawback. So maybe one way to deal with these issues is to build out the framework by constructing a new api for reading and writing data based on this provider concept.. Including the authentication. Then deal with and flesh out the issues we encounter along the way. At the same time or sometime later, another task can be started to hook into the os level read/write calls and make it work for every application the same. Maybe as some kind of layered filesystem driver or something, I don't know. Anyway, the point is that there are many many tasks to deal with related to the entire framework for this to work at all, right? And in the short run, all OM applications have a specific api anyway to make them work with the gui etc. The risk to security of doing it this way is minimal as using a program without the encryption hook just means that the program sees an encrypted file. Sure, it could damage the file if it wanted but for the most part the information will remain secure once encrypted with whatever mechanism. Later once the framework is up and some demo plugins are in place to show encryption providers and authentication providers and data readers/writers for various filesystem/database flavors, maybe we can deal with the issues related to 'all other applications'. That is, unless someone just happens to know off the top of their heads that its about x lines of code to do this by hooking into the os read/write routines with x being some number less than infinity?( ok, that was meant as a little joke) --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Hadn't seen unionfs -- that really warrants a further look. Thanks. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Wed, 21 Mar 2007 14:59, Henryk Plötz wrote: Moin, Plus: If you really want per-file encryption that would only need some minimal modifications to the existing solutions. Or use unionfs. That's very interesting and opens up lots of potential. Your right, key management along with many other topics have not been discussed in any detail. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tim Newsom wrote: The best part is that if you don't want it, you don't use it. And those that do want it, can use it and its all completley transparent to the applications. But not at all transparent to the end user. Again assuming that there is some sort of key caching going on, what is the real consumer benefit to having multiple ways of categorising data to different levels of security versus having a simple protect my data against unauthorised access checkbox somewhere that blanket-enables encryption? (Alternatively there could be some way in which these configuration settings are pluggable and people with the more complex requirements could download the advanced settings plugin and leave normal users with a simple yes/no choice.) --Tim Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tobias Gruetzmacher wrote: Am Mon, 19 Mar 2007 12:28:28 +0100 schrieb Sven Neuhaus: With regards to encryption - it'd be great if microSD cards can contain dm-crypt'ed partitions. It's probably rather trivial to add this. Partitions are a major usability nightmare IMHO. That is the reason my proposal focused on encfs/ecryptfs, which both are layered encryption file systems. This removes the requirement to set a fixed size for the encrypted space and makes it easy to use standard tools to backup the encrypted data. It doesn't have to be complicated, check out this screencast http://people.freedesktop.org/~david/crypto/ showing LUKS integration into Gnome. -Sven ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Tue, 20 Mar 2007 2:08, Jim McDonald wrote: Tim Newsom wrote: The best part is that if you don't want it, you don't use it. And those that do want it, can use it and its all completley transparent to the applications. But not at all transparent to the end user. Again assuming that there is some sort of key caching going on, what is the real consumer benefit to having multiple ways of categorising data to different levels of security versus having a simple protect my data against unauthorised access checkbox somewhere that blanket-enables encryption? (Alternatively there could be some way in which these configuration settings are pluggable and people with the more complex requirements could download the advanced settings plugin and leave normal users with a simple yes/no choice.) --Tim Cheers, Jim. I don't think you want security which is transparent to the user.. If the user does not know it exists then they won't know they are using it.. And then they might do something which causes problems later on. The user should have full knowledge of what they are doing. That doesn't mean it has to be difficult or have 200 commands at the prompt to set up. It can be easy and guided.. And possibly just an advanced menu somewhere which contains the necessary jump points into the security configs. Remember, most users (the average mom and dad) will not use the security features anyway. Some because they don't know how, some because they don't think of it and some because they just can't be bothered to set it up. Now, the ones that don't know how may at some point try to learn, so it needs to be able to help them through it. More advanced configs don't have to be set up by the average person either. Its the flexibility that is desired. Maybe it ships with password / gesture providers by default and someone can 'load new security providers' where it connects to a trusted source for signed openmoko security engin plugins (providers being easier to say). Once connected they could read descriptions of available providers, install them and during the install it asks some questions about how they want it initially configured. If they have not set up any security before, maybe it asks them the 'first time questions'... It can educate them on potential dangers without spreading FUD and open their eyes to the awesome potential that is the openmoko platform. Lets also not forget that openmoko is not just for phones.. But also other devices. This scheme could be used by anything... From a laptop with someones fingerprint reader and using a fingerprint security provider or some not thought of security mechanism to the next hand held multimedia player device (though why you would want security on it is your guess... Maybe security camera videos of a sensitive nature?).. Lets think universal and try to apply what we are creating to a larger set of devices. --Tim --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tim Newsom wrote: [Encryption options] Yep I understand that there are lots of possibilities and options, I just think that if something ships by default it should provide end users with a very simple dialog that is basically an on/off switch for 'protection of personal data' (or something else that doesn't even mention encryption) and the additional levels of configuration can be made available through plugins or whatever. Perhaps I've spent too long battling with ugly interfaces, but I think that if OpenMoko is going to have a broader audience than the people on this list and their kindred-in-geekness then a large amount of the effort will be deciding how to keep the interface as simple and streamlined as possible rather than loading the default build with every option imaginable... --Tim Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Tue, 20 Mar 2007 8:12, Jim McDonald wrote: Tim Newsom wrote: [Encryption options] Yep I understand that there are lots of possibilities and options, I just think that if something ships by default it should provide end users with a very simple dialog that is basically an on/off switch for 'protection of personal data' (or something else that doesn't even mention encryption) and the additional levels of configuration can be made available through plugins or whatever. Perhaps I've spent too long battling with ugly interfaces, but I think that if OpenMoko is going to have a broader audience than the people on this list and their kindred-in-geekness then a large amount of the effort will be deciding how to keep the interface as simple and streamlined as possible rather than loading the default build with every option imaginable... --Tim Cheers, Jim. I completely agree. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Tue, Mar 20, 2007 at 03:06:18PM +, Jim McDonald wrote: Yep I understand that there are lots of possibilities and options, I just think that if something ships by default it should provide end users with a very simple dialog that is basically an on/off switch for 'protection of personal data' (or something else that doesn't even mention encryption) and the additional levels of configuration can be made available through plugins or whatever. I agree, to an extent. I've used a lot of security programs on a lot of handhelds and I would like something that's sort of a cross between the way Palm OS does security and the way GNOME does security. On PalmOS, each record has a private flag that can be set. In the OS, there is a setting for what to do with private records, either hide them, redact them (black them out in listings) or show them. If we could combine this with a system daemon that keeps the encryption key in memory for a user-selectable amount of time (1 minute, 5 minutes, until sleep, etc), then it would minimize the annoyance factor of having to type in your password all the time while still having a per-item level of security. A system encryption engine would also allow the user to select their level of security (light vs. strong) and possibly be extended to keep multiple keys/encryption schemes. For anything beyond that, it may have to be implemented through plugins or as a stand-alone encrypted message application (a.la CryptoPad on Palm or ZSafe on Zaurus). Perhaps I've spent too long battling with ugly interfaces, but I think that if OpenMoko is going to have a broader audience than the people on this list and their kindred-in-geekness then a large amount of the effort will be deciding how to keep the interface as simple and streamlined as possible rather than loading the default build with every option imaginable... A wise man once said something to the effect of: make it as simple as possible, but no simpler. Some things may need to be more than a check-box, but I doubt things will end up needlessly complex. I think to avoid ugly interfaces, we will need to make things somewhat abstracted and flexible. That way if v1 is rather ugly, then v2 could be made better without overhauling the entire thing. And the interface should be kept separate from the implementation, so one can be updated without breaking the other. Probably something that talks through DBus to a storage engine of some kind. -KW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Joel Newkirk wrote: Tobias Gruetzmacher wrote: What I'm proposing is a user-friendly encryption scheme of the data the user stores in his phone, so any illegitimate user will not be able to get personal data about the owner of the phone. I'd like a good gestural interface for authentication - a passphrase or password would be a pain with a mini virtual keyboard, a pincode would remain a pain in many situations, a personalized fingertip doodle would be great. Present a virtual keypad but allow a finger-drawn character or shape to authenticate. If an abstract module like PAM is used for this, the user can customize the authentication method she wants to use. With regards to encryption - it'd be great if microSD cards can contain dm-crypt'ed partitions. It's probably rather trivial to add this. -Sven ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Moin, Am Mon, 19 Mar 2007 01:16:30 +0100 schrieb Alexander E Genaud: Secondly, many banks and corporations require authentication with the assistance of a token. Some devices display a seemingly random number every minute or so, while others accept pin codes and challenges. It might be difficult for a third party (Openmoko) to interface with existing systems (do VeriSign, ActivCard/Identy and the like make public keys actually, uh, public?). I just stumbled on http://www.openauthentication.org which seems to provide an open interface for that sort of thing. I didn't read it any closer but it might be worth looking into. -- Henryk Plötz Grüße aus Berlin ~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Hi, Am Mon, 19 Mar 2007 12:28:28 +0100 schrieb Sven Neuhaus: With regards to encryption - it'd be great if microSD cards can contain dm-crypt'ed partitions. It's probably rather trivial to add this. Partitions are a major usability nightmare IMHO. That is the reason my proposal focused on encfs/ecryptfs, which both are layered encryption file systems. This removes the requirement to set a fixed size for the encrypted space and makes it easy to use standard tools to backup the encrypted data. Greetings, Tobi -- GPG-Key 0xE2BEA341 - signed/encrypted mail preferred My, oh so small, homepage: http://portfolio16.de/ http://www.fli4l.de/ - ISDN- DSL-Router on one disk! Registered FLI4L-User #0003 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tobias Gruetzmacher wrote: Hi, Am Mon, 19 Mar 2007 12:28:28 +0100 schrieb Sven Neuhaus: With regards to encryption - it'd be great if microSD cards can contain dm-crypt'ed partitions. It's probably rather trivial to add this. Partitions are a major usability nightmare IMHO. That is the reason my proposal focused on encfs/ecryptfs, which both are layered encryption file systems. This removes the requirement to set a fixed size for the encrypted space and makes it easy to use standard tools to backup the encrypted data. Greetings, Tobi Just wanted to throw my $.02 into the mix. I think the most important aspect of this is ease of use...KISS. Some of the ideas floating around are over the top. It might give you warm fuzzies to have some super cool encryption scheme, but it will be completely pointless if you make it so difficult to use that (normal) people don't use it. There is a big difference between what is needed for keeping nuclear launch codes and your shopping list secure. Since it is much more likely that you will be storing your shopping list rather than top-secret documents, lets focus on encryption schemes that are more target for that use. Also, *most* times that a phone is lost/stolen people are just going to want to wipe it then sell on eBay, not hook up a debug board and do a memory dump. Seriously, where are you at that crooks are THAT tech savvy??? Please let me know so I can stay far far away. Now to contribute something productive, rather than just complain on the list. Here are two ideas that if used together be simple and effective. 1) I do like the gesture based approach as that is something that can be easily input using one hand (remember, KISS). However, that may not go over as well for a non-phone interface. So, having an intermediate layer that transform gestures to a key-phrase would be a great idea. Then you can have a preference to either input your password/key-phrase directly OR you can launch the gesture analyzer and that will handle the inputting of your password/key-phrase. 2) The sudo style of access could also be useful. Whenever private data (still not sure the best/most user friendly approach to determining what is and isn't) is accessed, you are required to put in a password (via method above) and it will last for a pre-determined amount of time. Just the combination of those two ideas would probably suffice for +90% of users needs. Then, if someone was actually carrying nuclear launch codes, then a secondary more robust implementation could either replace or supplement. But your grandmother would still be able to (hopefully) figure out that scheme. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Mon, 2007-03-19 at 22:57 +0100, Marcel de Jong wrote: From a user's standpoint: I do not think I'd like to enter a passphrase or any other measures just to open up my contacts list (which is after all a piece of personal data). Also for opening my calendar and such actions on the device, I'd prefer to have no passphrase. snip a de doo daa I think Marcel is probably stating what *most* people are going to want as well. Having the ability to encrypt data is a priority, but not having to use it should be a higher priority. One of the biggest mantra's I hear coming from the FOSS camp is choice and so keeping with the whole practice what you preach ideal, I think the level of encryption should be a user configurable preference. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Jonathon Suggs wrote: One of the biggest mantra's I hear coming from the FOSS camp is choice and so keeping with the whole practice what you preach ideal, I think the level of encryption should be a user configurable preference. I'd caveat that with comment that one of the biggest bugbears against the FOSS camp is usability so if this type of thing is going to be implemented then it should be a single system-wide option that gets handled away in the backend so that applications don't even need to know about it and that users don't have to pick and choose (or worse, select on a per-application basis) what data is encrypted. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Jim McDonald writes: Jonathon Suggs wrote: One of the biggest mantra's I hear coming from the FOSS camp is choice and so keeping with the whole practice what you preach ideal, I think the level of encryption should be a user configurable preference. I'd caveat that with comment that one of the biggest bugbears against the FOSS camp is usability so if this type of thing is going to be implemented then it should be a single system-wide option that gets handled away in the backend so that applications don't even need to know about it and that users don't have to pick and choose (or worse, select on a per-application basis) what data is encrypted. We certainly want a global scheme -- but I think we do want a per-data-item granularity. I've certainly got things on my phone whose protection I don't care about (shopping lists) and other things that have legal implications (notes on how various students' class presentations went). I want to be able to choose save this encrypted vs. save this, and then when I access data I've encrypted I have to enter the password. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Joe Pfeiffer wrote: [Encrypting data] We certainly want a global scheme -- but I think we do want a per-data-item granularity. I've certainly got things on my phone whose protection I don't care about (shopping lists) and other things that have legal implications (notes on how various students' class presentations went). I want to be able to choose save this encrypted vs. save this, and then when I access data I've encrypted I have to enter the password. Yep but on the flipside if you have some data that you want encrypted then encrypting all of it won't do any harm (perhaps a slightly slower response time, and assuming some sort of key caching going on the occasional entering of a decryption token, perhaps on unlock and 'phone startup?). Having to choose for each piece of data if it is encrypted or not, and having to handle that in every application individually, is a great example of where choice can be too much. I think that having a single system-wide setting and handling it appropriately (and far enough down the stack so that applications don't have to worry about it) would provide a simple and uniform approach to this problem without continually asking the user to decide which data is to be encrypted and which not. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On 3/20/07, Jim McDonald [EMAIL PROTECTED] wrote: continually asking the user to decide which data is to be encrypted and which not. There is the concept of folders which could be used :) clare ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Clare Johnstone wrote: On 3/20/07, Jim McDonald [EMAIL PROTECTED] wrote: continually asking the user to decide which data is to be encrypted and which not. There is the concept of folders which could be used :) clare True, but that's just another choice to be made when storing the data plus of course you have filesystem folders, arbitrary categorisation through tags, automatic classification depending on the type of data etc. so there are lots of concepts that can be used, and each one is a potential set of confusion (I tagged the data as 'sensitive' but the system didn't encrypt it because I accidentally put it in the 'public' folder). I just think that this is a good example where having an all-or-nothing approach is preferable to fine-grained control, as the benefits are minimal compared to the complexity for development and day-to-day effort for end-users that have to use such a system. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Mon, 19 Mar 2007 18:25, Jim McDonald wrote: Clare Johnstone wrote: On 3/20/07, Jim McDonald [EMAIL PROTECTED] wrote: continually asking the user to decide which data is to be encrypted and which not. There is the concept of folders which could be used :) clare True, but that's just another choice to be made when storing the data plus of course you have filesystem folders, arbitrary categorisation through tags, automatic classification depending on the type of data etc. so there are lots of concepts that can be used, and each one is a potential set of confusion (I tagged the data as 'sensitive' but the system didn't encrypt it because I accidentally put it in the 'public' folder). I just think that this is a good example where having an all-or-nothing approach is preferable to fine-grained control, as the benefits are minimal compared to the complexity for development and day-to-day effort for end-users that have to use such a system. Cheers, Jim. Ok.. Lets assume for a moment that there is an encryption / security engine.. And its hooked through dbus somehow.. Lets also assume there is a mechanism that handles all requests to save data from any application... Will just call it the save data mechanism.. (Grin)... So on the encryption / security engine it seems like there should be the ability to define user selectable levels of encryption / security.. Such as no encryption but password required.. Light encryption password required... Heavy encryption picture/gesture required (and maybe a certainty level for fuzzy matching like 90% /shrug).. or no password and no encryption.. Etc. Ok. There should be some kind of configuration for the save data mechanism which says select the published security levels (I.e. Those the user created in the security config) and then select which applications follow those rules.. So notes could be no security/no password or it could be 'ask me each time'... Calendar could be the same.. File browser could be heavy encryption with picture.. Etc.. Then each application does not need to know anything about the security levels at all. It just calls the save information api (whatever that is) and hands dbus the data to save. The save mechanism looks at the request and notes the application its coming from and then hands it off to the security engine to encrypt appropriately.. And then it hands it back at which point the save data mechanism can write it to the file system.. Reading is the same.. Except the read data mechanism looks at the application making the request and in the case of ask me data looks at the data to see if its encrypted/secured.. If so it tells the security mechanism which asks the user for the appropriate level of password information and then decrypts or authenticates the read action and the user gets to read the data. Combined with the sudo idea about a configurable amount of time for authorized idleness... And add to it the ability elevate permission levels.. So that once you have authorized to read highly sensitive information you can also just read password protected but not encrypted info.. And then I think it might meet everyones needs. By default no security is provided and none required.. Once configured it could handle almost any level of detail for encryption assuming someone wanted to go through the trouble of making it happen that way. And you could build new security mechanisms that plug into the architecture and allow for some people gesture authentication and for others hand writing codes or voice codes or numeric codes or anything. Um... Yeah.. Ok so that might be 10 cents worth. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tim Newsom writes: Ok.. Lets assume for a moment that there is an encryption / security engine.. And its hooked through dbus somehow.. Lets also assume there is a mechanism that handles all requests to save data from any application... Will just call it the save data mechanism.. (Grin)... So on the encryption / security engine it seems like there should be the ability to define user selectable levels of encryption / security.. Such as no encryption but password required.. Light encryption password required... Heavy encryption picture/gesture required (and maybe a certainty level for fuzzy matching like 90% /shrug).. or no password and no encryption.. Etc. Ok. There should be some kind of configuration for the save data mechanism which says select the published security levels (I.e. Those the user created in the security config) and then select which applications follow those rules.. So notes could be no security/no password or it could be 'ask me each time'... Calendar could be the same.. File browser could be heavy encryption with picture.. Etc.. Then each application does not need to know anything about the security levels at all. It just calls the save information api (whatever that is) and hands dbus the data to save. The save mechanism looks at the request and notes the application its coming from and then hands it off to the security engine to encrypt appropriately.. And then it hands it back at which point the save data mechanism can write it to the file system.. Reading is the same.. Except the read data mechanism looks at the application making the request and in the case of ask me data looks at the data to see if its encrypted/secured.. If so it tells the security mechanism which asks the user for the appropriate level of password information and then decrypts or authenticates the read action and the user gets to read the data. Combined with the sudo idea about a configurable amount of time for authorized idleness... And add to it the ability elevate permission levels.. So that once you have authorized to read highly sensitive information you can also just read password protected but not encrypted info.. And then I think it might meet everyones needs. By default no security is provided and none required.. Once configured it could handle almost any level of detail for encryption assuming someone wanted to go through the trouble of making it happen that way. And you could build new security mechanisms that plug into the architecture and allow for some people gesture authentication and for others hand writing codes or voice codes or numeric codes or anything. Um... Yeah.. Ok so that might be 10 cents worth. I like this -- except it doesn't quite match my sample-of-one user study. My degree-of-security-wanted is by data, not by application. The same app is used for things like VINs and tire sizes and oil filters for cars (no security) and for student presentation grades. It's also not clear to me that more than two levels of security (open/password protected) are needed -- where password protected means encrypted using whatever scheme we've got. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Joe Pfeiffer wrote: snip It's also not clear to me that more than two levels of security (open/password protected) are needed -- where password protected means encrypted using whatever scheme we've got. Personally. Unencrypted: Anything that you might want on display on the screensaver and don't really care if others see it. 4 or 5 digit PIN: GPS track logs, phone numbers, last numbers dialed Passphrase: Audio recordings of all calls. cookies and autofill data for https sites. restricted list of phone numbers. ssh keys to my home system. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Mon, 19 Mar 2007 22:09, Joe Pfeiffer wrote: I like this -- except it doesn't quite match my sample-of-one user study. My degree-of-security-wanted is by data, not by application. The same app is used for things like VINs and tire sizes and oil filters for cars (no security) and for student presentation grades. It's also not clear to me that more than two levels of security (open/password protected) are needed -- where password protected means encrypted using whatever scheme we've got. See that's where the 'ask me' setting comes in.. If an application can store encrypted vs not then its an 'ask me' then on a per data basis you can set it. The multi level security might not be necessary, but this scheme can handle it just in case. The best part is that if you don't want it, you don't use it. And those that do want it, can use it and its all completley transparent to the applications. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Joel Newkirk wrote: Tobias Gruetzmacher wrote: What I'm proposing is a user-friendly encryption scheme of the data the user stores in his phone, so any illegitimate user will not be able to get personal data about the owner of the phone. I'd like a good gestural interface for authentication - a passphrase or password would be a pain with a mini virtual keyboard, a pincode would remain a pain in many situations, a personalized fingertip doodle would be great. Present a virtual keypad but allow a finger-drawn character or shape to authenticate. Or perhaps some sort of voice recognition, perhaps a user-chosen phrase? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Jim McDonald wrote: Joel Newkirk wrote: I'd like a good gestural interface for authentication - a passphrase or password would be a pain with a mini virtual keyboard, a pincode would remain a pain in many situations, a personalized fingertip doodle would be great. Present a virtual keypad but allow a finger-drawn character or shape to authenticate. Or perhaps some sort of voice recognition, perhaps a user-chosen phrase? i like this idea. here's my improvement: pair the normal password/passphrase with voice data. just like in my current phone's address box I can add voice to an entry, a moko user could add voice to their login credentials. on those days when you have a sore throat or you're in a noisy place, the text password could be tapped in. but normally you would press a button, speak the password, and enter--LOTR even more elegant: if the voice credentialing subsystem used PAM (a must in my book) then the voice_auth PAM module would be a simple config in pam.d, added as sufficient for auth. thoughts? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Hello On Sun, 2007-03-18 at 01:19 -0500, Joel Newkirk wrote: Tobias Gruetzmacher wrote: ... I'd like a good gestural interface for authentication - a passphrase or password would be a pain with a mini virtual keyboard, a pincode would remain a pain in many situations, a personalized fingertip doodle would be great. Present a virtual keypad but allow a finger-drawn character or shape to authenticate. j How about something like this? http://www.ischool.berkeley.edu/~rachna/dejavu/ It uses images for recognition-based, rather than recall-based authentication. digger ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Sun, 2007-03-18 at 12:19 +, Jim McDonald wrote: Or perhaps some sort of voice recognition, perhaps a user-chosen phrase? I vote no on this one, primarily due to not being able to access this information without nearby people hearing (Or possibly recording) the pass phrase (Think about trains, planes, buses, business meetings, etc). A user-defined symbol drawn on the screen or a password/PIN tapped into the screen would be ideal, preferably with a user-defined timeout period (1-minute, 5-minutes, until-phone-goes-to-sleep, etc). -KW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Moin, Am Sat, 17 Mar 2007 10:51:31 + (UTC) schrieb Tobias Gruetzmacher: What I'm proposing is a user-friendly encryption scheme of the data the user stores in his phone, so any illegitimate user will not be able to get personal data about the owner of the phone. I was thinking about something similar but with a different direction. One problem I see is that a thief could just connect a debug board and dump the complete memory. Therefore any secret positively must not be stored in the phone but instead in a smartcard for example. 2. SIM-binding - this retrieves/stores a secret on the SIM card, that can only be accessed when the correct PIN for the SIM was entered. The secret is retrieved from the SIM card and used as a key for encfs/ ecryptfs to decrypt the users data I was thinking in that direction. I'm not familiar with SIMs (pretty much experience with other smartcards, though), so: The SIM has some sort of cryptographic function to authenticate itself to the network and assist in the setup of session keys. Can we use this functionality? E.g.: is it standardized enough so that we can expect it to be found in any SIM and can we access it through AT+CSIM and/or AT+CRSM (Harald told me about these commands which allow some level of passtrhough through the GSM modem to the SIM) or any other mechanism? If so we could use this function to key the encryption without actually extracting the secret from the SIM (I vaguely remember reading something about remotely keyed encryption which could be used here). An attacker dumping the memory would gain only those decrypted blocks that were currently in use and nothing more. The alternative approach of storing and retrieving the secret (e.g. as an address book entry) has the significant drawback that the secret must always be present in the phone's memory and can potentially be read from there. -- Henryk Plötz Grüße aus Berlin ~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Sun, 2007-03-18 at 18:57 +0100, Paul Wouters wrote: Excellent idea. Let's ditch the passphrase/pin though, because once we copy the data off phone to another device, brute forcing anything you can type comfortable using a pin or keyboard will be trivial. I wouldn't. Brute-forcing a passphrase/pin is only as simple as the passphrase/pin. Plus you are limiting your thinking to the current MoKo platform (The Neo). In the future there may be MoKo devices with hardware keyboards and without touch screens. An entropy meter associated with the creation of the passphrase/pin would be very useful, as would having a high limit on the number of characters, or no limit at all. It could help people choose better passphrases, making the people more security conscious in the process. Almost all of my passwords are 15+ characters, but they are all memorable (to me) and when I've run them through stand-alone entropy meters, they all rate very highly. I really like the custom drawn symbol idea. It introduces a lot of variables. Not only the lines, but also the timestamps on when scribbling it. Yes, lots of variables, like fuzzy-matching the symbol, because I don't know about you, but I don't think I can be pixel-perfect drawing on a touchscreen in any reasonable length of time. -KW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Moin, Am Sun, 18 Mar 2007 18:40:26 +0100 schrieb [EMAIL PROTECTED]: I would appreciate a fingerprint sensor - there are a lot of Asian mobile phones / smart phones with a fingerprint sensor... Yeah, but a fingerprint sensor adds only convenience and no security at all. starbug regularly demonstrates circumventing any fingerprint sensor on the market (last was the sensor in IBMs Thinkpads, see http://events.ccc.de/congress/2006/Fahrplan/events/1578.en.html or some older material in english at http://www.ccc.de/biometrie/fingerabdruck_kopieren?language=en). Plus: it doesn't solve the underlying problem: A fingerprint sensor might give you authentication (comparable in strength to a numerical 3-digit PIN without retry counter) but can't give you a decryption key. At least it's not obvious to me how one would derive a key with sufficient entropy from the sampled fingerprint data. Biometric authentication always works with some fuzziness factor. Encryption doesn't allow any fuzziness. -- Henryk Plötz Grüße aus Berlin ~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Hi, Am Sun, 18 Mar 2007 18:24:31 +0100 schrieb Henryk Plötz: What I'm proposing is a user-friendly encryption scheme of the data the user stores in his phone, so any illegitimate user will not be able to get personal data about the owner of the phone. I was thinking about something similar but with a different direction. One problem I see is that a thief could just connect a debug board and dump the complete memory. Therefore any secret positively must not be stored in the phone but instead in a smartcard for example. That is certainly a problem. It would be nice if the phone needed a power- cycle before connecting the debug interface to counter such attacks. If so we could use this function to key the encryption without actually extracting the secret from the SIM (I vaguely remember reading something about remotely keyed encryption which could be used here). An attacker dumping the memory would gain only those decrypted blocks that were currently in use and nothing more. That, of course, would be really cool. Does somebody have more info about the SIM access of the GSM module? Would this approach be usable and fast enough? The alternative approach of storing and retrieving the secret (e.g. as an address book entry) has the significant drawback that the secret must always be present in the phone's memory and can potentially be read from there. Yes, I'm aware of that. It would be really useful if we could protect against reading of memory (at least the phone does not have FireWire ;)) Greetings, Tobi -- GPG-Key 0xE2BEA341 - signed/encrypted mail preferred My, oh so small, homepage: http://portfolio16.de/ http://www.fli4l.de/ - ISDN- DSL-Router on one disk! Registered FLI4L-User #0003 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Henryk Plötz wrote: Moin, Am Sun, 18 Mar 2007 18:40:26 +0100 schrieb [EMAIL PROTECTED]: I would appreciate a fingerprint sensor - there are a lot of Asian mobile phones / smart phones with a fingerprint sensor... Yeah, but a fingerprint sensor adds only convenience and no security at all. starbug regularly demonstrates circumventing any fingerprint It can add some security, especially against most opponents that are not going to bother to try to fake the print. For example, four fingers, scanned either upwards or downwards gives you 8 'keys'. If you add a 90 degree rotated finger, that gives you 4*4 = 16 keys. And as the sensors are typically designed as a 256*4 or so camera, you can basically do an optical mouse with them, in reverse, using the finger as a 'surface', to add gestures in the middle of the prints. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Hi, Am Sun, 18 Mar 2007 18:57:21 +0100 schrieb Paul Wouters: I vote no on this one, primarily due to not being able to access this information without nearby people hearing (Or possibly recording) the pass phrase (Think about trains, planes, buses, business meetings, etc). A user-defined symbol drawn on the screen or a password/PIN tapped into the screen would be ideal, preferably with a user-defined timeout period (1-minute, 5-minutes, until-phone-goes-to-sleep, etc). Excellent idea. Let's ditch the passphrase/pin though, because once we copy the data off phone to another device, brute forcing anything you can type comfortable using a pin or keyboard will be trivial. The point is: You cannot. Taking my idea 2 (using the SIM as a key vault) you have 3 tries for the SIM pin and then the SIM is locked and you need the PUK to unlock it. If you get the PUK wrong 10 times the SIM transforms into useless junk. I remove idea 3 (user-choosable passphrase) from my proposal, because that my provide less security then idea 2. If it is possible to store another secret using the PIN2, you could implement private records (as Joe Pfeiffer suggested) using the PIN2. But if we are talking about about generic encryption of user data, maybe a simple public/private flag like in PalmOS would be enough (just to hide private data from a shoulder surfer) If I read http://gsho.thur.de/gsho/technik/download/gsm11-11.pdf correctly (I just read some parts, sorry if I get something wrong), each file on the SIM card can be locked with either the PIN, the PIN2 or by the Administrator (the one who gave you the SIM, your network operator), so you could certainly use the SIM as a key storage... (This document talks about CHV1 and CHV2 where I used PIN and PIN2...) Greeting, Tobi -- GPG-Key 0xE2BEA341 - signed/encrypted mail preferred My, oh so small, homepage: http://portfolio16.de/ http://www.fli4l.de/ - ISDN- DSL-Router on one disk! Registered FLI4L-User #0003 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
but if the passphrase involves cursing at the phone, you won't get anybody to give you a second look. everybody is swearing at these things when appointments get duplicated, calls dropped, etc. Yes, think about the people sitting next to you in a bus or something. They could think you're crazy if you talk to your mobile, and tell it something about your grandma :) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Using fingerprint sensors will make the phone look less good IMO Can't a gesture-based authentication be used? I mean swipe a certain pattern with your finger on the touchscreen. Regards, Hans 2007/3/19, Steven Milburn [EMAIL PROTECTED]: Oh the fingerprint sensor FUD, what fun. First, if one concedes that the typical sensor can be easily fooled, I still think fingerprint sensors tend to add security to most phones. That's because I think most users cannot be bothered to hide data behind a decent pass phrase they would have to type on a tiny keyboard. Joe Average is much more likely to adopt a concept that works something like: Swipe one of your eight fingers (up, down, left, or right) (thumbs can be dexterally difficult) and you are authenticates and one of 32 pre-selected actions happens (call a speed dial, open email, open calendar, etc). A more secure mechanism that no one uses is less secure than an inferior one that people will actually use. But, I wouldn't actually concede that a fingerprint sensor is necessary less secure than a typical password. These days some can be very difficult to spoof. Almost no swipe sensor targeted to cell phones is an optical sensor these days. The common, cheap ones use capacitive sensors. The better ones use active RF sensing, with sophisticated anti-spoof measures built-in. Some of the more advanced sensors even have the ability to securely store keys right on them, and some even have the ability to encrypt/decrypt data for you once you authenticate, with the keys never leaving the sensor. I say all this just to try to clear up some of the FUD. But, I realize full well that suggesting fingerprint sensors is in no way an answer to the security question on the Neo. I don't even think it makes sense to push for a fingerprint sensor to be included in the hardware rev, because there are better things to concentrate on at this point (wifi). --Steve On 3/18/07, Ian Stirling [EMAIL PROTECTED] wrote: Henryk Plötz wrote: Moin, Am Sun, 18 Mar 2007 18:40:26 +0100 schrieb [EMAIL PROTECTED]: I would appreciate a fingerprint sensor - there are a lot of Asian mobile phones / smart phones with a fingerprint sensor... Yeah, but a fingerprint sensor adds only convenience and no security at all. starbug regularly demonstrates circumventing any fingerprint It can add some security, especially against most opponents that are not going to bother to try to fake the print. For example, four fingers, scanned either upwards or downwards gives you 8 'keys'. If you add a 90 degree rotated finger, that gives you 4*4 = 16 keys. And as the sensors are typically designed as a 256*4 or so camera, you can basically do an optical mouse with them, in reverse, using the finger as a 'surface', to add gestures in the middle of the prints. ___ 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: Proposal: Personal Data Encryption (maybe SoC?)
Moin, Am Mon, 19 Mar 2007 00:56:51 +0100 schrieb Hans Bakker: Can't a gesture-based authentication be used? I mean swipe a certain pattern with your finger on the touchscreen. Yes. That gives probably at least enough entropy to replace the SIM's PIN and something we definitely should look into. What I'm thinking about is to use the libstroke mechanism. Short introduction: The gesture area is divided into 3x3=9 bins like so: 1 2 3 4 5 6 7 8 9 You then simply concatenate the numbers of all bins that are touched. An 'L' shape for example would be 14789. This is robust enough to be used as a cryptographic key and might give enough entropy for a 4-digit PIN. (Format the PIN as two byte BCD, SHA-1 the stroke string and fold the hash down to two bytes, then xor pin and hash.) Some feedback will be necessary so the user can see that the gesture was correctly detected before sending the PIN to the SIM. I propose some sort of bubblebabble-digest. -- Henryk Plötz Grüße aus Berlin ~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Moin, Am Sun, 18 Mar 2007 22:15:57 + (UTC) schrieb Tobias Gruetzmacher: If it is possible to store another secret using the PIN2, you could implement private records (as Joe Pfeiffer suggested) using the PIN2. But if we are talking about about generic encryption of user data, maybe a simple public/private flag like in PalmOS would be enough (just to hide private data from a shoulder surfer) Unfortunately you can't use the PIN2, because it already has other uses. E.g. in prepaid card systems the PIN2 is used to recharge the card. Also the fixed dialling numbers file is only writable with PIN2. It would not be uncommon that the phone user doesn't actually know the PIN2 (e.g. parents buying card for their children, giving them the PIN but not the PIN2; or even employer/employee for that matter). Plus: You can't create new files with your own access permissions anyways. File creation is a messy area in the whole smartcard world and almost always depends on manufacturer specific commands. If I read http://gsho.thur.de/gsho/technik/download/gsm11-11.pdf correctly (I just read some parts, sorry if I get something wrong), each file on the SIM card can be locked with either the PIN, the PIN2 or by the Administrator (the one who gave you the SIM, your network operator), so you could certainly use the SIM as a key storage... A thanks for the link. Unfortunately that documents negates my hope: The cryptographic command is RUN GSM ALGORITHM with CLA=A0 INS=88. AT+CSIM won't accept commands with CLA=A0 and AT+CRSM only accepts a selected few INS and 88 is not one of them. This pretty much only allows using the SIM as 'dumb' key storage (albeit with PIN protection with retry counter). The key could be stored in a specially formatted SMS on the SIM or in a phone book entry. -- Henryk Plötz Grüße aus Berlin ~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Sun, 18 Mar 2007, Steven Milburn wrote: First, if one concedes that the typical sensor can be easily fooled, I still think fingerprint sensors tend to add security to most phones. That's because I think most users cannot be bothered to hide data behind a decent pass phrase they would have to type on a tiny keyboard. Joe Average is much more likely to adopt a concept that works something like: Swipe one of your eight fingers (up, down, left, or right) (thumbs can be dexterally difficult) and you are authenticates and one of 32 pre-selected actions happens (call a speed dial, open email, open calendar, etc). It doesnt add more security compared to a scribbled login pattern. And it doesnt require a fingerprint reader. Paul ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
That still requires two hands just to make a phone call. I don't know if it's as bad everywhere else, but American drivers are way too likely to attempt this while driving 80mph in traffic and eating a big mac. The main reason I like the fingerprint sensor concept is that it enables one-handed, no-look speed dialing, while keeping some level of security on the contacts list. I'm seriously contemplating getting a Neo at some point and replacing one of the side buttons with a sensor for this purpose. I think it would be a fun project! --Steve On 3/18/07, Paul Wouters [EMAIL PROTECTED] wrote: On Sun, 18 Mar 2007, Steven Milburn wrote: First, if one concedes that the typical sensor can be easily fooled, I still think fingerprint sensors tend to add security to most phones. That's because I think most users cannot be bothered to hide data behind a decent pass phrase they would have to type on a tiny keyboard. Joe Average is much more likely to adopt a concept that works something like: Swipe one of your eight fingers (up, down, left, or right) (thumbs can be dexterally difficult) and you are authenticates and one of 32 pre-selected actions happens (call a speed dial, open email, open calendar, etc). It doesnt add more security compared to a scribbled login pattern. And it doesnt require a fingerprint reader. Paul ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Sun, 18 Mar 2007 18:05, Henryk Plötz wrote: Moin, /snip Some feedback will be necessary so the user can see that the gesture was correctly detected before sending the PIN to the SIM. I propose some sort of bubblebabble-digest. -- Henryk Plötz Grüße aus Berlin ~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ Can't you just draw the lines that correspond to the locations touched? A gesture can be 1 symbol drawn over the entire screen without picking up the pin/fingertip... Or it could be a 5 second drawing of kanji or some other symbol.. In addition, since it has to be fuzzy, the gesture needs to be ralative to the start position of the drawing and should give a configurable amount of time to enter the entire picture/gesture. Then someone could draw whatever they like in 5 seconds or 10 or whatever.. Or they could do something simple with their finger tip or they could actually write words on the screen, etc. Plus, if you are going to have a 3x3 grid, you might want to make that configurable also.. To add a lot of variability in the supposed gesture / key. Just a few thoughts... Flame away. /grin --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Knight Walker wrote: On Sun, 2007-03-18 at 18:57 +0100, Paul Wouters wrote: I really like the custom drawn symbol idea. It introduces a lot of variables. Not only the lines, but also the timestamps on when scribbling it. Yes, lots of variables, like fuzzy-matching the symbol, because I don't know about you, but I don't think I can be pixel-perfect drawing on a touchscreen in any reasonable length of time. -KW My proposal was simply to have the ability to use my fingertip to trace a shape to substitute for a 'pin' for unlock purposes. Left-right-left-circle-down, or up-down-up-down-up-down-right-up, or any of millions of other possible freehand strokes that can be readily distinguished. Or maybe part of one's signature, drawn with a stylus. When training the system to recognize the 'security stroke' (and the user to trace it consistently if needed), a meter can be displayed letting the user know how secure and distinguishably unique the stroke is. If they opt simplicity over security, then can just use a left-right line or something, while security-conscious users might look spastic unlocking their phones. But it doesn't depend on pixel-perfect drawing, just a sequence of relative 'pen' positions or movements or angles or whatever drives the chosen recognition engine. j ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Joel Newkirk writes: My proposal was simply to have the ability to use my fingertip to trace a shape to substitute for a 'pin' for unlock purposes. Left-right-left-circle-down, or up-down-up-down-up-down-right-up, or any of millions of other possible freehand strokes that can be readily distinguished. Or maybe part of one's signature, drawn with a stylus. Of course, if we have quikwriting as an input method, there's really no difference between a shape and a textual password... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tobias Gruetzmacher wrote: What I'm proposing is a user-friendly encryption scheme of the data the user stores in his phone, so any illegitimate user will not be able to get personal data about the owner of the phone. Greetings, Tobi I'd like a good gestural interface for authentication - a passphrase or password would be a pain with a mini virtual keyboard, a pincode would remain a pain in many situations, a personalized fingertip doodle would be great. Present a virtual keypad but allow a finger-drawn character or shape to authenticate. j ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
