tutuapp - ¿Cómo puede un servidor autenticar una aplicación de iPhone(el código, no el usuario)?
no se pudo verificar la app tutuapp (7)
Cualquier comunicación saliente generada por su aplicación puede interceptarse y reproducirse más tarde. Si desea estar razonablemente seguro de que una solicitud proviene de su aplicación, puede hacer cosas como incrustar claves públicas (no privadas) en su aplicación y usarla para firmar su comunicación. Sin embargo, en una situación como esta, las claves privadas y públicas no hacen nada, excepto proporcionar un no repudio (es decir, probar que solo el destinatario puede leer el mensaje, porque son los únicos con la mitad correspondiente del par de llaves). ).
Lo que estás buscando es proporcionar autenticidad. Podría hacer algo como realizar un intercambio de claves DH ( http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange ) para generar un secreto compartido (ya que al codificar un secreto en su aplicación no se garantiza que sea un secreto), luego usa ese secreto para realizar una manipulación específica en tu mensaje (aunque esto todavía no es la autenticidad perfecta).
O puede hacer algo como inspeccionar la firma del código de su aplicación y verificar que es una firma apropiada y que es su aplicación, o algo similar.
Tal vez Graham Lee aparecerá y dará una mejor respuesta. :)
EDITAR
(pensando en voz alta) Esta es una idea: una vez que su aplicación esté en la tienda, puede extraer la firma del código de la aplicación de publicación, colocarla en su servidor y usarla en una respuesta de desafío. Cuando su cliente se conecta al servidor, su servidor podría generar un valor aleatorio y enviarlo de vuelta. El cliente podría manipular ese valor utilizando la firma de código incorporada de la aplicación y devolver el valor manipulado. Mientras tanto, su servidor podría estar haciendo lo mismo. Cuando el servidor obtiene el valor manipulado, podría compararlo con su versión y luego finalizar / continuar la conexión según si coinciden. Técnicamente, esto todavía podría ser falsificado (otra aplicación podría robar la firma del código y usarlo en sí misma), pero parece que sería más seguro.
Digamos que tengo una solución que involucra una aplicación de iPhone que genera cierta información y luego la envía a un servicio web para su procesamiento. Es importante que SOLAMENTE se puedan procesar las solicitudes de instancias de esta aplicación de iPhone en particular (puede haber muchas instancias de la aplicación utilizadas por muchos usuarios diferentes, pero quiero estar seguro de que están usando un código en el que confío) En otras palabras, quiero asegurarme de que la aplicación de mi iPhone no pueda ser suplantada (fácilmente) por otros clientes. ¿Cómo harías esto?
Cuando se inicie la aplicación, envíe una solicitud de token al servidor. Luego, haga que el servidor envíe un token (solo una secuencia secreta recién generada) al cliente a través de APNS. Toda la comunicación subsiguiente se autentica con ese token. Incluso puede conservar el token "de forma segura" con el lado del llavero para iPhone. En el límite lo que quieres es, de hecho, imposible, pero de esta manera confías un poco más en las herramientas de Apple.
Hace un tiempo hice una pregunta similar:
Restricción del acceso al servidor a la aplicación de iPhone
Lo que terminé haciendo es usar un nombre de usuario generado aleatoriamente (GUID). Luego tomo el nombre de usuario, agrego un secreto (codificado en mi aplicación, reflejado en el servidor), y SHA1 el resultado, y lo envío como contraseña.
En el servidor tomo el nombre de usuario dado, agrego el mismo secreto, lo hash y lo comparo con lo que el cliente envió. Tenga en cuenta que esto debe enviarse a través de SSL para que sea incluso de forma remota.
Otro enfoque sería enviar un certificado de cliente SSL con su paquete de aplicaciones y configurar su servidor para que solo acepte conexiones de clientes con ese certificado.
La debilidad de ambos es que si su aplicación está dañada, es trivial extraer el secreto o el certificado del cliente.
Si su preocupación es que los clientes no pagados están utilizando los recursos de su servidor, tiene un problema totalmente diferente, porque entonces su modelo de amenaza principal son las copias piratas de su aplicación que se ejecutan en teléfonos con jailbreak. Vea las respuestas a mi pregunta para algunas contramedidas.
Otra posibilidad es pedir a la aplicación una parte del contenido del paquete de la aplicación, algo como el byte 59967 del ejecutable de la aplicación, o un plist o xib incluido. Al mantener tanto el nombre del archivo como la posición solicitada totalmente aleatoria, cualquier persona que falsifique información debe incrustar una copia completa de su aplicación, lo que hace que sea muy fácil determinar si están falsificando su aplicación y, posiblemente, muy fácil de buscar en Google.
Básicamente, el cliente le dará un número de versión, y en el servidor tendrá copias de todos los archivos para todas las versiones públicas para verificar las respuestas (y para decidir qué desafío enviar).
Ya que es imposible prevenir esto, lo mejor es hacer que la detección de falsificaciones sea lo más fácil de escanear posible, por lo que pienso en soluciones que lo ayuden en ese sentido en lugar de intentar bloquear lo que no se puede bloquear (aunque algunos triviales). el bloqueo inicial mantendrá fuera el riff-raff).
Básicamente, más capas en lugar de una capa realmente dura son lo que usted quiere para asegurar algo.
Puede ocultar una clave privada en su aplicación que se utiliza para una autenticación de respuesta-desafío .
Si esta respuesta es demasiado breve / abstracta, deje un comentario y lo explicaré con más detalle.
Editar:
Me gustaría agregar que no creo que haya una forma segura (como en ingeniería de ingeniería inversa) para hacer la autenticación descrita. Pero en cuestiones de seguridad me estoy equivocando más a menudo que nunca.
Todas las demás respuestas brindan formas legítimas de brindar seguridad adicional, pero no perfecta. Debe saber por adelantado (ya que nadie más ha sido tan explícito) que no es posible proporcionar comunicaciones teóricamente seguras, de modo que su servidor siempre pueda validar que el cliente en el otro extremo es una copia comprada de su aplicación que se ejecuta en hardware autorizado. . No puedes hacer esto porque cualquiera que sea el nivel de seguridad de hardware que Apple haya incorporado para iniciar una cadena de confianza (para que esto sea realmente posible para ellos), no te lo exponen.
Por lo tanto, su estrategia debería ser una de "muchas barreras", algunas más grandes, otras más pequeñas, diseñadas para frustrar los diversos grados de complejidad de ataque y la sofisticación del atacante. Vea otras respuestas a esta pregunta para algunas buenas ideas. La cantidad de barreras que necesita, y la complejidad de las mismas, depende completamente del costo para usted (económicamente, confianza, lo que sea) de tener un ataque exitoso.
Considere también la idea de que si puede evitar un ataque de seguridad "reproducible", estará mejor. En otras palabras, si alguien rompe su aplicación / protocolo, y los datos para que otras personas hagan eso son los mismos para cada copia / instancia, entonces tendrá más problemas, ya que las instrucciones / claves se pueden publicar en la web. algun lado. Si puede encontrar una manera de hacer que cada copia / cliente sea único, entonces puede observar en el servidor y, en el peor de los casos, eliminar clientes con problemas conocidos, etc. (Esto es difícil para la plataforma del iPhone).
Use su Id. De dispositivo ... Enviar Id. De dispositivo con la solicitud ... cada iPhone tendrá una Id. De dispositivo única