iOS Trousseau de Sécurité

nous voulons utiliser des certificats sur l'iPhone pour authentifier pour MS Exchange de Synchronisation. Nous ne sommes pas sûr de savoir comment le concept de sécurité est mis en place pour protéger ces certificats.

par exemple, est-il possible d'obtenir le "plein" Trousseau d'accès sur l'iPhone si pas de ScreenLock est-il activé?
(ou avec un iPhone Jailbreaké).

Quelqu'un a des liens à ce sujet?

  • Cette question serait approprié à security.stackexchange.com
  • Encore, très pertinent pour nous tous iOS devs qui fréquente de Débordement de Pile. Peut-être que nous devrions tous nous visiter security.stackexchange.com de plus en plus fréquemment? 🙂
InformationsquelleAutor phx | 2010-08-24
  1. 47

    De Fraunhofer étude sur iOS trousseau de sécurité:

    De ce que je peux dire, il y a deux niveaux de cryptage que l'iOS trousseau utilise. Le premier niveau utilise l'écran de verrouillage code de mot de passe comme clé de chiffrement. Le deuxième niveau utilise une clé générée et stockée sur l'appareil.

    De Fraunhofer chercheurs ont compris comment contourner le deuxième niveau. C'est le "plus facile" à autour de, depuis la clé de chiffrement est stocké sur l'appareil. Donc sur iOS4, leur méthode ne fonctionne qu'avec le keychain entrées qui n'utilisent PAS kSecAttrAccessibleWhenUnlocked ou kSecAttrAccessibleWhenUnlockedThisdeviceonly, parce que ces entrées de résider dans la mémoire avec le premier niveau décrypté, même lorsque le téléphone est verrouillé.

    • À partir de l'iOS 4, avec les touches de kSecAttrAccessibleWhenUnlocked et kSecAttrAccessibleWhenUnlockedThisdeviceonly sont protégés par un niveau supplémentaire de chiffrement
    • Sur iOS 3.x et versions antérieures, toutes les touches peuvent être déchiffrées à l'aide de l'institut Fraunhofer de la méthode, indépendamment de l'accessibilité de l'attribut utilisé
    • Les périphériques sans mot de passe à tout va toujours être vulnérable
    • Appareils avec la faiblesse des mots de passe (à moins de six chiffres) sera toujours un peu vulnérables

    ≈50 ms par mot de passe de l'essayer; → ≈20 essais par seconde; → ≈1,7 ans de 50% de l'
    changement de deviner le bon mot de passe de 6 caractères alphanumériques
    code avec la base de 36. Le standard simple code de 4 chiffres seraient
    être brute forcé en moins de 9 minutes. Basé sur l'hypothèse que
    le compteur de mal essaie de l'iOS peut être ignoré, car il n'est pas
    basé sur le matériel

    Apple Inc. La WWDC 2010, le Noyau du système d'exploitation, Session 209 "la Sécurisation des Données de l'Application", Diapositive 24

    Bas de ligne:
    Si vous devez stocker des données sensibles, à mieux utiliser votre propre chiffrement. Et ne les stockez pas la touche sur l'appareil.

    Edit:
    Il existe de nombreux articles de presse qui citent le Fraunhofer étude et de rassurer ses lecteurs de ne pas s'inquiéter, à moins que leurs appareils sont volés, parce que cette attaque ne peut être fait avec un accès physique à l'appareil.

    Je suis douteuse. Le fait que les chercheurs n'ont leurs tests avec un accès physique au téléphone semble avoir été simplement un moyen de simplifier le problème, plutôt que d'une limitation. C'est leur description de ce qu'ils ont fait pour déchiffrer le trousseau des entrées:

    Après à l'aide d'un outil de jailbreak, pour avoir accès à un shell de commande, nous
    exécutez un petit script d'accès et de déchiffrer les mots de passe trouvés dans le
    un trousseau de clés. Le déchiffrement se fait à l'aide de fonctions
    par le système d'exploitation lui-même.

    Comme quelqu'un qui a utilisé le jailbreak.moi sait que, cette opération ne nécessite pas de physique l'accès à l'appareil. Théoriquement, il devrait être facile à modifier le jailbreak.me code et de le automatiser les suivantes:

    1. Effectuer le jailbreak comme normal (tout cela nécessite est pour l'utilisateur d'ouvrir un malveillant PDF)
    2. Exécution de Fraunhofer scripts après le jailbreak est terminé
    3. Envoyer les mots de passe sur le réseau à un emplacement à l'attaquant peut lire de

    Donc une fois de plus, être prudent sur ce que vous mettez dans le trousseau d'accès.

    • L'accès physique à l'appareil est nécessaire, car il y a une clé stockée quelque part sur la carte mère qui ne peut pas être ouvert ou lu par tous les moyens à tous. Cette clé est unique à chaque appareil iOS fabriqués, et cela signifie que seulement cette appareil est capable de décrypter les données du périphérique. Ainsi, l'accès physique est nécessaire pour déchiffrer, parce que vous avez fait à indiquer à l'appareil à déchiffrer lui-même. Le décryptage de l'appareil de toute autre façon est quasiment impossible (comme dans, attaque en force de prendre des milliards d'années). Cela ne s'applique pas pour les sauvegardes, qui sont cryptées sans le dispositif de clé
    • Je pense que vous avez mal compris le sens de l'accès physique. L'article de nouvelles liées dit "de L'attaque, qui exige la possession du téléphone...". Mais en fait, il n'y a aucune raison pourquoi une distance exploiter qui s'exécute sur le périphérique ne peut pas faire la même chose.
    • Un code à distance exploiter (peu probable sur un des correctifs de téléphone) s'exécute toujours dans les mêmes autorisations que les exploités application, et toutes les applications s'exécutent dans un bac à sable sans un accès en lecture aux fichiers à l'extérieur d'un répertoire unique, le système d'exploitation crée spécialement pour elle (vide par défaut). Pour un code à distance exploiter pour gagner de l'arbitraire du système de fichiers d'accès à un utilisateur qui a enraciné son téléphone (le point de l'ensemble de l'enracinement) ou une augmentation de privilèges exploiter. Encore une fois, si vous appliquez les patches que vous êtes assez fort. Deux exploits zero day est un étirement. Sans prison casser, seulement USB permet un plein accès au système de fichiers.
    • Vous avez raison à propos de la prison casser. Si vous prison break votre téléphone presque tous le noyau des fonctionnalités de sécurité sont à plat désactivé. Alors vous êtes de gauche avec la même sécurité que Mac OS X et Windows et (autant que je sache) Linux: n'importe quelle application sur votre système peut essayer de la force brutale votre trousseau de clés, et avec des produits typiques de mots de passe, il ne durera pas longtemps. Surtout sur un téléphone à 4 chiffres des codes d'accès sont communs.
    • Ce n'est pas vraiment un tronçon à tous--c'est exactement comment jailbreak.moi travaillé. Tout ce que l'utilisateur avait à faire était de visiter un site web pour commencer le processus de jailbreak. L'utilisateur n'a jamais eu de connecter son appareil à son ordinateur. Si je me souviens bien, il a effectivement fait usage de multiples exploits complètement la racine du téléphone. Mon point est que si vous visitez un site web peut jailbreaker votre téléphone, puis un site web malveillant peut à peu près faire ce qu'il veut.
    • Bien sûr, mais jailbreak.moi ne fonctionne pas de la dernière version d'iOS. Chaque fois qu'ils trouvent une faille de sécurité, apple ferme. Il ressemble JailBreak.moi qui n'a pas travaillé sur une version de iOS publié dans le dernier onze mois.
    • jailbreak.moi pour iOS 4 prouve que le concept de ce type d'attaque. Tout ce qu'il faut sont une nouvelle série d'exploits pour que ça arrive. Le fait que Apple patchs après le fait n'est pas vraiment pertinent.
    • Ce sujet de l'ajout d'une couche de chiffrement, pour être un peu plus en sécurité"? Disons que vous chiffrez vos données vous-même avant de les stocker sur le trousseau de clés. Et la " clé " utilisé dans votre adhoc algorithme ne peut pas être facilement trouvés dans le binaire...
    • Toute nouvelle information concernant les résultats et les futures versions de l'iOS (7 - 8) ?

    InformationsquelleAutor pepsi
  2. 4

    Normalement, le trousseau de clés serait le moyen recommandé pour stocker un tel certificat. Toutefois, il a été découvert que le jailbreak peut être utilisé pour contourner la sécurité du trousseau (l'article).

    • Ma compréhension est que seul trousseau d'éléments spécifiques à la classe de protection peuvent être obtenus avec la technique décrite. Ces classes sont kSecAttrAccessibleAlways et kSecAttrAccessibleAlwaysThisDeviceOnly. Voir forum.agile.ws/index.php?/topic/... pour le mo de détails.
    • Oui cet article confirme simplement que vous ne devez pas stocker les éléments sensibles avec l'attribut kSecAttrAccessibleAlways, voir developer.apple.com/library/ios/#DOCUMENTATION/Security/...
    InformationsquelleAutor Nick Toumpelis
  3. 3

    Franhofer a fait une étude sur la sécurité de l'iPhone Trousseau :

    http://www.sit.fraunhofer.de/Images/sc_iPhone%20Passwords_tcm501-80443.pdf

    InformationsquelleAutor aLt
  4. 2

    Je peux répondre à la partie de votre question, mais puisque l'autre partie est encore inconnue, je suis à droit de vote de la question comme je suis aussi impatients de connaître la réponse.

    La partie à laquelle je peux répondre est la suivante: "pouvez obtenir la pleine application trousseau d'accès si aucune screenlock est activé. Non, chaque application dispose de son propre trousseau de la zone sur l'iphone, ce qui signifie qu'une application ne peut accéder à ses propres secrets. Ces secrets ne sont pas verrouillés pour l'application elle-même, donc il n'y a aucun moyen de cacher le trousseau des entrées à partir de l'application elle-même. Donc, pour résumer: une application peut lire ses propres entrées, et pas d'autres entrées.

    Ce que je suis intéressé de savoir si c'est ce qui se passe sur les appareils jailbreaké. Sont des porte-clés de toutes les applications exposées une fois qu'un appareil a un jailbreak?

    InformationsquelleAutor Ivo Jansch