2010-07-27 15 views
21

Quiero almacenar alguna información pequeña pero crítica, como las claves AES en mi aplicación Android. ¿Cuál sería la forma recomendada de hacer esto? No quiero hardcode keys como parte de mi aplicación.Android Secure Storage

Miro KeyStore pero realmente no resuelve mi problema. Puede almacenar mis claves dado que puedo proporcionar una contraseña. Entonces necesito encontrar un lugar seguro para almacenar esta contraseña que es igual a mi problema original.

¿Hay una clase de Android incorporada para realizar esta tarea? ¿O debería buscar bibliotecas de terceros? Usar NDK también es aceptable para mí.

Actualización:

Tenía la esperanza de encontrar una API de Android para el almacenamiento de tal manera que garantiza que sólo la aplicación que almacenan cierta información pueden recuperar de nuevo. El sistema operativo Android podría haber aplicado esto basándose en firmar firmas de la aplicación. De esta forma, mi aplicación puede generar una clave aleatoria en la primera ejecución y almacenarla en un almacenamiento seguro para su uso posterior. ¿Hay alguna API para esto?

+2

Bueno, si se almacenan datos en '/ datos/datos de la aplicación/ /' sólo entonces que la aplicación pueda acceder a él. Esto no es cierto si el teléfono está rooteado. Pero aparte de eso, debería estar bien almacenando datos de contraseña allí. – Falmarri

Respuesta

5

¿Hay una clase de Android incorporada a realizar esta tarea?

Aparte de java.io.File, no.

¿O debería buscar las bibliotecas de terceros ?

Puede intentarlo, pero sospecho que la mayoría se verá como la solución que ya rechazó. La mayoría de los almacenes de datos seguros implican contraseñas y suponen que las contraseñas se guardan en otra parte (por ejemplo, en la cabeza de un usuario). Por ejemplo, OI Safe tiene un sistema basado en el propósito de permitir que las aplicaciones almacenen cosas en la caja fuerte, pero luego el usuario está involucrado en el desbloqueo de la caja fuerte, IIRC.

+0

Gracias por la respuesta. Realmente no resuelve mi problema, pero es bueno saber las limitaciones. –

+0

@Szere Dyeri: "Esperaba encontrar una API de Android para el almacenamiento que garantice que solo la aplicación que almacenó cierta información pueda recuperarla". - No existe tal API en Android, lo siento. – CommonsWare

+2

¿Qué quiere decir con que no hay tal API? Esta garantía es el comportamiento predeterminado de todos los archivos que la aplicación almacena en el almacenamiento interno, ya que a cada aplicación se le asigna un ID de usuario único y el modo predeterminado de archivos que crea una aplicación debe ser solo legible/grabable por el usuario del creador. El único, excepto esto, es (a) los archivos colocados en el almacenamiento externo, y (b) los archivos creados con la bandera para que sean legibles/grabables en todo el mundo. La única forma en que se puede ejecutar otra aplicación con su uid es si ambos (a) están firmados con su certificado y (b) ambos tienen el mismo android: sharedUserId. – hackbod

4

Una solución, si termina utilizando la API de KeyStore, es generar su contraseña dinámicamente en tiempo de ejecución cada vez que la aplicación necesite acceder a KeyStore. Si basa su algoritmo de contraseña en una variable simple, pero variable, vinculada a la instalación específica, como el MEID del dispositivo (u otra identificación específica del dispositivo físico obtenida en tiempo de ejecución), podría proporcionar una clave para el bloqueo que se vuelve cada vez más difícil para recoger.

Ejemplo: utilice una identificación del dispositivo físico, córtela en tres posiciones y añádalas a la posición final en la cadena ID, luego agregue sus iniciales a la cadena programáticamente. Creo que este enfoque daría una capa de seguridad que no se puede romper fácilmente a menos que el cracker sepa cómo se hizo la clave (es decir, tiene su código fuente).

MEID = MEID + "fluffy" + "2008"; 

Dónde MEID es una cadena con una identificación del dispositivo, "esponjoso" es el nombre de sus mejores amigos gato, y "2008" es el año de un acontecimiento importante en su vida. Luego ingrese esta nueva cadena en una matriz, analice el número que más le convenga (el día del mes en que obtuvo su licencia de conducir, por ejemplo), retire tres caracteres y suelte esos caracteres al final de la cadena. Clip desde el frente de la cadena a la cantidad de posiciones que necesita para su llave y listo. Esta no debe ser una tarea muy intensiva en cuanto a los procesadores, por lo que, con algún código de tolerancia a fallas para las variables, debería ser capaz de ejecutar esto en su proceso principal incluso sin preocuparse demasiado por obtener un ANR del sistema. Si realmente quieres ponerte froggy, convierte la cuerda en bits en algún punto y "bitwise op" en los cambios. Viola, una clave dinámica baja, que es única para el dispositivo en el que se ejecuta.

EDIT:

Como @RedWarp señaló, descompilación un .apk es siempre dentro del ámbito de la possiblility para cualquier código objeto con las herramientas y la motivación adecuada. Si la generación "clave" es un proceso realmente importante, entonces es imprescindible abstraer el gen clave fuera del alcance de la aplicación.

El verdadero punto que intento hacer con esta respuesta es que un poco de pensamiento puede ir un poco con respecto a la seguridad mínima. Una seguridad más sólida es más profunda que una simple respuesta mía.

+1

La seguridad a través de la oscuridad solo puede retrasar a un atacante persistente. Seguro que agrega sabor a la receta. No debe usarse como una única opción viable. – Samuel

+0

@SamQuest Por supuesto, esto no se presenta como la única opción viable, pero es un comienzo, para que uno piense de otras maneras únicas con respecto a la seguridad clave. Pero a menos que la aplicación en cuestión sea una aplicación financiera u otra implementación de alta seguridad, esto debería proporcionar suficiente oscuridad. Otra opción podría ser proporcionar remotamente la clave oscurecida a través de un script RPC o algo así, pero este enfoque probablemente incluirá complejidad adicional. – Kingsolmn

+2

Es bastante fácil revertir una .apk, y por lo tanto obtener el algoritmo – Redwarp

0

Debe distinguir aquí entre las claves y los datos de la aplicación.

KeyPairGenerator y KeyGenerator "AndroidKeyStore" almacena las claves que generan desde su aplicación bajo un alias en KeyStore y asocia las claves a su aplicación. Si el dispositivo tiene "hardware seguro" puede especificar que se use y las claves se almacenarán allí.

No hay contraseña para las claves. Utiliza el alias para especificar qué tecla quieres usar. Solo su aplicación puede recuperar las claves que generó.

ver: https://developer.android.com/training/articles/keystore.html

Para los datos privados de su aplicación, si entiendo ".. una API de Android para el almacenamiento de tal manera que garantiza que sólo la aplicación que almacena cierta información se puede recuperar de nuevo ...", Es posible que mira estas:

https://developer.android.com/guide/topics/data/data-storage.html#filesInternal https://developer.android.com/guide/topics/data/data-storage.html#db