Core Data et sécurité
Hello,
Je dois chiffrer "crypter" les données locales de mon application. J'ai comme contrainte d'associer le mot de passe de l'application ( l'application aura un mot de passe au lancement ) à la clé de chiffrement.
J'ai plusieurs solutions :
Utiliser Core Data ( La solution idéale):
1. Utiliser l'API de cryptage des fichier Apple iOS : Dans ce cas le système génère luis même la clé de chiffrement en se basant sur le "passcode" utilisateur et la classe de protection utilisé.
Problème : J'ai aucun moyen d'associer le mot de passe de l'application à la génération de cette clés.
2. Utiliser Commen Crypto : Je ne sais ce qu'on peut faire avec cette solution, Est-ce possible de crypter facilement le store Core Data ? et aux niveaux performances ? Si vous avez des retours d'expériences c'est super.
Utiliser SQLite :
Y a des librairies externes qui chiffrent facilement une base de données sqlite comme SQLCipher.
Problème : ça me soule d'utiliser SQLite dans un projet dont j'ai beaucoup de synchronisation à faire entre mes données locales et les données serveurs,.....
Donc voila je suis embêté parce j'ai l'impression que je vais opté pour SQLite et ça va être la catastrophe.
Voyez-vous une solution se basant sur Core Data ? Merci
Réponses
as tu regardé: https://nickharris.wordpress.com/2010/07/14/core-data-and-enterprise-iphone-applications-protecting-your-data/
olivier
L'article parle du premier cas que j'ai cité ( peut être que j'ai mal expliqué
. Mais le problème avec cette solution c'est que j'ai pas la main sur la clés du chiffrement, la clés est associée avec le mot de passe utilisateur et autre chose que le système gère lui même.
Nick Harris parle d'une vidéo de WWDC 2010 sur "Securing Application Data", qui se trouve ici https://developer.apple.com/videos/wwdc/2010/. Peut-être, ça t'aiderait ?
Je ne l'ai jamais utilisé, mais il y a ça:
https://github.com/project-imas/encrypted-core-data
CoreData ne dipose d'aucun mécanisme de chiffrement natif.
Le seul moyen de chiffrer avec CoreData c'est d'utiliser des IncrementalStore personnalisé, ce qui est complexe à mettre en oe“uvre (j'en ai déjà écris, c'est pas donné à tout le monde, et si on y ajoute de la crypto, il y a toute les chances de se planter). Cette solution c'est ce que tente de mettre en oe“uvre le lien de FKDEV. Jamais testé et un gros audit est nécessaire IMHO avant de l'envisager.
Le chiffrement natif de l'iPhone est de mon point de vue la solution la plus intéressante pour la plupart des applications.
C'est pas gratifiant pour le dev mais au moins ça fonctionnera pour de vrai.
Ok Merci pour vos réponses.
c'est bien parti pour SQLite ...malheureusement
Pourquoi abandonner Core Data pour SQLite quand Core Data utilise une base de données SQLite ?
Autre question : si je génère des données prelodées et que je joins dans le bundle de mon app un fichier core data, sera-t-il chiffré ? Si oui, je ne vois pas comment la clé pourrait dépendre du tel.
Parce que Core Data n'est à priori pas linké avec une version de sqlite permettant le chiffrage de la base.
Si on pouvait contrôler la version de sqlite utilisée par Core Data, alors ce serait jouable.
On utiliserait les extensions sqlite qui permettent de chiffrer la base, et voilà .
Par ce que CoreData utilise un backend SQLite classique et ne permet pas, sauf à écrire un NSIncrementalStore, de configurer la base SQLite comme on le souhaite.
Selon l'application, ça a du sens.
Par exemple, si je fait une application de gestion de mot de passe, j'en ai rien a braire que le téléphone soit sécurisé, je veux que mes données le soient. Car les données applicatives stocké de manière sécurisé sur iOS ne le sont tant qu'elles restent sur iOS.
Je ne veux pas que la compromission de la sauvegarde du téléphone permette d'accéder à mes mots de passe.
Et à l'avenir ça me permet de porter cela sur OS X qui lui ne dispose pas de chiffrement natif du même ordre (FileVault déchiffre tout d'un coup, il n'y a pas de sous-clefs par utilisateurs par exemple).
Rien à voir avec la semoule, c'est simplement changer le niveau de protection des fichiers de CoreData vis à vis du système natif au système de fichiers d'iOS.
Cela ne permet pas de chiffrer le contenu de la base en elle même.
Je tiens au passage à rappeler que chiffrer une base de donnée est quelque chose d'assez complexe. Ce n'est pas donné à tout le monde et globalement, ça n'a de sens que pour protéger les données à froid.
Une fois l'application lancée, les données sont accessible en mémoire. Ou a minima les indexes permettant de faire des requêtes dessus sans devenir dingue. Sinon cela veut dire que pour chaque requête on est obliger de déchiffrer toutes les entrées de la base. C'est impossible.
La plupart du temps, lorsque l'on chiffre une base de données, on chiffre essentiellement son espace de stockage sur disque et une personne autorisé entre une clef de déchiffrement au démarrage du serveur de base de données. Ce que propose en gros l'iPhone.
Les rares cas où on chiffre plus que cela, c'est lorsque des secrets fort sont stockés en base.
La possibilité est alors de stocker ce secret sous forme de donnée brute chiffrée. Il n'y a alors qu'une seule colonne de chiffrée et le reste est en clair (pour permettre de trouver la ressource, donc les clefs primaires et éventuellement le titre de la ressource pour faire une recherche dessus).
ça c'est très simple à faire avec CoreData et CommonCrypto. Le principe de base est :
NSDictionnary de départ -> NSData (conversion en PLIST) -> CommonCrypto pour chiffrer ça avec AES CBC -> NSData (chiffré)
Et tu stock ce NSData final.
Autre chose, c'est pas forcément une bonne chose que de chiffrer les données avec le mot de passe de l'utilisateur. Car le jour où il en change c'est l'enfer pour tout modifier.
Généralement le mot de passe de l'utilisateur protège une clef aléatoire qui elle chiffre les données. Quand tu change ton mot de passe, tu ne fait que protéger la même clef avec un autre code. Sans tout refaire. C'est le fonctionnement de FileVault et de la protection iOS en gros.
Autre question naà¯ve : si mon fichier core data est chiffré est que l'iPhone est jailbreaké, la personne peut-elle facilement lire le fichier (en clair) ?
Un utilisateur qui jailbreak son iPhone doit avoir conscience que par définition, jailbreaker signifie "faire sauter toutes les sécurités que iOS met en place pour ta propre protection". Du coup c'est à eux d'en prendre pleinement la responsabilité.
Alors certes souvent les gens font ça pour lever aussi des limitations qui les gênent, mais ces limitations sont là justement, du moins pour une bonne partie, pour la sécurité. On ne peut pas à la fois enlever la porte de la maison parce qu'on trouve ça chiant d'avoir à l'ouvrir à chaque fois qu'on veut sortir... et espérer quand même être protégé contre un cambriolage.
Donc si les gens jailbreak leur iPhone, il faut qu'ils aient conscience que par définition ça casse les protections, et donc que plus rien n'empêche une application malveillante d'aller fouiller dans les données des autres applications, aller y chercher des mots de passe qui seraient stockés, aller récupérer des données qui étaient prévu pour rester dans la sandbox de l'application d'origine. Ils ne peuvent pas alors espérer que leurs données qu'ils mettent dans leur iPhone soit toujours aussi bien protégées alors qu'ils ont fait sauter les verrous, c'est à eux d'assumer qu'il y a un risque pour leurs mots de passe.
Perso nous on met toujours une clause dans les CGU disant que si le device est jailbreaké c'est de la responsabilité de l'utilisateur d'assumer qu'il a fait sauter les protections et qu'on ne peut du coup plus garantir la sécurité de ses données.
Le jailbreak c'est le Mal ! >:D
D'où ma question : si le device est jailbreaké et que les données sont protégées avec le procédé d'Apple, est-ce que le fichier sera lisible ?
- Par exemple si tu embarques ta base (non chiffrée) dans ton bundle IPA avec l'appli, avant même de parler de jailbreak c'est très facile de la récupérer. Si tu synchronises ton iPhone avec ton Mac via iTunes ça va copier tes IPA sur ton mac pour les sauvegarder (ou même si tu les télécharges directement depuis iTunes depuis ton Mac, dans tous les cas tu peux facilement récupérer l'IPA sur ton Mac in fine). Et du coup il suffit de dézipper l'IPA pour aller trouver le fichier sqlite dedans
- Du coup tu te dis "je vais le chiffrer". Oui mais pour la chiffrer, il va bien falloir que tu aies une clé de déchiffrement pour que quand l'appli se lance tu puisses déchiffrer ta base. Donc cette clé il faut l'embarquer dans ton IPA. Donc ça ne fait que déplacer le problème
- Alors tu pourrais te dire "je vais pas embarquer cette clé, je vais la télécharger au premier lancement". Oui mais comment s'assurer que la connexion à ton serveur à ce premier lancement est sécurisée (pour s'assurer qu'un petit malin ne va pas venir espionner le traffic de son propre réseau Wifi au lancement de ton app pour voir ce qui passe dessus et voir la clé qui t'es retournée) ? Ou alors il faut une connexion sécurisée avec vérification de l'identité des 2 parties (SSL Two-Way). Mais ça nécessite alors d'embarquer dans l'IPA la clé privée permettant à ton app de t'authentifier sur le serveur... donc encore une fois, ça ne fait que déplacer le problème
- Tu pourrais éventuellement embarquer ta clé de chiffrement de ta base directement dans ton code, quitte à l'éclater et la parsemer dans plusieurs constantes pour perdre un peu celui qui chercherait à analyser/désassembler ton application pour la récupérer. Mais ça va pas aller bien loin car ça va être vite fait de trouver à quel endroit tu assembles ces constantes et donc reconstituer la clé
- Ou même plus simple encore si l'utilisateur a un iPhone jailbreaké il va pouvoir attacher un débuggeur à ton application pendant qu'elle tourne et dumper sa mémoire et accéder directement au contenu de la base de données que l'application aura bien dû déchiffrer pour pouvoir la manipuler de toute façon au runtime (comme le mentionnait déjà yoann en fait)
Au final il n'y a pas vraiment de solution miracle... quelle que soit la solution dans tous les cas par définition si ton application peut déchiffrer ta base de données pour pouvoir y lire dedans (et va bien falloir qu'elle le fasse !), alors tes données ne sont jamais complètement protégées vu que sur un environnement jailbreaké y'aura moyen de lire les données une fois déchiffrées par l'app.Reste à voir si tu veux jouer au jeu du chat et de la souris avec les pirates, pour à défaut de rendre ça impossible, de leur complexifier au maximum la tâche... mais à ce jeu là , on sait bien qui perd à chaque fois... ça veut dire qu'il faudrait que tu aies autant ou + de connaissances en sécurité qu'un éventuel pirate pour réussir à le berner et à être plus malin que lui... je doute que beaucoup de monde ici ait un niveau de compétence assez élevé en sécurité pour faire cela (et même dans ce cas ça ne protège en rien)
Réponse hyper intéressante Ali avec plein de détails techniques ! Merci
Je pense que dans mon cas, chiffrer les données à l'aide du clé est la bonne solution (ou alors rien du tout).
D'après ce que vous avez dit, il me reste une difficulté, c'est que ma base core data est produite par une appli OSX...
Merci @samir d'avoir ouvert cette discussion très intéressante !
Ce qui est bien avec ce forum, c'est que c'est une sorte de blog vivant
En fait, le seul moyen de sécuriser la base de donnée, c'est de ne pas l'embarquer mais de télécharger des morceaux quand l'utilisateur en a besoin.