Cómo ocultar la clave de API de Android

Muchas aplicaciones de Android que interactúan con la nube utilizan una arquitectura cliente - servidor con la actuación teléfono como un cliente y gran parte del trabajo pesado que tiene lugar en el servidor. A veces usted tiene control sobre el servidor y, a veces es un tercero que proporciona los datos, por ejemplo, actualizaciones de tráfico, datos del mercado de valores, o la información meteorológica, etc. Normalmente estos terceros proveedores utilizan una clave de API como un mecanismo de autenticación simple para permitir el acceso a estos recursos, y como una forma de cobrar por sus datos.

Ahora hay un montón de razones por las que es posible que desee mantener su clave de API de seguridad. Obviamente, si usted está cobrando por el acceso a los datos de la API y luego no quieres a alguien para descompilar el APK, encontrar su clave de API, y luego empezar a usarlo en sus propias aplicaciones. Está bien va a costar dinero para estas llamadas a la API robados, o peor aún, crear frustración para los usuarios existentes si su API de repente deja de funcionar porque el proveedor detiene su acceso cuando se ve el aumento de la actividad. Si su clave de API no convertirse comprometida a continuación, obtener una nueva clave a sus usuarios nunca es fácil. ¿Se revoca la clave de API de edad y cambia a una nueva clave de API, lo que podría dejar a los usuarios de versiones anteriores de cadena? ¿O se mantiene la vieja API clave vivo mientras espera a que los antiguos usuarios para mejorar, pero corre el riesgo de nuevos cargos falsos? De cualquier manera, no va a ser 100% satisfactorio, así que lo mejor es evitar por completo la situación.

Antes de examinar las opciones para ocultar su clave API, echemos un vistazo a cómo alguien puede encontrar su clave de API. Hay dos tipos básicos de ataque, en primer lugar, por la descompilación APK para ver si se almacena en alguna parte del código, y en segundo lugar el uso de un hombre en el ataque medio (MITM) para ver si se transmite de forma insegura en la web. Para acceder al tráfico de la red que el hacker tiene que arrancar de raíz sus teléfonos usando algo como ProxyDroid. Esto permite que el tráfico a ser interceptada utilizando la herramienta de Charles Proxy o BurpSuite usando un ataque MITM.

Claves de la API se envían a menudo a través de una URL. Por ejemplo, usted puede hacer una solicitud a la API Weather Underground utilizando el siguiente URL,
http://api.wunderground.com/api/2ee858dd063ef50e/conditions/q/MI/Troy.json dónde 2ee858dd063ef50e es la clave de la API. Si envía la solicitud a través de HTTP y luego la tecla API sería claramente visible para cualquiera que haga un ataque MITM. Envío correctamente a través de HTTPS hará que sea imposible ver la clave de la API a través de proxy. Nota usé la palabra "correctamente". Los medios de comunicación está llena de ejemplos de ataques MITM donde el HTTPS fue interceptado debido a la aplicación aceptó un certificado SSL falsa generada por herramientas como Charles Proxy en lugar de comprobar que se trataba de una autoridad de certificación de confianza (CA). También hemos encontrado ejemplos en los que el propio dispositivo no manejó certs correctamente y cualquier tráfico HTTPS estaba abierto a un ataque MITM. También es necesario tener cuidado con donde vive clave API antes de montar la llamada HTTPS. Veremos que el próximo.

En mi auditorías de cientos de aplicaciones móviles Android que he visto muchos intentos para ocultar la clave de API. En este artículo veremos algunas de las formas desarrolladores han tratado de proteger su clave de API.

Las opciones posibles son los siguientes:

1. En preferencias, bienes o recursos carpetas compartidas
2. Codificado en Java
3. Uso de la NDK
4. API tecla / cambio de clave privada Pública

En preferencias, bienes o recursos carpetas compartidas

A continuación se muestra un ejemplo de una clave de API que se encontró por descomprimir el archivo APK después de que se quitó el teléfono y mirando en la carpeta asssets.

0M5WrSiVVUbMohPNDsrAmIb0hR6NftlV9E1hjvA0M5WrSiVVUbMohPNDsrAmIb0hR6NftlV9E1hjvA03JOvW5GGOOkIY0n70rIiPPFlZjqOqI3SFhKoYA

El lugar más común me parece que las claves desarrolladores tienda API se encuentra en las preferencias compartidas, a continuación es un ejemplo. Es una práctica común para poner APIkeys en la carpeta de recursos en el APK, que luego se almacena en las preferencias compartidas después de la aplicación se abre por primera vez.

Codificado en Java

Una clave de API es mucho más probable que se encuentra en la carpeta de los activos o recursos que en el código descompilado porque es mucho más fácil de actualizar xml que el código compilado. Pero todavía sucede con regularidad. A continuación un ejemplo de una clave de API que se encuentra en una aplicación de la farmacia que se almacena en un archivo Constants.java.

Constantes de clase del paquete-com.riis.pharmacy pública {public static API_TOKEN final String = "Nti4kWY-qRHTYq3dsbeip0P1tbGCzs2BAY163ManCAb" -}

Uso de la NDK

El Kit Devlopment nativo de Android (NDK) le permite escribir código en C / C ++, y puede ser muy útil cuando usted está tratando de ocultar cosas como claves API. La buena noticia es que las bibliotecas NDK no se puede descompilar hacer la información más difícil de encontrar. El código NDK compilado todavía se puede abrir con un editor hexadecimal, sino por la naturaleza de la clave de API que son más difíciles de distinguir en un editor hexadecimal.

# include # includejstring Java _ com _ _ apindk riis _ _ MainActivity invokeNativeFunction (JNIEnv * env, javaThis jobject) {return (* env) -> NewStringUTF (env, "Nti4kWY-qRHTYq3dsbeip0P1tbGCzs2BAY163ManCAb") -}

Usted debe incluir una llamada para ver si la suma de comprobación se adapte a su APK lo contrario alguien puede llamar a su biblioteca NDK fuera de su aplicación para recuperar la contraseña. Este enfoque en última instancia, no va a ser lo suficientemente bueno para detener a alguien de la lectura de la binaria. Pero es una mejor opción a considerar si usted no tiene más remedio que poner las llaves de la API o de cifrado en el dispositivo, por ejemplo, si el servidor back-end pertenece a un proveedor de terceros. Código desensamblado también se vuelve rápidamente más difícil de entender como se pone más lejos de estos ejemplos helloworld simples.

/ Intercambio de claves API privada Pública

Mientras HTTPS oculta de forma segura la clave de la API durante la transmisión, la recuperación de la clave de la API del teléfono para la llamada HTTPS se puede hacer es un verdadero problema para los desarrolladores. Como hemos visto esconde una clave de API no es diferente a cómo las personas tratan de ocultar una clave de cifrado simétrico (ver mi artículo anterior sobre dónde almacenar sus contraseñas). Todas estas claves se pueden recuperar mediante la copia de seguridad o el comando adb tirón adb y un poco de perseverancia. Así que incluso si el hacker no puede realizar un hombre en medio del ataque aún pueden ver cómo se pone la llamada juntos y la API que se utiliza en la llamada para que puedan apropiarse de su recurso si es útil para ellos. Podríamos intentar tratar de cifrar la clave de API en el teléfono, pero si usted está almacenando la clave de cifrado en el teléfono, entonces estamos simplemente añadiendo un paso más para llegar a la clave de API.

Sin embargo, usted puede utilizar un intercambio de claves API pública / privada para salvaguardar la clave de API, lo que ya no puede ser robado. La desventaja de usar el intercambio de claves pública / privada para las contraseñas es que el teléfono no puede estar en modo de avión cuando se conecta como el descifrado se realiza en un servidor remoto. Esto no se aplica a las claves de la API, ya que siempre están usando la comunicación de red.

La clave primero debe ser cifrada con la clave pública en un servidor remoto a través de su biblioteca favorita como KeyCzar de Google. Usted puede almacenarlo en el res / xml carpeta para que pueda recuperarlo cuando alguien abre la aplicación en el teléfono y luego almacenarla en las preferencias comunes de la aplicación, o enviarlo a la aplicación desde el servidor remoto para que pueda ser reutilizado cuando sea necesario. Cuando se realiza la llamada URL de la clave de API cifrado se envía a través de HTTPS y luego se descifra en el servidor para que pueda ser comparada con la clave de API real. También puede utilizar alguna otra pieza dinámica de información como el nombre de usuario para asegurarse de que la clave de API encriptados, no puede en sí ser utilizado como una clave de API. No hay nada que impida que otra persona que envía la misma clave de API de cifrado de una aplicación diferente para derrotar a tus esfuerzos. Usted puede poner fin a estos ataques de repetición de cifrado de la clave de API junto con una sola vez número generado aleatoriamente o GUID, conocido como un nonce. El nonce y la clave de API se envían al servidor para la autenticación de la API, y la clave de API y un nuevo nonce se envían de nuevo al cliente para ser salvo en las preferencias compartidas después de cada entrada para el siguiente uso. Cada nonce generado se guarda cuando se crea y marcada como se usa una vez que ha sido enviado desde cualquier cliente.

Conclusión

¿Qué opción que elija es probablemente va a ser determinada por la cantidad de control que tiene sobre el servidor back-end. Si usted no tiene ningún control entonces usted está probablemente va a tener que ocultar la clave de API utilizando el NDK. Si lo hace, le recomendamos el público / privada de cifrado de la clave de API utilizando nonces para evitar ataques de repetición. En el próximo artículo veremos las implicaciones de seguridad de apoyo versiones del sistema operativo Android anteriores, así como la forma en que algunos teléfonos Android son más seguros que otros.

---

Sobre el Autor

Godfrey Nolan es el fundador y presidente de la empresa de telefonía móvil y el desarrollo web RIIS LLC con sede en Troy, Michigan, y Belfast, Northern Ireland.He ha tenido una obsesión saludable con código de bytes de ingeniería inversa. Ver más de él aquí. Él es también el autor de Bulletproof Android: Consejos prácticos para la creación de aplicaciones seguras.