¿Cómo puede un servidor autenticar una aplicación de iPhone (el código, no el usuario)?

Digamos que tengo una solución que involucra una aplicación de iPhone que genera cierta información y luego envía esa información a un servicio web para su procesamiento. Es importante que SOLO las solicitudes de las instancias de esta aplicación de iPhone en particular puedan procesarse (puede haber muchas instancias de la aplicación utilizadas por muchos usuarios diferentes, pero quiero estar seguro de que todas usan código en el que confío). En otras palabras, quiero asegurarme de que mi aplicación de iPhone no pueda ser (fácilmente) suplantada por otros clientes. ¿Cómo harías esto?¿Cómo puede un servidor autenticar una aplicación de iPhone (el código, no el usuario)?

Fuente

2010-03-18 Peter Baer

Sea más preciso sobre qué tipo de seguridad tiene en mente. ¿Desea inhibir las solicitudes de otros dispositivos (iPhone), otras aplicaciones (en el mismo dispositivo) o cualquier solicitud de dispositivos arbitrarios? –

Buen punto, he cambiado la pregunta para reflejar esto. Gracias. –

Todas las demás respuestas dan formas legítimas de proporcionar algo de seguridad adicional, pero no perfecta. Debe saber por adelantado (ya que nadie más ha sido tan explícito) que no es posible para 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 ejecutándose en hardware sancionado. No se puede hacer esto porque cualquiera sea la seguridad de nivel de hardware que Apple haya incorporado para iniciar una cadena de confianza (para que esto sea realmente posible), no se exponen a usted.

Su estrategia debe ser una de "muchas barreras", algunas más grandes, otras más pequeñas, diseñadas para frustrar diversos grados de complejidad de ataque y sofisticación del atacante. Vea otras respuestas a esta pregunta para algunas buenas ideas. Cuántas barreras necesita y de qué sofisticación depende completamente el costo para usted (económicamente, la confianza, lo que sea) de tener éxito en un ataque.

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 de otras personas para hacer eso es lo mismo para cada copia/instancia, entonces usted está en más problemas, porque las instrucciones/claves se pueden simplemente publicar en la web algun lado. Si puede encontrar una manera de hacer que cada copia/cliente sea única, entonces puede observar en el servidor y, en el peor, cortar clientes rotos conocidos, etc. (Esto es difícil en la plataforma de iPhone).

Fuente

2010-03-18 19:46:13

Puede ocultar una clave privada en su aplicación que se utiliza para challenge-response authentication.

Si esta respuesta es demasiado corta/abstracta, deja un comentario y te explicaré con más detalle.

Editar:

me gustaría añadir que yo no creo que haya una conexión segura (como a la inversa-Ingeniería-safe) manera de hacer la autenticación descrito. Pero en materia de seguridad me estoy equivocando más a menudo que nunca.

Fuente

2010-03-18 09:04:15

Esto todavía es bastante inseguro. No es difícil abrir un archivo .ipa y extraer recursos. –

Esa fue mi primera idea también: hacer que el servidor le diga al cliente un número X, que el cliente debe modificar en un segundo número Y usando un algoritmo conocido solo por el cliente y servidor Pero dado que la aplicación estaría públicamente disponible, cualquiera podría inspeccionar el código del cliente y aplicar ingeniería inversa al algoritmo ... (aunque, para mi aplicación, "la seguridad a través de la oscuridad" puede ser suficiente porque no valdría la pena que alguien vaya a través del esfuerzo de intentar revertir la ingeniería del código, estoy intentando evitar la falsificación trivial, pero tengo curiosidad por saber si hay un enfoque más sólido) –

Acepto que este enfoque es inseguro y especialmente vulnerable a la piratería de la aplicación cliente . Pero también creo que no hay forma de crear una autenticación realmente segura para este problema en particular. En mi opinión, ocultar una clave es lo mejor que uno puede hacer. –

Utilice su ID de dispositivo ... Enviar ID de dispositivo con la solicitud ... cada iPhone tendrá única ID de dispositivo

Fuente

2010-03-18 09:05:42

El UDID no es un secreto muy seguro para fines de autenticación. Es bueno para la identificación, pero no para la seguridad. –

Sí, lo sé, pero se menciona en la pregunta que "SOLAMENTE las solicitudes de esta aplicación de iPhone en particular pueden procesarse" ... en este caso UDID servirá para el propósito ... –

Lo siento, mi pregunta no era clara en eso - espero que la aplicación sea utilizada por muchos usuarios en muchos dispositivos (iPhone). No quiero restringir el servicio para ser utilizado por un solo dispositivo. He aclarado la pregunta. –

Cualquier comunicación saliente generado por su aplicación puede ser interceptada y se repite más adelante. Si deseaba estar razonablemente seguro de que su solicitud proviene de una solicitud, puede hacer cosas como insertar 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 no repudio (es decir, demostrar que solo el destinatario puede leer el mensaje, porque es el único con la mitad correspondiente del par de llaves).)

Lo que está 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 codificar un secreto en su aplicación no garantiza que sea un secreto), y luego usar ese secreto para realizar una manipulación específica de su mensaje (aunque esto todavía no es autenticidad perfecta).

O podría hacer algo como inspeccionar la firma del código de su aplicación y verificar que sea una firma apropiada y que sea su aplicación, o algo similar.

Quizás Graham Lee aparezca y dé una mejor respuesta. :)

EDITAR

(pensando en voz alta) He aquí una idea: Una vez que su aplicación está en la tienda, se puede extraer la firma de código de la aplicación para publicar, poner eso en su servidor, y el uso que en una respuesta desafío. Cuando su cliente se conecta al servidor, su servidor podría generar un valor aleatorio y enviarlo de regreso. 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, tu servidor podría estar haciendo lo mismo. Cuando el servidor obtiene el valor manipulado, puede compararlo con su versión y luego finalizar/continuar la conexión en función de si coinciden. Técnicamente, esto aún podría ser falso (otra aplicación podría robar la firma del código y usarlo ella misma), pero parece que sería más seguro.

Fuente

2010-03-18 17:53:26

No creo que ninguna de sus propuestas sea más segura que la de mi respuesta. Lo cual, ciertamente, no es seguro, también. –

Como el UDID, la firma del código es una mala elección para un secreto, ya que es un secreto bien conocido. –

@Nikolai cierto, por lo que prefijé con "(pensando en voz alta)". :) –

me hizo una pregunta similar hace un tiempo:

Restricting access to server to iPhone app

Lo que terminé haciendo es utilizando un nombre de usuario generada de forma aleatoria (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 la contraseña.

En el servidor tomo el nombre de usuario dado, añado el mismo secreto, hash it y lo comparo con lo que el cliente envió. Tenga en cuenta que esto debe enviarse a través de SSL para que sea remotamente seguro.

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 con ambos es que si su aplicación está rajada, es trivial extraer el secreto o el certificado del cliente.

Si su preocupación no se paga, los clientes que utilizan los recursos de su servidor tienen un problema completamente diferente, porque su principal modelo de amenaza son las copias piratas de su aplicación que se ejecuta en teléfonos liberados. Vea las respuestas a mi pregunta para algunas contramedidas.

Fuente

2010-03-18 17:56:09

El secreto podría ser fácilmente modificado y utilizado por otra persona, y tu certificado SSL también podría ser fácilmente extraído. –

Si con "ingeniería inversa" te refieres a "ejecutar cadenas de caracteres" en el archivo .ipa "descifrado", estás en lo cierto. Pero una vez que alguien ha descifrado su .ipa, la aplicación puede considerarse comprometida y todas las apuestas están desactivadas. –

o si lo ejecuta en un iphone con jailbreak, puede hacer cualquier cosa ya que tiene acceso a la raíz. –

Otra posibilidad es solicitar a la aplicación una parte del contenido del paquete de la aplicación, algo así como el byte 59967 del ejecutable de la aplicación, o un plist o xib incluidos. Al mantener el nombre de archivo y la posición solicitados de manera totalmente aleatoria, cualquier spoofing debe insertar una copia completa de la aplicación, lo que facilita la determinación de si están falsificando su aplicación y posiblemente sea muy fácil buscar citas en Google.

Básicamente, simplemente le pediría al cliente que le proporcione un número de versión, y en el servidor tendría copias de todos los archivos para todas las versiones públicas para comprobar las respuestas (y para decidir qué desafío enviar).

Dado que es imposible evitar esto, lo mejor es hacer que la detección de spoofing sea lo más fácil de escanear posible, así que pensaría en soluciones que lo ayuden en ese sentido, en lugar de tratar de bloquear lo no bloqueable (aunque algunos bloqueos iniciales triviales mantendrán a raya a los riffs).

Básicamente, más capas en lugar de una capa realmente dura son lo que desea para proteger algo.

Fuente

2010-03-19 03:50:36

Me gusta esta idea, pero no entiendo muy bien cómo esto "hace que sea muy fácil determinar si están falsificando su aplicación". Estoy de acuerdo en que la detección de spoofing es casi tan buena como la prevención en primer lugar (si sabes que puedes atraparte fácilmente, hay menos incentivo para hacerlo). Pero no estoy seguro de cómo este esquema ayuda a hacer eso. –

Más en la línea de, hace que sea fácil determinar si un producto en particular falsifica su aplicación, más de lo que las solicitudes individuales son falsificadas: si la aplicación de suplantación está en Internet, una búsqueda ocasional de Google de algunos de sus archivos debería ser capaz de encontrarlo No puede detectar un trabajo de falsificación realmente bueno, por lo que desea dificultar que alguien distribuya ampliamente algo que hace un buen trabajo falsificando sin que usted lo sepa. –

Cuando se inicia la aplicación, envíe una solicitud de token al servidor.Luego haga que el servidor envíe un token (solo una cadena secreta recién generada) al cliente a través de APNS. Todas las comunicaciones subsiguientes se autentican con ese token. Incluso puede persistir el token 'de forma segura' utilizando el lado del iPhone de Keychain. En el límite, lo que quieres es, de hecho, imposible, pero de esta manera dependes un poco más de las herramientas de Apple.

Fuente

2010-06-23 13:50:34 Colin

¿Cómo puede un servidor autenticar una aplicación de iPhone (el código, no el usuario)?

Respuesta

Cuestiones relacionadas