10:23 a.m.
Aloha!
Christos Vasilakis <mailto:cvasilak@gmail.com>
October 29, 2013 12:26 PM
Hi there,
during the development of security bits in iOS I had come up with some
questions which I will appreciate your input. In particular:
a) As described here [1] a passphrase is asked to be entered by the
user and then we use PBKDF to generate the encryption keys which we
will then encrypt user's data. The problem I see with this approach,
is that if the user decides to change his passphrase we need to
re-encrypt users’ data with the new key.
I think this feature must come on the
next releases, if you check some
well recognized applications like 1password
(http://help.agilebits.com/1Password3/change_master_password.html) is
completely trick to do it. Into this release use let's make it simple:
1- User provides and confirm her password for encryption
2- Data is encrypted
A possible solution is to generate a random _symmetric key_ and then
use PBKDF (with user’s passphrase) to encrypt that _symmetric key_. In
that we stay independent of the user’s passphrase change.
I'm not sure if I
got it right, but if an attacker is able to break the
passphrase would be just a matter of recover that key to decrypt the
data, looks like we just added encryption over encryption.
It can also help in scenarios where a separate PBKDF key can be used
to encrypt the _symmetric key_ , generated by security questions (in
case the user forgets his passphrase).
Security questions should never happen for
local encryption, for this
reason the server must be added on the next release. SafeSlinger for
example adds the concept of Sling keys
(https://www.cylab.cmu.edu/safeslinger/instructions-main.html) so you
are able to decrypt data with previous keys, but I really want to stick
with simple, if for some reason user forgot his password for this very
initial release we won't recover her password.
b) From my understanding, data can be decrypted on server since a
shared secret is used (produced by Diffie-Hellman)?
The server won't be added
into this release, but answering the question.
Server should never be able to decrypt user's data, if something closer
to this was added into our spec (by me or anyone else) that's wrong.
How can this be avoided? During my search came up with a 'Split
Server-Side Keys’ concept described here [2]. Basically two keys are
generated one half resides on the client (generated by PBKDF) one on
the server (random). The server can’t decrypt without possession of
the client key and vice versa. Looked interesting
That's what
https://issues.jboss.org/browse/AGSEC-136 stands for. We
should never expose sensitive user's data for the server.
Let me know if I got your questions correctly.
Thanks,
Christos
[1] http://tinyurl.com/p65tjhv
[2] https://gist.github.com/cvasilak/200180a133e4eb2573ac
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj