Práctica recomendada para cifrar datos en una aplicación de Android

Acabo de usar SSL con una clave pública codificada del servidor. Nadie en el camino puede manipular o leer lo que enviaste. No necesitas inventar tu propio protocolo.

Pero, por supuesto, el propio usuario puede manipular y leer los datos de esta manera, pero resolver eso es un problema de DRM y no un problema de seguridad.

Creo que BouncyCastle se puede usar para ese Android. Prefiero TLS 1.2 con un conjunto de cifrado basado en DHE AES128, pero dependiendo de lo que admita su servidor, es posible que deba cambiar a una suite menor.

No es una buena idea implementar su propia solución criptográfica ad-hoc-ish. Probablemente tendrás algo mal. (Por ejemplo, AES con una frase de contraseña codificada es terrible . Cualquiera puede obtener la frase de contraseña simplemente descargando la aplicación y extrayendo la frase de contraseña. No sé por qué duda de que alguien lo haría).

Le recomiendo que utilice soluciones estándar y bien examinadas. Si tiene un canal de comunicación que necesita proteger, use SSL / TLS. Si desea proteger los datos almacenados, utilice GPG / PGP / OpenPGP. Hay bibliotecas y códigos disponibles para ambos que deberían facilitar su integración en su software.

Probablemente optaría por la solución que mencionó el OP, utilizaría RSA y solo tendría la clave pública en la aplicación. Por lo general, debe evitar que la aplicación pueda realizar tanto el cifrado como el descifrado (especialmente con una clave codificada) porque la clave finalmente se eliminará. Si la entrada del usuario es posible, también es posible la criptografía simétrica.

Existen herramientas de ingeniería inversa para buscar funciones de cifrado y hash bien conocidas a través de los sboxes en uso, y desde allí es generalmente bastante sencillo extraer las claves si las almacena en el binario.

Solo tenga en cuenta que rsa es bastante lento, que es una de las razones por las que la mayoría de los usos implican su uso para cifrar una clave simétrica que se utiliza para realizar la criptografía real.

  

Todavía estoy pensando en cuál sería la mejor manera de cifrar el   datos.

Si desea almacenar los datos en el propio dispositivo, puede solicitar una contraseña de usuario y obtener una clave simétrica utilizando una función de derivación de clave. Bcrypt y PBKDF2 son ejemplos bien conocidos.

La mejor manera de cifrar los datos no es en el lado del cliente. Mediante el POST de HTTP de los datos a través de un túnel TLS 1.2 debidamente configurado, uno puede estar seguro de la confidencialidad de la red. Al implementar prácticas de desarrollo seguras y sólidas (por ejemplo, OWASP ASVS L4) junto con pruebas periódicas pero rigurosas (por ejemplo, pruebas avanzadas de penetración de aplicaciones usando Burp Suite Professional, wXf / Buby, y fuzzdb), se puede ayudar a prevenir el compromiso del servidor, aunque Ciertamente, esto no se limita solo al desarrollo, sino también a la implementación segura, a las operaciones seguras, etc. Normalmente se sugieren programas ISO 27k para este tipo de entornos.

Por lo general, no es aconsejable almacenar datos en el lado del cliente que representen un compromiso de información personal o específica de la aplicación, ya sea encriptada o no. Por ejemplo, almacenar (o incluso conservar en memoria durante demasiado tiempo) las credenciales activas de una aplicación bancaria, especialmente con nombres de usuario, contraseñas, nombres reales, números de cuenta, etc. ... es un absoluto no-no.