Aller au contenu

Index

Aucune donnée sensible stockée en dehors de l'application

Description

Afin de garantir le stockage approprié des données sensibles, comme les identifiants utilisateur, les jetons de session et les PII, les données sensibles ne doivent pas être stockées en dehors du conteneur de l'application ou du stockage d'identifiants du système.

Les données sensibles peuvent être exposées par le biais de mécanismes IPC non sécurisés ou divulguées par inadvertance vers le stockage cloud, les sauvegardes ou le cache du clavier. Par conséquent, le risque de perte ou de vol de l'appareil mobile doit tenir compte des scénarios d'accès physique.

Recommandation

iOS

Sur iOS, les développeurs peuvent s'appuyer sur l'API de protection des données d'iOS pour protéger les données sensibles. L'API s'appuie sur le Secure Enclave Processor (SEP) pour fournir un traitement cryptographique et une gestion des clés sécurisés.

Les fichiers peuvent se voir attribuer une classe de protection qui offre différents niveaux de protection :

  • Protection complète (NSFileProtectionComplete) : Une clé dérivée du code d'accès de l'utilisateur et de l'UID de l'appareil protège cette clé de classe. La clé dérivée est effacée de la mémoire peu de temps après le verrouillage de l'appareil, rendant les données inaccessibles jusqu'à ce que l'utilisateur déverrouille l'appareil.

  • Protégé sauf si ouvert (NSFileProtectionCompleteUnlessOpen) : Cette classe de protection est similaire à la protection complète, mais si le fichier est ouvert lors du déverrouillage, l'application peut continuer à accéder au fichier même si l'utilisateur verrouille l'appareil. Cette classe de protection est utilisée lorsque, par exemple, une pièce jointe de courrier électronique est en cours de téléchargement en arrière-plan.

  • Protégé jusqu'à la première authentification de l'utilisateur (NSFileProtectionCompleteUntilFirstUserAuthentication) : Le fichier est accessible dès que l'utilisateur déverrouille l'appareil pour la première fois après le démarrage. Il reste accessible même si l'utilisateur verrouille ensuite l'appareil et que la clé de classe n'est pas supprimée de la mémoire.

  • Aucune protection (NSFileProtectionNone) : La clé pour cette classe de protection est protégée uniquement par l'UID. La clé de classe est stockée dans un "Effaceable Storage" (stockage effaçable), qui est une zone de la mémoire flash sur l'appareil iOS permettant le stockage de petites quantités de données. Cette classe de protection existe pour l'effacement à distance rapide (suppression immédiate de la clé de classe, ce qui rend les données inaccessibles).

Toutes les clés de classe à l'exception de NSFileProtectionNone sont cryptées avec une clé dérivée de l'UID de l'appareil et du code d'accès de l'utilisateur. Par conséquent, le déchiffrement ne peut avoir lieu que sur l'appareil lui-même et nécessite le code d'accès correct.

Depuis iOS 7, la classe de protection des données par défaut est "Protégé jusqu'à la première authentification de l'utilisateur".

Le Keychain (trousseau d'accès) peut également stocker de petites quantités de données, comme des clés de chiffrement et des jetons de session. L'accès au Keychain s'effectue à l'aide d'une API personnalisée telle que :

  • SecItemAdd
  • SecItemUpdate
  • SecItemCopyMatching
  • SecItemDelete

Les données stockées dans le Keychain sont protégées via une structure de classe similaire à celle utilisée pour le chiffrement de fichiers. Les éléments ajoutés au Keychain sont codés sous forme de plist binaire et cryptés avec une clé AES 128 bits par élément en mode Galois/Counter Mode (GCM). Notez que les blocs de données plus importants ne sont pas destinés à être enregistrés directement dans le Keychain - c'est l'objectif de l'API de protection des données. Vous pouvez configurer la protection des données pour les éléments du Keychain en définissant la clé kSecAttrAccessible lors de l'appel à SecItemAdd ou SecItemUpdate. Les valeurs d'accessibilité configurables pour kSecAttrAccessible suivantes sont les classes de protection des données du Keychain :

  • kSecAttrAccessibleAlways : Les données de l'élément Keychain sont toujours accessibles, que l'appareil soit verrouillé ou non.
  • kSecAttrAccessibleAlwaysThisDeviceOnly : Les données de l'élément Keychain sont toujours accessibles, que l'appareil soit verrouillé ou non. Les données ne seront pas incluses dans une sauvegarde iCloud ou locale.
  • kSecAttrAccessibleAfterFirstUnlock : Les données de l'élément Keychain ne sont pas accessibles après un redémarrage jusqu'à ce que l'utilisateur ait déverrouillé l'appareil.
  • kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly : Les données de l'élément Keychain ne sont pas accessibles après un redémarrage tant que l'appareil n'a pas été déverrouillé une fois par l'utilisateur. Les éléments avec cet attribut ne migrent pas vers un nouvel appareil. Ainsi, ces éléments ne seront pas présents après une restauration à partir d'une sauvegarde d'un appareil différent.
  • kSecAttrAccessibleWhenUnlocked : Les données de l'élément Keychain sont accessibles uniquement lorsque l'utilisateur déverrouille l'appareil.
  • kSecAttrAccessibleWhenUnlockedThisDeviceOnly : Les données de l'élément Keychain sont accessibles uniquement lorsque l'utilisateur déverrouille l'appareil. Les données ne seront pas incluses dans une sauvegarde iCloud ou locale.
  • kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly : Les données du Keychain ne sont accessibles que lorsque l'appareil est déverrouillé. Cette classe de protection n'est disponible que si un code d'accès est configuré sur l'appareil. Les données ne seront pas incluses dans une sauvegarde iCloud ou locale.

AccessControlFlags définissent les mécanismes avec lesquels les utilisateurs peuvent authentifier la clé (SecAccessControlCreateFlags) :

  • kSecAccessControlDevicePasscode : Accéder à l'élément via un code d'accès.
  • kSecAccessControlBiometryAny : Accéder à l'élément via l'une des empreintes digitales enregistrées dans Touch ID. L'ajout ou la suppression d'une empreinte digitale n'invalidera pas l'élément.
  • kSecAccessControlBiometryCurrentSet : Accéder à l'élément via l'une des empreintes digitales enregistrées dans Touch ID. L'ajout ou la suppression d'une empreinte digitale invalidera l'élément.
  • kSecAccessControlUserPresence : Accéder à l'élément via l'une des empreintes digitales enregistrées (à l'aide de Touch ID) ou par défaut via le code d'accès.

Android

Sur Android, les développeurs peuvent exploiter plusieurs capacités pour stocker des données, comme les Shared Preferences, SQLite, le stockage interne et externe, mais peuvent également divulguer des données via des mécanismes tels que la journalisation (logging), les sauvegardes, le cache...

Les Shared Preferences (préférences partagées) sont une API couramment utilisée pour le stockage de données qui peut être déclarée avec des autorisations lisibles par tous (world-readable). Une utilisation non sécurisée de l'API Shared Preferences peut exposer des données.

SQLite est une autre forme courante de stockage de données et n'est pas cryptée. Les développeurs doivent privilégier des alternatives chiffrées comme SQLCipher qui offrent une meilleure confidentialité des données.

Le stockage interne est conteneurisé par défaut et ne peut pas être consulté par d'autres applications sur l'appareil. Il est cependant possible de définir les modes non sécurisés MODE_WORLD_READABLE et MODE_WORLD_WRITEABLE, qui sont tous deux obsolètes.

Le stockage externe est lisible par tous et ne doit pas être utilisé pour stocker des données sensibles. Il est important de noter que les données stockées en dehors du conteneur de l'application /data/data/<package-name> ne seront pas supprimées lors de la désinstallation de l'application.

Android KeyStore et KeyChain fournissent un stockage de données sécurisé. KeyStore utilise une clé publique pour créer un secret de chiffrement afin de crypter les données. KeyChain est utilisé pour stocker les clés privées à l'échelle du système et nécessitera que l'utilisateur configure un code PIN ou un mot de passe.

Liens

Normes

  • HIPAA_CONTROLS:
    • SECURITY251
    • SECURITY212
    • SECURITY213