iOS Basics
Séparation des privilèges et bac à sable
Sur iOS, une distinction de privilèges existe entre les applications accessibles par l'utilisateur et les processus principaux du système. Les applications s'exécutent sous l'identité utilisateur mobile, tandis que les processus système cruciaux fonctionnent en tant que root. Cette séparation est renforcée par un mécanisme de bac à sable, qui impose des limitations strictes sur les actions que les applications peuvent entreprendre. Par exemple, même si les applications partagent la même identité utilisateur, elles sont interdites d'accéder ou de modifier les données des autres.
Les applications sont installées dans un répertoire spécifique (private/var/mobile/Applications/{ID aléatoire}) et ont un accès en lecture restreint à certaines zones et fonctionnalités système, telles que les SMS et les appels téléphoniques. L'accès aux zones protégées déclenche une demande de permission à l'utilisateur.
Protection des données
iOS propose aux développeurs les API de protection des données, construites sur le processeur Secure Enclave Processor (SEP) - un coprocesseur dédié aux opérations cryptographiques et à la gestion des clés. Le SEP garantit l'intégrité de la protection des données via une clé spécifique au périphérique, l'UID du périphérique, intégrée en son sein.
Lors de la création d'un fichier, une clé de chiffrement AES unique de 256 bits est générée, chiffrant le contenu du fichier. Cette clé de chiffrement, accompagnée d'un ID de classe, est ensuite chiffrée à l'aide d'une clé de classe et stockée dans les métadonnées du fichier. Le déchiffrement d'un fichier implique l'utilisation de la clé du système pour accéder aux métadonnées, récupérer la clé de classe avec l'ID de classe, puis déchiffrer la clé de chiffrement unique du fichier.
iOS définit quatre classes de protection pour la sécurité des données, qui déterminent quand et comment les données peuvent être accédées :
Protection complète (NSFileProtectionComplete) : Les données sont inaccessibles jusqu'à ce que le périphérique soit déverrouillé à l'aide du code d'accès de l'utilisateur.
Protégé sauf ouvert (NSFileProtectionCompleteUnlessOpen) : Permet l'accès au fichier même après le verrouillage du périphérique, à condition que le fichier ait été ouvert lorsque le périphérique était déverrouillé.
Protégé jusqu'à la première authentification de l'utilisateur (NSFileProtectionCompleteUntilFirstUserAuthentication) : Les données sont accessibles après le premier déverrouillage de l'utilisateur après le démarrage, restant accessibles même si le périphérique est à nouveau verrouillé.
Aucune protection (NSFileProtectionNone) : Les données ne sont protégées que par l'UID du périphérique, facilitant l'effacement rapide des données à distance.
Le chiffrement de toutes les classes, sauf NSFileProtectionNone, implique une clé dérivée à la fois de l'UID du périphérique et du code d'accès de l'utilisateur, garantissant que le déchiffrement n'est possible que sur le périphérique avec le bon code d'accès. À partir d'iOS 7, la classe de protection par défaut est "Protégé jusqu'à la première authentification de l'utilisateur".
Les développeurs peuvent utiliser FileDP, un outil pour inspecter la classe de protection des données des fichiers sur un iPhone.
Le trousseau
En iOS, un trousseau sert de conteneur sécurisé pour stocker des informations sensibles, accessible uniquement par l'application qui l'a stocké ou par des utilisateurs explicitement autorisés. Cette encryption est renforcée par un mot de passe unique généré par iOS, lui-même encrypté avec AES. Ce processus d'encryption utilise une fonction PBKDF2, combinant le code d'accès de l'utilisateur avec un sel dérivé de l'UID du dispositif, un composant auquel seul le chipset de l'enclave sécurisée peut accéder. Par conséquent, même si le code d'accès de l'utilisateur est connu, le contenu du trousseau reste inaccessible sur tout dispositif autre que celui où il a été initialement encrypté.
La gestion et l'accès aux données du trousseau sont gérés par le démon securityd, en fonction des autorisations spécifiques de l'application telles que Keychain-access-groups et application-identifier.
Opérations de l'API du trousseau
L'API du trousseau, détaillée dans la documentation des services de trousseau d'Apple, fournit des fonctions essentielles pour la gestion du stockage sécurisé :
SecItemAdd: Ajoute un nouvel élément au trousseau.SecItemUpdate: Met à jour un élément existant dans le trousseau.SecItemCopyMatching: Récupère un élément du trousseau.SecItemDelete: Supprime un élément du trousseau.
Le forçage du mot de passe du trousseau implique soit d'attaquer directement la clé encryptée, soit de tenter de deviner le code d'accès sur le dispositif lui-même, ce qui est considérablement entravé par l'application de l'enclave sécurisée d'un délai entre les tentatives infructueuses.
Configuration de la protection des données des éléments du trousseau
Les niveaux de protection des données des éléments du trousseau sont définis en utilisant l'attribut kSecAttrAccessible lors de la création ou de la mise à jour de l'élément. Ces niveaux, comme spécifié par Apple, déterminent quand et comment les éléments du trousseau sont accessibles :
kSecAttrAccessibleAlways: Accessible à tout moment, indépendamment de l'état de verrouillage du dispositif.kSecAttrAccessibleAlwaysThisDeviceOnly: Toujours accessible, mais non inclus dans les sauvegardes.kSecAttrAccessibleAfterFirstUnlock: Accessible après le premier déverrouillage post-redémarrage.kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly: Identique au précédent, mais non transférable vers de nouveaux dispositifs.kSecAttrAccessibleWhenUnlocked: Accessible uniquement lorsque le dispositif est déverrouillé.kSecAttrAccessibleWhenUnlockedThisDeviceOnly: Accessible lorsqu'il est déverrouillé, non inclus dans les sauvegardes.kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly: Nécessite le code d'accès du dispositif, non inclus dans les sauvegardes.
Les AccessControlFlags affinent davantage les méthodes d'accès, permettant l'authentification biométrique ou l'utilisation du code d'accès.
Avertissement concernant les dispositifs jailbreakés
Sur les dispositifs jailbreakés, les protections du trousseau sont compromises, représentant un risque de sécurité significatif.
Persistance des données du trousseau
Contrairement aux données spécifiques à une application supprimées lors de la désinstallation de l'application, les données du trousseau persistent sur le dispositif. Cette caractéristique pourrait permettre aux nouveaux propriétaires d'un dispositif d'occasion d'accéder aux données d'application de l'ancien propriétaire simplement en réinstallant les applications. Il est recommandé aux développeurs de supprimer proactivement les données du trousseau lors de l'installation de l'application ou lors de la déconnexion pour atténuer ce risque. Voici un exemple de code Swift démontrant comment effacer les données du trousseau lors du premier lancement de l'application :
Capacités de l'application
Dans le domaine du développement d'applications, le sandboxing joue un rôle crucial dans l'amélioration de la sécurité. Ce processus garantit que chaque application fonctionne dans son propre répertoire principal unique, l'empêchant ainsi d'accéder aux fichiers système ou aux données appartenant à d'autres applications. L'application de ces restrictions est effectuée à travers des politiques de sandbox, qui font partie du Cadre de contrôle d'accès obligatoire Trusted BSD (MAC).
Les développeurs ont la possibilité de configurer certaines capacités ou autorisations pour leurs applications, telles que la Protection des données ou le Partage du trousseau. Ces autorisations sont appliquées immédiatement après l'installation de l'application. Cependant, pour accéder à certaines ressources protégées, l'application doit obtenir le consentement explicite de l'utilisateur lors de la première tentative. Cela est réalisé grâce à l'utilisation de chaînes de but ou chaînes de description d'utilisation, qui sont présentées aux utilisateurs dans une alerte de demande d'autorisation.
Pour ceux qui ont accès au code source, la vérification des autorisations incluses dans le fichier Info.plist peut être effectuée en :
Ouvrant le projet dans Xcode.
Localisant et ouvrant le fichier
Info.plist.Recherchant les clés préfixées par
"Privacy -", avec l'option de visualiser les clés/valeurs bruts pour plus de clarté.
Lors du traitement d'un fichier IPA, les étapes suivantes peuvent être suivies :
Dézipper le fichier IPA.
Localiser le fichier
Info.plistdansPayload/<nomdelappli>.app/.Convertir le fichier au format XML si nécessaire, pour une inspection plus facile.
Par exemple, les chaînes de but dans le fichier Info.plist pourraient ressembler à ceci :
Capacités de l'appareil
Le fichier Info.plist d'une application spécifie les capacités de l'appareil qui aident l'App Store à filtrer les applications en fonction de la compatibilité de l'appareil. Celles-ci sont définies sous la clé UIRequiredDeviceCapabilities. Par exemple :
Cet exemple indique que l'application est compatible avec l'ensemble d'instructions armv7. Les développeurs peuvent également spécifier des capacités comme le NFC pour s'assurer que leur application n'est disponible que sur des appareils prenant en charge le NFC.
Autorisations
Les Autorisations sont un autre aspect critique du développement d'applications iOS, servant de paires clé-valeur qui accordent aux applications la permission d'effectuer certaines opérations au-delà des vérifications d'exécution. Par exemple, activer la Protection des données dans une application implique d'ajouter une autorisation spécifique dans le projet Xcode, qui est ensuite reflétée dans le fichier d'autorisations de l'application ou le fichier de provisionnement mobile intégré pour les IPAs.
Références
Last updated