Génie civil & structural
Mise en œuvre du chiffrement des données pour le stockage sensible des données Ios
Table of Contents
Comprendre le chiffrement des données sur iOS
Au niveau matériel, l'Enclave Secure gère les clés de chiffrement et les opérations cryptographiques. Au niveau du système d'exploitation, ]La protection des données[ utilise le chiffrement au niveau des fichiers qui relie les clés de chiffrement au code passe de l'appareil. Pour les données spécifiques à l'application, les développeurs peuvent utiliser des cadres comme CryptoKit, CommonCrypto et le cadre de sécurité pour chiffrer des enregistrements, fichiers ou charges utiles réseau.
Le chiffrement convertit le texte clair en texte codé à l'aide d'un algorithme et d'une clé. Sans la bonne clé, les données restent illisibles. Apples iOS Data Protection API chiffre automatiquement les fichiers au repos, mais les développeurs ont besoin d'un chiffrement explicite pour les données stockées en dehors du système de fichiers protégés, comme dans les données de base, les fichiers d'utilisateur ou les caches personnalisés.
La clé à retenir : chiffre les données sensibles chaque fois qu'elles résident sur l'appareil, même si le chiffrement iOS est activé par défaut. Cela assure une protection contre l'accès physique à l'appareil, l'extraction médico-légale ou les applications malveillantes qui fonctionnent dans le même bac à sable.
Cadres de chiffrement et API iOS
Apple fournit plusieurs bibliothèques cryptographiques. Choisir la bonne dépend de la cible de déploiement et du niveau de contrôle requis.
CryptoKit – API Swift moderne
Introduit dans iOS 13, CryptoKit offre une interface Swift-native pour la cryptographie symétrique et asymétrique, le hachage et l'accord clé. Il utilise AES-GCM[ pour le chiffrement authentifié, qui protège la confidentialité et l'intégrité.
import CryptoKit
func encryptSensitiveData(_ plaintext: String, using key: SymmetricKey) throws -> Data {
let inputData = Data(plaintext.utf8)
let sealedBox = try AES.GCM.seal(inputData, using: key)
return sealedBox.combined
}
func decryptSensitiveData(_ encryptedData: Data, using key: SymmetricKey) throws -> String {
let sealedBox = try AES.GCM.SealedBox(combined: encryptedData)
let decryptedData = try AES.GCM.open(sealedBox, using: key)
return String(decoding: decryptedData, as: UTF8.self)
}
Conservez toujours le dans la chaîne-clés, non dans UserDefaults ou dans un fichier simple. Utilisez avec pour relier la clé à l'appareil et à la présence de l'utilisateur.
CommonCrypto – Flexibilité basée sur le C
Pour les applications qui supportent des versions iOS anciennes ou qui nécessitent des modes de chiffrement de blocs personnalisés (p. ex. CBC avec HMAC), CommonCrypto fournit des fonctions C de faible niveau. Il prend en charge AES, DES, 3DES et divers algorithmes de hachage.
#include <CommonCrypto/CommonCryptor.h>
- (NSData *)aes256Encrypt:(NSData *)plaintext withKey:(NSData *)key iv:(NSData *)iv {
size_t outLength;
NSMutableData *ciphertext = [NSMutableData dataWithLength:plaintext.length + kCCBlockSizeAES128];
CCCryptorStatus status = CCCrypt(kCCEncrypt, kCCAlgorithmAES, kCCOptionPKCS7Padding,
key.bytes, key.length, iv.bytes,
plaintext.bytes, plaintext.length,
ciphertext.mutableBytes, ciphertext.length,
&outLength);
if (status == kCCSuccess) {
ciphertext.length = outLength;
return ciphertext;
}
return nil;
}
Pour le chiffrement authentifié, la paire AES-CBC avec un HMAC séparé, ou le passage à AES-GCM via CryptoKit si possible.
Cadre de sécurité et porte-clés
Le cadre de sécurité fournit des services de porte-clés pour le stockage sécurisé des clés, certificats et mots de passe. Utilisez pour stocker les clés avec des contrôles d'accès stricts (par exemple, exiger la présence de l'utilisateur via biométrie).
Mise en œuvre du chiffrement pour différents types de données
Toutes les données ne nécessitent pas la même stratégie de chiffrement. Personnalisez l'approche pour savoir comment et où les données sont utilisées.
Chiffrement des données de base et des données par défaut de l'utilisateur
Les données de base sont des fichiers SQLite simples sauf cryptés. Pour les données de base, activez l'attribut NsFileProtectionType dans le fichier de stockage. Pour une granularité plus fine, chiffrez les attributs individuels ou les objets entiers avant d'enregistrer:
- Utiliser des attributs de données de base transformables avec un transformateur de valeur personnalisé qui chiffre/décrypte en lecture/écriture.
- Sérialisez l'ensemble de l'objet géré comme JSON, chiffrez-le et stockez le chiffrement dans un attribut binaire.
- Pour UserDefaults, ne jamais stocker les chaînes sensibles brutes ; chiffrer chaque valeur et stocker les données chiffrées.
Exemple de stockage de données chiffrées dans UserDefaults :
let key = SymmetricKey(size: .bits256)
let data = "user_ssn".data(using: .utf8)!
let sealedBox = try AES.GCM.seal(data, using: key)
UserDefaults.standard.set(sealedBox.combined, forKey: "encrypted_ssn")
UserDefaults.standard.synchronize()
Chiffrement des fichiers avec la protection des fichiers
iOS offre des classes de protection de niveau de fichier : , et . Définissez ces attributs lors de la création ou du déplacement de fichiers :
let fileURL = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first!.appendingPathComponent("data.bin")
try FileManager.default.setAttributes([.protectionKey: FileProtectionType.complete], ofItemAtPath: fileURL.path)
Combinez la protection des fichiers avec le chiffrement explicite si les données doivent rester protégées même lorsque l'appareil est déverrouillé. Par exemple, chiffrez le fichier avec une clé stockée dans la chaîne-clés et accessible seulement après l'authentification.
Chiffrement des données réseau (sécurité de la couche de transport)
Pour les connexions TCP personnalisées, utilisez avec TLS ou implémentez le pinning SSL pour empêcher les attaques man-in-the-middle. Chiffrez la charge utile à la couche d'application pour une défense supplémentaire en profondeur : même si TLS est compromise, les données restent protégées.
Pratiques exemplaires de gestion clés
Le chiffrement n'est que aussi fort que la gestion clé. Suivez ces lignes directrices pour maintenir la sécurité :
- Générer les clés à l'aide d'un générateur de nombres aléatoires sécurisés par cryptographie – Utiliser ou .
- Store touches exclusivement dans la porte-clés avec les attributs d'accessibilité appropriés: empêche la sauvegarde et relie la clé à l'appareil.
- Utiliser l'authentification biométrique ou le code de passe avant de récupérer la clé – avec force la vérification de l'utilisateur.
- Retate keys on a agenda or after a security event – Re-encrypter les données avec de nouvelles clés et supprimer les anciennes clés en toute sécurité.
- Ne pas utiliser de touches de code dur dans le code source ou les fichiers de configuration.
- Tirer le levier de l'enclave sécurisée pour la génération asymétrique de clés – les clés privées ne peuvent pas être exportées, empêchant l'exfiltration.
Pour les applications qui traitent des données hautement sensibles, envisagez d'utiliser un module de sécurité via des services réseau, bien que cela introduit la latence et nécessite une connectivité Internet.
Rotation et réencryptage des clés
Lorsqu'une clé est compromise ou après une période définie (par exemple tous les 90 jours), faites pivoter la clé. Cela implique de déchiffrer toutes les données avec l'ancienne clé, de générer une nouvelle clé et de ré-crypter.
- Conservez un identifiant de clé (par exemple UUID) à côté de chaque enregistrement chiffré.
- Conservez une cartographie des identifiants aux clés réelles dans la chaîne-clés (encryptée au repos).
- Pendant la rotation, ajoutez une nouvelle entrée sans re-crypter immédiatement toutes les données. Re-cryptez paresseusement lors de l'accès.
Considérations en matière de conformité et de réglementation
De nombreuses réglementations exigent le cryptage des données sensibles. GFR[ exige des mesures techniques appropriées, et le cryptage est une technique de pseudonymisation reconnue. HIPAA[ exige le cryptage de l'ePHI au repos et en transit. PCI DSS[ exige le cryptage des données du détenteur de carte.
Voir la documentation officielle d'Apple pour les dernières recommandations : CryptoKit Developer Guide, [Keychain Services et Protection de la vie privée des utilisateurs[. Pour des conseils à l'industrie, voir OWASP Mobile Security Testing Guide et NIST SP 800-175B – Cryptographie Standards.
Essais et validation
Après avoir mis en œuvre le chiffrement, vérifier qu'il fonctionne correctement:
- Écrire des tests d'unité qui chiffrent et décryptent les textes simples connus et affirment les sorties.
- Cas de bord de test : données vides, charges utiles très importantes et caractères codés corrompus.
- Effectuer des tests de sécurité à l'aide d'un appareil jailbroken pour simuler des scénarios d'attaque – vérifier que les clés restent inaccessibles sans authentification.
- Utilisez des outils d'analyse statique pour garantir qu'aucune clé codée en dur ou algorithme faible.
- Examiner les journaux – ne jamais enregistrer les données sensibles au texte simple ou les clés de chiffrement.
Conclusion
En combinant la protection des fichiers iOS, le cryptage de couches d'application avec CryptoKit ou CommonCrypto, et la gestion rigoureuse des clés via la chaîne-clés et l'enclave sécurisée, les développeurs peuvent réduire considérablement le risque d'exposition aux données. La conformité aux règlements comme le RGPD et le HIPAA nécessite des pratiques de cryptage documentées et vérifiables.