Cifrar datos dentro de la aplicación móvil y enviarlos al servicio web

13

Estoy desarrollando una aplicación móvil para Android e iOs. ¿Cuál es la mejor práctica cuando se trata del cifrado de datos dentro de la aplicación móvil que se enviará a un servicio web?

Básicamente generaré una cadena que consta de algunos parámetros como GPS y tiempo. Esta cadena debe cifrarse y luego pasarse a un servicio web.

He considerado hacerlo con encriptación asimétrica. Cifre la cadena con la clave pública (que tiene que estar codificada) y descifre con la clave privada. Debido a que cada aplicación se puede realizar ingeniería inversa, esto no es seguro en absoluto. Después de encontrar la clave pública codificada y la función de generación de cadenas, es fácil falsificar lo que quieras.

Cualquier entrada es muy apreciada.

EDITAR: un enfoque más claro de mi pregunta: una función de mi aplicación generará una cadena y otra función cifrará esta cadena, que se enviará a un servidor. ¿Cómo puedo evitar que una cadena auto-elaborada se pase a la función de encriptación después de aplicar ingeniería inversa a mi aplicación? En otras palabras, ¿puedo garantizar con una técnica de encriptación que los datos enviados por mi aplicación móvil a un servidor no sean creados por otra persona?

    
pregunta niklr 17.02.2013 - 00:01
fuente

3 respuestas

20

No puedes. Este es un principio fundamental de la computación de propósito general.

Te estás topando con la máxima de Shannon:

  

El enemigo conoce el sistema. Uno debe diseñar sistemas bajo el supuesto de que el enemigo se familiarice de inmediato con ellos.

Solo para aclarar mi punto de vista: le está dando un auto a alguien y le está pidiendo que solo conduzca a un lugar en particular. Nada les impide decidir ir a otro lugar, confía en que se adhieran a su solicitud.

Si su mecanismo de seguridad depende de la esperanza de que alguien no mire su ejecutable y descubra su método de cifrado / claves incrustadas, entonces no es un mecanismo de seguridad; Es un mecanismo de oscuridad.

Por lo que puedo decir, usted está tratando de hacer cumplir que los usuarios están dentro de un área específica a través de las coordenadas del GPS, y también quiere asegurarse de que no falsifiquen esas coordenadas. Esto no se puede hacer en una plataforma informática de propósito general, como un teléfono inteligente. Veamos la pila de tecnología:

  • Su aplicación web se encuentra en "la nube" en algún lugar. Usted controla esto completamente.
  • Su aplicación se encuentra en un teléfono. Usted tiene un control mínimo sobre esto, en su caso. Los posibles vectores de ataque incluyen ingeniería inversa, modificación de aplicaciones, solicitudes directas de aplicaciones web, edición de memoria, etc.
  • El sistema operativo del teléfono inteligente (por ejemplo, Android o iOS) se ejecuta en el dispositivo. No tienes control sobre esto. Este es el responsable de comunicarse con el dispositivo GPS y traducir los datos en coordenadas utilizables. Los posibles vectores de ataque incluyen: coordenadas de GPS falsas a través del panel de prueba (la mayoría de los teléfonos tienen esta función), controlador de GPS modificado, API de GPS enganchadas, etc.
  • El módulo GPS está dentro del dispositivo. No tienes control sobre esto. El módulo GPS es responsable de la comunicación con los satélites GPS y la transmisión de los datos a la CPU a través de un bus estándar. Los posibles vectores de ataque incluyen: el hombre en el medio del bus, el reemplazo del módulo GPS falso, la señal de satélite GPS falsa de la radio definida por software, etc.

Por lo tanto, no puede hacer que las coordenadas GPS que recibe en su aplicación web sean correctas, ya que podrían haber sido alteradas en el nivel de la aplicación, el nivel del sistema operativo, el nivel de hardware o incluso el GPS. nivel de señal. O bien, a excepción de todo eso, ¡alguien podría omitir el teléfono por completo y enviar manualmente las solicitudes a su aplicación web que contenga datos falsos!

La solución es aceptar el riesgo o cambiar su modelo de seguridad.

    
respondido por el Polynomial 17.02.2013 - 13:10
fuente
4

Siempre debes usar SSL.

SSL tiene una clave pública incorporada, y proporciona "autenticación", lo que significa que garantiza que el servidor con el que se está comunicando sea en realidad el servicio web que desea, y no algún impostor.

Dado que no indica lo contrario, o cualquier otra necesidad que tenga, creo que SSL resolverá todas sus inquietudes sobre el envío de datos a un servidor y su protección en tránsito.

Actualizar

Según sus requisitos actualizados en los comentarios, entiendo que desea evitar la falsificación de los datos GPS enviados a su servicio web.

Si no tiene control sobre el dispositivo (administrativo o de otro tipo), lo que dice @Polynomial es correcto. Si está creando un sistema cerrado, integrado o está en una corporación, puede tener más opciones.

Suponga que tiene control total de cada teléfono en el que se ejecutará su aplicación. Eso significa bloquear el teléfono, mantener el control exclusivo de la contraseña de administrador y nunca dárselo a los usuarios finales.

A continuación, puede asignar a cada dispositivo una clave única para cifrar los datos que se enviarán a un servicio web.

Si un teléfono determinado está comprometido, podrás determinar en qué dispositivo se basó en la clave utilizada.

    
respondido por el random65537 17.02.2013 - 00:49
fuente
4

La mejor práctica depende del uso exacto.

Lo que deduzco de tu pregunta es que tienes una aplicación que te envía datos y tiempo de GPS, como una aplicación de "huella". Desea asegurarse de que no se le están suministrando datos falsos, por lo que desea asegurarse de que los datos provengan de su cliente real y no sean falsos.

Bueno, desafortunadamente, como han dicho otras respuestas, eso es imposible. Dado el archivo APK para su aplicación, alguien puede descompilarlo en el código fuente de Java, posiblemente no tan elegante como su propia fuente, pero definitivamente viable. Luego, pueden usar su código para crear su propia aplicación, que se comunica con la suya exactamente de la forma que usted espera, y usarla para proporcionarle datos falsos.

Por lo tanto, cualquier esquema que utilice para el transporte de datos nunca debe confiar en el cliente. En su lugar, debe confiar en el usuario .

Considera esta solución; su servidor de aplicaciones está firmado con un certificado de clave pública de confianza (en este caso, se podría confiar por la única razón de que su aplicación conoce el certificado exacto que se debe otorgar; esto se denomina "certificado pinning "y funciona si obtuvo el certificado firmado por una CA global o no). Previa solicitud, presenta este certificado a quien lo solicite; Es información pública, podría pegar esto en cada foro de hackers en Internet y no sería menos seguro. Su cliente utiliza este certificado para negociar un túnel de comunicaciones seguro; Esto es algo bastante estándar.

Ahora, tienes confidencialidad . Necesita autenticidad ; no importa que nadie más pueda escuchar la conversación entre ustedes dos si no está seguro de quién está al otro lado. Entonces, una vez que el canal está abierto, lo siguiente que espera es una solicitud de autenticación que contenga credenciales de usuario. Debe rechazar cualquier solicitud para enviar datos GPS si la sesión no ha sido autenticada. Las credenciales que proporciona el usuario en dicha solicitud podrían ser su nombre de usuario y contraseña, el IMEI o la dirección MAC de su teléfono, el código de 10 dígitos de un llavero criptográfico, lo que crea que sea necesario para garantizar que solo un usuario en particular podría proporcionar esas credenciales.

Una vez que tenga esas credenciales y haya verificado que coinciden con las expectativas, sin embargo, si quiere hacerlo, envíe un "token de autenticación". Esto es tan simple como un número aleatorio distinto del utilizado para cualquier otra sesión abierta. Un V4 GUID es también una buena elección. Este identificador será requerido como parte de cualquier solicitud para enviar o recibir datos en este canal durante esta sesión, se aceptará solo en este canal en particular, y solo siempre que ya que esta sesión única está abierta.

Una vez configurado todo esto, generalmente se puede confiar en cualquier llamada de servicio que se realizó a través del canal seguro de esa sesión que incluye el token de autenticación correcto. Probablemente debería incluir una cosa más, que es una medida para protegerse contra los ataques de repetición. Un atacante no tiene que saber exactamente qué se envía de un lado a otro para desordenarte simplemente repitiendo lo que ya se ha dicho. Por lo tanto, para asegurarse de que su sistema solo maneje un mensaje único una vez, sin importar cuántas veces se envíe, cada mensaje debe incluir un nonce , un valor único que se usa una sola vez. Un simple valor de contador de secuencia, que forma parte de la estructura de solicitud y está cifrado por el canal seguro, debería ser suficiente para esto; entonces, todo lo que tiene que hacer es ignorar cualquier mensaje cuyo número de secuencia no sea el siguiente que espera recibir del cliente (puede haber alguna tolerancia a fallos inherente a esto, pero nunca acepta lo mismo tipo de solicitud de servicio del mismo cliente con el mismo número de secuencia dos veces).

    
respondido por el KeithS 18.02.2013 - 22:14
fuente

Lea otras preguntas en las etiquetas