On Oct 29, 2013, at 6:36 PM, Corinne Krych <corinnekrych(a)gmail.com> wrote:
On Oct 29, 2013, at 3:26 PM, Christos Vasilakis <cvasilak(a)gmail.com> wrote:
> 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. 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. 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).
+1
I like this level of indirection. I think it make sense for most of the apps. In iOS
symmetric encryption, we already have ramdom key generation [1] so this flow can be
implemented. For now, we're missing storage of keys in keychain. Those scenarios will
be nice to add to AGSEC-132 showcase app. To me, It's more a matter on how you want to
use local encryption.
To encrypt data:
1. generate random key
2. encrypt it using PBKDF2 with passphrase from user
3. encrypt data with random key
4. store key with owner mgt (keychain)
To decrypt data
1. read key from keychain
2. decrypt key from passphrase
3. decrypt data with decrypted key
To change password
1. read key from keychain
2. decrypt key from old passphrase
3. reencrypt decrypted using PBKDF2 with new passphrase from user
4. store key with owner mgt (keychain)
[1]
https://github.com/corinnekrych/aerogear-crypto-ios/blob/master/crypto-sd...
>
> b) From my understanding, data can be decrypted on server since a shared secret is
used (produced by Diffie-Hellman)? How can this be avoided?
Do you mean how can we avoid hacking of the server side?
correct that’s what I meant
> 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
Besides, we're still left with the question of which ECDH Objective-C lib to use…
>
> 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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev