Comment garderiez-vous le secret des données secrètes dans une application iPhone?

Question

Disons que j'ai besoin d'accéder à un service web à partir d'une application iPhone. Ce service web exige des clients de signer numériquement des requêtes HTTP afin de prouver que l'application "sait" un secret partagé; une clé de client. La demande de signature est stockée dans un en-tête HTTP et la demande est tout simplement envoyé via HTTP (pas de HTTPS).

Cette clé doit rester secret à tout moment mais doit être utilisé par l'application pour iPhone.

Alors, comment voulez-vous stocker de manière sécurisée cette clé étant donné que vous avez toujours dit de ne jamais stocker des données sensibles sur le côté client?

L'utilisateur moyen (99% des utilisateurs) seront heureux de vous suffit d'utiliser l'application. Il y aura quelqu'un (un ennemi?) qui veut que le secret clé du client pour le service ou la clé du client propriétaire de mal par la voie de l'emprunt d'identité. Une telle personne peut jailbreaker son téléphone, l'accès aux binaires, exécutez "chaînes" ou d'un éditeur hexadécimal et fouiner. Donc, juste le stockage de la clé dans le code source est une idée terrible.

Une autre idée est de stocker la clé dans le code, pas une chaîne littérale, mais dans un NSMutableArray créé à partir de l'octet de littéraux.

On peut utiliser le Trousseau mais depuis une application iPhone n'a jamais à fournir un mot de passe pour stocker des choses dans le Trousseau d'accès, je suis circonspect sur le fait que quelqu'un ayant accès à l'application sandbox peut et sera en mesure de simplement regarder ou trivialement décoder les éléments qui y sont.

EDIT - j'ai donc lu ce sujet le Trousseau: "Dans l'iPhone OS, une application a toujours accès à son propre trousseau éléments et n'a pas accès à toute autre application des articles. Le système génère son propre mot de passe pour le trousseau d'accès, et les magasins de la touche de l'appareil de telle manière qu'il n'est pas accessible à toutes les applications."

Donc, c'est peut-être le meilleur endroit pour stocker la clé.... Si oui, comment puis-je expédier avec la clé pré-entré dans l'application trousseau? Est-ce possible? Sinon, comment pourriez-vous ajouter la clé au premier lancement sans la clé dans le code source? Hmm..

EDIT - Déposé de rapport de bug # 6584858 à http://bugreport.apple.com

Merci.

Answer 1

L'objectif est, à terme, de limiter l'accès du service web pour les utilisateurs autorisés, à droite? Très facile si vous contrôlez le service web (si vous n'en avez pas, de l'envelopper dans un service web qui vous ne contrôle).

1) Créer une paire clé publique/privée. La clé privée qui se passe sur le serveur de service web, qui est mis dans un donjon gardé par un dragon. La clé publique qui se passe sur le téléphone. Si quelqu'un est capable de lire la clé publique, ce n'est pas un problème.

2) demandez à chaque exemplaire de la demande de générer un identifiant unique. Comment vous faites cela est à vous. Par exemple, vous pourrait-il établir dans l'exécutable sur le téléchargement (est-ce possible pour les applications iPhone)? Vous pouvez utiliser le téléphone du GUID, en supposant qu'ils ont un moyen de calculer un. Vous pouvez également refaire cette par session si vous avez vraiment voulu.

3) Utiliser la clé publique pour chiffrer "Mon identifiant unique est $FOO et j'approuve ce message". Soumettre qu'à chaque requête pour le service web.

4) Le service web décrypte chaque demande, de rebondir qui ne contiennent pas un identificateur valide. Vous pouvez faire autant ou aussi peu de travail que vous voulez ici: gardez une liste blanche/liste noire, surveiller l'utilisation par l'identificateur de base et enquêter sur les cas de comportement suspect, etc.

5) Depuis l'identificateur unique de maintenant ne sera jamais envoyé sur le fil, la seule façon de compromis, c'est d'avoir un accès physique au téléphone. Si ils ont un accès physique au téléphone, vous perdez le contrôle de toutes les données de n'importe où sur le téléphone. Toujours. Ne peut pas être aidé. C'est pourquoi nous avons conçu le système de compromettre le téléphone ne fait jamais de compromis plus d'un compte.

6) Construire des processus d'affaires pour répondre à la nécessité a) de supprimer l'accès d'un utilisateur qui est en abuser et b) restaurer l'accès à un utilisateur dont le téléphone a été physiquement compromis (cela va être très, très rare, à moins que l'utilisateur est l'adversaire).

Answer 2

La réponse est simple, aujourd'hui c'est juste pas possible de garder des secrets sur l'iPhone. Un iPhone jailbreaké est juste un ordinateur à usage général qui tient dans votre main. Il n'y a pas de plate-forme sécurisée de matériel que vous pouvez accéder. L'utilisateur peut usurper tout ce que vous pouvez imaginer utiliser pour identifier de manière unique un périphérique donné. L'utilisateur peut injecter du code dans votre processus de faire des choses comme inspecter le trousseau de clés. (Recherche de MobileSubstrate pour voir ce que je veux dire.) Désolé, vous êtes foutu.

Un rayon de lumière dans cette situation est d'achat in-app reçus. Si vous vendez un article dans votre application via achat in-app vous obtenez un accusé de réception que la crypto signé et peut être vérifié avec Apple sur demande. Même si vous ne pouvez pas garder le reçu secret, il peut être tracé (par Apple, pas vous) à un achat spécifique, qui pourrait dissuader les pirates de les partager. Vous pouvez également accélérateur d'accès à votre serveur par la réception pour éviter que les ressources de votre serveur d'être drainé par des pirates.

Answer 3

Si vous pouvez supporter d'être uniquement sur iPhone OS 3.0, vous pouvez consulter les notifications push. Je ne peux pas entrer dans les détails, mais vous pouvez fournir une charge utile aux serveurs Apple avec la notification elle-même. Lorsqu'ils acceptent l'alerte (ou si votre application est en cours d'exécution), une partie de votre code est appelée et l'élément de trousseau est stocké. À ce stade, c’est le seul moyen de stocker en toute sécurité un secret sur un iPhone auquel je puisse penser.

Answer 4

J'ai eu la même question, et passé beaucoup de temps à fouiller pour une réponse. La question est la poule et de l'œuf: combien de pré-poluate le trousseau de clés avec des données nécessaires à votre application.

En tout cas, j'ai trouvé une technique qu'au moins, il sera plus difficile pour un jailbreaker pour découvrir les informations qu'ils vont au moins avoir à démonter votre code pour trouver ce que vous avez fait pour masquer l'info:

Chaîne De La Dissimulation De L'

Essentiellement, la chaîne est obscurci avant d'être mis dans l'application, puis vous unobfuscate à l'aide de code.

Ses mieux que de ne rien faire.

David

Answer 5

Je pense que cette même question, et ma réponse, peuvent être pertinents à votre cas aussi. En un mot, il y a certains parlent d'un module de plateforme sécurisée d'être présent dans un iPhone. Cela permettra à votre service pour faire confiance à un iPhone, même dans les mains d'un pirate. Cependant, il semble à l'aide du trousseau est votre meilleur pari.