Web Application Security
Re: encryption in android apps Jan 09 2013 01:14PM
saghar estehghari (s estehghari gmail com) (1 replies)
Re: encryption in android apps Jan 10 2013 03:56AM
Landon Hurley (ljrhurley gmail com)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/09/2013 08:14 AM, saghar estehghari wrote:
> Hey,
>
> 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
> the key?
>
> Thanks
> Saghar
>

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.

landon

- --
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/

iQIcBAEBCgAGBQJQ7jvwAAoJEDeph/0fVJWsDtwP/jdHrhf462IGzaqZcaYig7jF
gkwirLbRS8J93qwutT5IiiK8KuWTHgZ7Q56dgWfzMvkPn8eN1M+W++vMddofq4ok
/VIbLpEQvBAVgy7/7fkGeI10rVz9Xnf87gB3PpSlWGDORbdPmXFAP54/BnmA8Nm1
RmJDuw1F8hVm8Qu32QNO0aGHar1YHneNrs0bzW6gPy6payZ5Hv0pDrBJEx9lIjQg
vlydQgGeH+eX36oG4LvMAIjR6CkpUFxmNKtivBW94K/GLNt3WdcV6ETITk0o64LM
NFwPpCSqXy7wpcTT2dX+kPpADIlYsHanA6YEd8kS5LdIG+PJO/5lDOIE+/gewVNP
aWBFawI4WkhHOnXn2LW/u/uFY8U91TAobpu5D7/Plf6UhTk3QIq7CfS3sI80aema
slgsv3NA3X1ARcq0FIdrXC3pv+C1ArvuoQKY5B4sOZpMPNqLIJws9LDxqnaIDC4p
0DUdBadKGW021xXPZvxxCyB7NgWs03qYvN0EV4jUxt8NTaLb4HJZdEo6IcDX4Yrp
6lI1IRmS4RNhLKhsvKeaTx/Aq+SK7JFRcZM/rXu+f8c0y6p4IO7UG3PsB3GCP7m0
uqq/4H37JV7hjihmt6AeBVM2IQkqBQbHu7Ga5NqCe+7Oyuag5OmwIYlejdGsgeiI
tIHk5EcyU9zLVyhGi6Qf
=zSeu
-----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!
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus