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