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).