mailing list archives
Re: encryption in android apps
From: Landon Hurley <ljrhurley () gmail com>
Date: Wed, 09 Jan 2013 22:56:32 -0500
-----BEGIN PGP SIGNED MESSAGE-----
On 01/09/2013 08:14 AM, saghar estehghari wrote:
The application is a sort of secure payment with NFC. However the tag
is passive (not connected to any network) and it's the mobile app's
responsibility to communicate with the server.
The whole system works with certificates and signatures for
authentication. This implies that the server generates a certificate
for each user, user authenticates itself with the certificate to the
tag. The tag then uses the info inside the certificate to do
computation. All communications are encrypted. But as reading more
about vulnerabilities about android apps, and I should save the
certificates on the mobile device, I want to make sure that nobody can
sees the contents of the certificates by encrypting them.
As for Public/Private key, I though about the same solution. As the
server will generate the pair of keys and this will be transferred to
the mobile app.
But as for storing the private key on the mobile app, do you think the
a keystore on android would be safe place to store the key?
For PIN code, do you think the entropy of 6 digits is low? I can't use
passwords, as the client needs an easy to use application. If I use
PBKDF2 and an attacker reverse engineers the application can it gets
PBKDF2 uses the PIN and a salt in combination, which are run through the
PBKDF2 algorithm to generate a key. The salt increases the entropy of
the PIN, because its (in theory) a secret that is only found on the
device hardware. As long as the device is trusted, the key is secure as
well: thus, if I understand your concern, even given the source code of
the program, the individual user keys could not be reverse engineered.
It's not as effective as employing a better password, but it will
prevent someone from just creating rainbow tables.
As for where to store private keys: although I'm not familiar with the
Android system structure, each key should be independently encrypted,
with the most obvious choice being to use a PBKDF2 output to encrypt
them. That will ensure that someone grabbing the contents of the
internal memory is still left with an encrypted, and to them useless
file. As a general rule, most systems that use asymmetric encryption
inherently encrypt the private key (certificate) by default. This will
mean that you will not have to rely upon system X's default security;
you can enforce it on your own.
The risk with using a salt though is that given a loss of the salt, you
lose access to any data encrypted with the key, so incorporating a way
to back up the salt would be beneficial.
Violence is the last refuge of the incompetent.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
-----END PGP SIGNATURE-----
This list is sponsored by Cenzic
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!