freesafe-devel — FreeSafe developers

Re: [Freesafe-devel] jFreeSafe backup and restore updates

[Alex K. <ako...@gm...>]

Laszlo,
   my comments are below:

> Well, with strong crypto that wouldn't be a problem. As there is the
> network between the phone and the server, you can assume that the backup
> data will be bruteforced. Period. The easiest would be to use https but
> MIDP does not support messing around with the certificates and that would
> be needed to prevent man-in-te-middle attacks.

   Yeah, I did think that https would be better than creating a custom
encryption scheme, but I am aware of the limited https support in
handsets. One alternative that I was thinking about was to include the
public key in the jar that goes on the handheld. This way, the server
doesn't have to return the public key every time a backup is
requested, but rather the client can use the public key that comes
with the distribution. There is always the alternative of adding a
'request public key' functionality to support a public/private key
combo different from the default.


> Well, that would be almost as long as a sensible strong key. Another
> thing that I thought of for sharing a secret between the mobile and the
> server is using an alpanumeric encoding instead of a simple hexadecimal.
> It could be just lowercase letters and numbers, then it's 36 symbols.
> That's about 5 bits/symbol, which means 26 characters for a 128 bit
> random key. That's quite acceptable for occasional bacups I think.

   The good thing with using the PBE is that the password/password
phrase could be something meaningful to the user, instead of having a
random string that the user has no chance of remembering (and will
definitely have to write down somewhere - you know how when you try to
enforce security too stringently, users end up subverting it by doing
unwise things the the security methods at hand - e.g. like putting the
password in the name of the backup, on a sticky note with the floppy,
or other such things).



> Yes, I had that idea in my mind when I started this backup thingy (if I
> can say that I started it at all). I wanted to have a PC application and
> I still want to have it very much as the one I use is a piece of crap.
> There is a java version of PasswordSafe but unfortunately that is also
> very lame UI wise. It's a shame, because I liked the original windows
> version a lot. But the PC UI is not a problem, I'll be happy to do it
> once I released the initial backup functionality.

   I was thinking more of a web-app type of app, not so much a rich
client / desktop app. The user has to run the backup server anyway in
order to do the backup; thus, it would be nice if the backup server
provides a UI for manipulating the content of the backup as well
(instead of having yet a third app for editing the backups).

> There would be an even better solution that I did a prototype of for my
> previous employer. I'm quite sorry that I didn't come up with the idea or
> that we didn't publish it. I might ask my ex-boss how acceptable it would
> be for me to do that.

    Hey, anything that would give us a kickstart would be nice.

> Yepp. I always wanted to create a generic Entry type with autogenerated
> Forms. Using that would eliminate this problem as well. However it's not
> completely trivial in the MIDP environment as we don't have reflection
> and using Hashtables in each entry would probably waste a lot of memory.
> But this could be profiled.

   I was thinking more in terms of including the flexibility on the
server side, and leave the phone app to be as limited as it needs to
be. So, my thought went something like this : the client asks for
"Entry Layout v. 1.1" for a backup that is stored as version 1.0 (e.g.
the client upgraded from 1.0 to 1.1 but the backup was done in 1.0).
The server reads the stored records using the 1.0 entry spec, and then
writes out the results the the client using spec 1.1 (that is assuming
that the server will have the necessary crypto pieces - e.g. the
password - to decrypt the backup and read the records).

>
> I'm also on NetBeans. The Mobility Pack is quite cool but it wasn't there
> in 2002 when I started the project and I always wanted the project
> to remain IDE agnostic exactly because I thought of other developers who
> might use a different environment. I know it wasn't worth it since it's a
> very small project.

   I was thinking of maybe having a separate folder with a couple of
NetBeans projects pointing to the source code. Thus, we can keep the
regular Ant script  (e.g. so that you can build and release it without
NetBeans) and still have the Mobility Pack advanced functionality. I
understand the concern with the project being accessible to
non-NetBeans users; however, I don't find it as a good enough reason
to not move forward with something better.


> The debugging should work, as there is a linux shell script that starts
> the application in the emulator with debugging enabled. You just have to
> attach the debugger. I know it's one step more than from the IDE but it
> works for the Eclipse guys too. However, I'll review what I could do
> about it.

   Sure, if debugging works, it would probably be a good idea to put
up a note on the site on how to do so.

>
> I started to use the Mercurial VCS lately and I like it a lot and I'm
> planning to move the whole project under it. I think I'll keep the
> sourceforge repository as well and push the changes there from time to
> time but I'll use Mercurial locally and to work with the contributors
> (well, that's you :) ). BTW it has a very nice NetBeans support. It
> allows you to do the commits locally and then other developers can pull
> the changes from you to their repository. Would you mind start using
> that? I can publish a URL where you could pull the latest revision from
> after integrating your patch and from then on you could use it.

     That'll be fine with me, I was looking for a good excuse to start
using Mercurial anyway. The other day I pulled down the NetBeans
mercurial repo, but I haven't done anything with it. One thing that is
slightly concerning with that approach is that I see a lot of
complications with the Hg usage on the NetBeans mailing lists, and
since it's a distributed VCS some things are just conceptually
different and could cause unnecessary trouble.


Cheers,

Alex K

Re: [Freesafe-devel] jFreeSafe backup and restore updates

[Marai L. <at...@at...>]

On Sun, 3 Feb 2008 19:34:55 -0500
"Alex Kotchnev" <ako...@gm...> wrote:

  Hi,

> else, as there is no need to mess around with both server and client
> side : all that the server does is to store and retrieve the encrypted
> data

Yes, I got it.

>    I don't think there is anything there describing your proposed
> authentication scheme. The current setup only does the PBE and sends

Then probably I forgot to check it in, as usual. :)

> the encrypted data to the server. One minor improvement would be to
> include some kind of authentication at the server before accepting a
> backup or retrieving one, as currently any backup files are available
> without authentication (e.g. anyone could potentially pull any backup
> (and attempt a brute force) if the backup server is left up and
> running).

Well, with strong crypto that wouldn't be a problem. As there is the
network between the phone and the server, you can assume that the backup
data will be bruteforced. Period. The easiest would be to use https but
MIDP does not support messing around with the certificates and that would
be needed to prevent man-in-te-middle attacks.

>    These are all good ideas, the question is whether you or I would
> have the time to commit to implementing something more complex. At

I'm willing to work on it, it just seemed to much at once to get the
protocol, the ui and the app logic (storing keys, etc) right at once. Now
you did some of it, so it doesn't look that much anymore :).

> least on my side, I am pretty busy : the only reason that I was able
> to set aside time to add this feature is that I'm changing my phone
> and I needed a good way of moving my data from one phone to the other.

I have to admit, that I was too lazy to do that. I let my data go with my
9500 and now I don't use the app on my 6120. I'm kind of busy too, but as
I became a freelancer in September things have changed a lot. Sometimes
I'm too busy then I usually have free periods. I know I promised that I
would work on it last year, during my sabbatical, but I found that I
wasn't able to achive anything. I needed to have a break.

>     I would urge you to review these changes and make sure that they
> would work for you as well. The stronger crypto would be great;
> however, I would imagine something similar could be accomplished if we
> just require a long enough (and complex enough) password for the PBE

Well, that would be almost as long as a sensible strong key. Another
thing that I thought of for sharing a secret between the mobile and the
server is using an alpanumeric encoding instead of a simple hexadecimal.
It could be just lowercase letters and numbers, then it's 36 symbols.
That's about 5 bits/symbol, which means 26 characters for a 128 bit
random key. That's quite acceptable for occasional bacups I think. 

> solution that is there right now. My point overall is that it would be
> most beneficial to the project to have a working solution for backup
> and restore and having one that is just "good enough" would be better

Sure. I'm susceptible to perfectionism and I always have to remind myself
to go for the good enough solution first.

>     I was also thinking of the possibility of allowing server side
> editing of the "keyring" that is backed up to the server. The idea is

Yes, I had that idea in my mind when I started this backup thingy (if I
can say that I started it at all). I wanted to have a PC application and
I still want to have it very much as the one I use is a piece of crap.
There is a java version of PasswordSafe but unfortunately that is also
very lame UI wise. It's a shame, because I liked the original windows
version a lot. But the PC UI is not a problem, I'll be happy to do it
once I released the initial backup functionality.

> that it is often cumbersome to have to do data input on the device
> (e.g. unless you have a qwerty type device), and it would be VERY
> beneficial to be able to drop a backup to the server, edit it, and
> restore it back to the device with the updated values.

There would be an even better solution that I did a prototype of for my
previous employer. I'm quite sorry that I didn't come up with the idea or
that we didn't publish it. I might ask my ex-boss how acceptable it would
be for me to do that.

>     One  other problem that I became acutely aware of is how sensitive
> the application is to changes in the field layout of the stored
> records because they are stored in a binary format. The problem was

Yepp. I always wanted to create a generic Entry type with autogenerated
Forms. Using that would eliminate this problem as well. However it's not
completely trivial in the MIDP environment as we don't have reflection
and using Hashtables in each entry would probably waste a lot of memory.
But this could be profiled.

>    Finally, I'm not sure what you use for your development, but if
> attracting other developers is any kind of priority or interest to
> you, the current setup with a plain ant build is not very developer
> friendly : e.g. it works well to produce the build artifacts, but if
> you want to try to do anything more than that (e.g. debug the app,
> server or client side) it is not very friendly. I'm a big fan of

I'm also on NetBeans. The Mobility Pack is quite cool but it wasn't there
in 2002 when I started the project and I always wanted the project
to remain IDE agnostic exactly because I thought of other developers who
might use a different environment. I know it wasn't worth it since it's a
very small project.

> whole bunch of other things. I think it would be extremely useful to
> have something like this committed into the repository so that if a
> new user wants to tweak the app they can get a quick start in no time.

The debugging should work, as there is a linux shell script that starts
the application in the emulator with debugging enabled. You just have to
attach the debugger. I know it's one step more than from the IDE but it
works for the Eclipse guys too. However, I'll review what I could do
about it.

I started to use the Mercurial VCS lately and I like it a lot and I'm
planning to move the whole project under it. I think I'll keep the
sourceforge repository as well and push the changes there from time to
time but I'll use Mercurial locally and to work with the contributors
(well, that's you :) ). BTW it has a very nice NetBeans support. It
allows you to do the commits locally and then other developers can pull
the changes from you to their repository. Would you mind start using
that? I can publish a URL where you could pull the latest revision from
after integrating your patch and from then on you could use it.

  Laszlo

Re: [Freesafe-devel] jFreeSafe backup and restore updates

[Alex K. <ako...@gm...>]

Laszlo,
   a few comments on your comments:

> I only had the time to look through your patch. It's a great help as it
> has most of the things I was reluctant to write :). However, I don't like
> the fact that you use PBE (password based encryption) for sending the
> data over the wires.

   I see your point, we can clearly use stronger encryption when
backing up and restoring the data in the application. It should be
pretty straightforward to replace the encryption scheme with anything
else, as there is no need to mess around with both server and client
side : all that the server does is to store and retrieve the encrypted
data

> I figured out a protocol that would probably work. I'm not sure if I put
> the docs in the CVS or not.

   I don't think there is anything there describing your proposed
authentication scheme. The current setup only does the PBE and sends
the encrypted data to the server. One minor improvement would be to
include some kind of authentication at the server before accepting a
backup or retrieving one, as currently any backup files are available
without authentication (e.g. anyone could potentially pull any backup
(and attempt a brute force) if the backup server is left up and
running).

> It's basically the same as HTTPS: the server
> generates an RSA key-pair, and then sends its public key to the mobile.
> The mobile generates a symmetric key for twofish, and sends it back to the
> server encrypted with the public key and then it sends the data encrypted
> with the symmetric key using twofish. To prevent man-in-the-middle
> attacks the server and the mobile have to have a shared secret. What I
> thought of is generating a random string on the mobile and then typing it
> in on the server. Then when the server sends the public key to the mobile
> it will also include an HMAC (a hash) of the public key and the random
> string.
>
> Now if we don't want this whole authentication thing at first then it's
> enough to just use any (non-password based!) symmetric key. But then it
> has to be entered by the user manually in case of a restore on another
> device. That would mean 32 characters for a 128 bit key or 48 for a 192
> bit (that's used to encrypt the password store itself). 32 characters
> _might_ be tolerable. I don't know what's the estimated time to
> bruteforce 128 bit Twofish.

   These are all good ideas, the question is whether you or I would
have the time to commit to implementing something more complex. At
least on my side, I am pretty busy : the only reason that I was able
to set aside time to add this feature is that I'm changing my phone
and I needed a good way of moving my data from one phone to the other.

>
> All in all, what I'm going to do is that I'll apply your patch locally
> and then look at what it's like exactly and then I'll figure out how to
> fix the crypto part the fastest way. (That would be probably using a
> strong key and typing it in before a restrore.) Then I'll do the more
> complicated solution. That shouldn't take too much time as you did
> write basically all of the application logic part. At least as far as I
> can see from looking through the patch.

    I would urge you to review these changes and make sure that they
would work for you as well. The stronger crypto would be great;
however, I would imagine something similar could be accomplished if we
just require a long enough (and complex enough) password for the PBE
solution that is there right now. My point overall is that it would be
most beneficial to the project to have a working solution for backup
and restore and having one that is just "good enough" would be better
than delaying a release in order to have the "perfect" solution. We
could certainly work something more robust and secure later on (e.g. a
dropdown in a future release to select "strong" or "normal"
encryption).

    I was also thinking of the possibility of allowing server side
editing of the "keyring" that is backed up to the server. The idea is
that it is often cumbersome to have to do data input on the device
(e.g. unless you have a qwerty type device), and it would be VERY
beneficial to be able to drop a backup to the server, edit it, and
restore it back to the device with the updated values.

    One  other problem that I became acutely aware of is how sensitive
the application is to changes in the field layout of the stored
records because they are stored in a binary format. The problem was
that I had made some local changes (prior to submitting the previous
patch to you) with the field sizes differing from the official release
and I had used that version to store all of my passwords. As a result,
when I installed the official release, I was unable to open my stored
passwords. Finally, it was a royal pain the rear to debug the issue
because although I had the stored passwords in the phone's recordstore
and in the backup, there was no "utility" that I could run on my
laptop to "dump" the passwords in some cleartext format just in case I
had to re-key them from scratch (e.g. in the case of a breaking data
format change like I had)

   Finally, I'm not sure what you use for your development, but if
attracting other developers is any kind of priority or interest to
you, the current setup with a plain ant build is not very developer
friendly : e.g. it works well to produce the build artifacts, but if
you want to try to do anything more than that (e.g. debug the app,
server or client side) it is not very friendly. I'm a big fan of
NetBeans and I have a couple of NetBeans Mobility Pack projects set up
that build the project and allow running in the emulator, debugging on
the emulator, deployment, editing of deployment properties, and a
whole bunch of other things. I think it would be extremely useful to
have something like this committed into the repository so that if a
new user wants to tweak the app they can get a quick start in no time.

Cheers,

Alex K

Re: [Freesafe-devel] jFreeSafe backup and restore updates

[Marai L. <at...@at...>]

  Hi,

>    attached is a patch (against trunk) to allow backup and restore
> functionality. You already had the functionality stubbed out, but with
> no implementation. This implementation is slightly different than what

First of all, thanks for your work!

> you had initially started: in this implementation, the user gets to
> specify a password when he is requesting a backup and restore, and the
> server side simply stores and returns the password protected record

I only had the time to look through your patch. It's a great help as it
has most of the things I was reluctant to write :). However, I don't like
the fact that you use PBE (password based encryption) for sending the
data over the wires. At first I thought I would just do that but it's not
strong enough and can be bruteforced. I just made a simple calculation
and it seems that an 8 char long, completely random alphanumeric password
could be bruteforced with 100% probability in less than a year. I just
ran into an estimation on the website of a similar application for PalmOS
that a 1.2GHz PC can do about 1.5M tries/sec. That application uses MD5
and 3DES but I don't think that there is too much difference between that
and our Twofish/SHA1 scheme. I assumed that today a PC can do 6M
tries/sec (given that they can have 2-4 cores and twice the clock rate
it's a modest assumption).

A few thousand years worth of protection is a realistic requirement, I
think. Note that one has to take in account that the computing power
that one can buy for $1 doubles every 1.5 years and that means a hundred
times in ten years. So what's a thousend year today, will be 10 years from
ten years now, and that means that it's less than 20 years instead of a
thousand. And since FreeSafe can store credit card numbers, thanks to
your patch, that may be valid for _at least_ a decade, we have to go for
strong encryption in this case. Also we have to prevent man-in-the-middle
attacks.

I figured out a protocol that would probably work. I'm not sure if I put
the docs in the CVS or not. It's basically the same as HTTPS: the server
generates an RSA key-pair, and then sends its public key to the mobile.
The mobile generates a symmetric key for twofish, and sends it back to the
server encrypted with the public key and then it sends the data encrypted
with the symmetric key using twofish. To prevent man-in-the-middle
attacks the server and the mobile have to have a shared secret. What I
thought of is generating a random string on the mobile and then typing it
in on the server. Then when the server sends the public key to the mobile
it will also include an HMAC (a hash) of the public key and the random
string.

Now if we don't want this whole authentication thing at first then it's
enough to just use any (non-password based!) symmetric key. But then it
has to be entered by the user manually in case of a restore on another
device. That would mean 32 characters for a 128 bit key or 48 for a 192
bit (that's used to encrypt the password store itself). 32 characters
_might_ be tolerable. I don't know what's the estimated time to
bruteforce 128 bit Twofish.

> store. This approach would probably not work too well in attempting to
> transfer the backups from one handset model to another (e.g. if they
> have different implementations of RecordStore); however, it works well
> with the same or related models (e.g. I just finished a backup from a
> Nokia E61, and restored it into a Nokia E61i).

It's not a problem. The API you hooked in is totally independent of
RecordStore. The data that the applications read out and write into the
store is device independent (of course). The actual record store file
format (if there is a file at all) is what's device dependent but you
only encounter it if you access it e.g. through the filesystem of the
phone.

All in all, what I'm going to do is that I'll apply your patch locally
and then look at what it's like exactly and then I'll figure out how to
fix the crypto part the fastest way. (That would be probably using a
strong key and typing it in before a restrore.) Then I'll do the more
complicated solution. That shouldn't take too much time as you did
write basically all of the application logic part. At least as far as I
can see from looking through the patch.

  Laszlo