Concrètement, ça veut dire que si on a mis dans le fichier pref des tags comme quoi une in-app est activée, l'utilisateur peut mettre la variable à true et donc accéder aux fonctionnalités ?
Concrètement, ça veut dire que si on a mis dans le fichier pref des tags comme quoi une in-app est activée, l'utilisateur peut mettre la variable à true et donc accéder aux fonctionnalités ?
Heu non. Keychain comme NSUserDefault sont des éléments modifiable par l'utilisateur avec le jailbreak (et en bidouillan un peut ça doit l'être aussi sans jailbreak via les sauvegardes).
Non, si vous voulez stocker des info d'achat il n'y a pas 36 options...
Par exemple, lorsqu'un utilisateur achète une application sur l'AppStore il y a un reçu dans l'application que vous êtes censé valider dans votre code. Ce reçu n'est valable que 30 jours de mémoire. Si pendant plus de 30 jours l'utilisateur ne s'est pas connecté à Internet avec son iOS les applications deviennent inutilisable.
Vous pouvez reprendre ce type d'idée, des reçu signé par un serveur après validation de l'achat depuis votre serveur au près de l'AppStore. Et éventuellement leur mettre une date de péremption.
C'est un exemple, c'est perfectible et d'autres méthodes existent. Dans tous les cas le simple stockage dans les container d'Apple ne suffisent pas.
Merci Yoann, je n'ai pas tout compris, mais c'est bon à savoir. En ce qui me concerne, dans un premier temps, je me contenterai de la méthode de Smy qui me semble un peu plus accessible. Et puis, je pense que pour une app ou une extension à moins de 2 euros, tout le monde n'a pas forcément envie de s'amuser à bidouiller, au risque de ne pas avoir les mises à jour, et de n'avoir aucune fiabilité dans le temps... je vais compter là -dessus...
Pourquoi s'épuiser à sécuriser les inapp pour les iPhone "jailbreakés" ? Leurs utilisateurs peuvent déjà télécharger tout ce qu'ils veulent gratuitement, non ?
Et j'ai des doutes sur la modification du keychain sur un iPhone non jailbreaké. Sa lecture via une sauvegarde peut être, mais ce n'est pas le débat.
Pourquoi s'épuiser à sécuriser les inapp pour les iPhone "jailbreakés" ? Leurs utilisateurs peuvent déjà télécharger tout ce qu'ils veulent gratuitement, non ?
Et j'ai des doutes sur la modification du keychain sur un iPhone non jailbreaké. Sa lecture via une sauvegarde peut être, mais ce n'est pas le débat.
Parce que si vous avez codé ça correctement (i.e.: avec une partie server side correctement monté et une vérification au près d'Apple, le jailbreak ne changera rien).
Pour info tous les outils existent pour accéder à une sauvegarde iOS et au keychain.
Parce que si vous avez codé ça correctement (i.e.: avec une partie server side correctement monté et une vérification au près d'Apple, le jailbreak ne changera rien).
Tu veux dire qu'on peut éviter le téléchargement de notre appli sur un Iphone jailbreaké ?
Tu veux dire qu'on peut éviter le téléchargement de notre appli sur un Iphone jailbreaké ?
Pour l'application en elle même c'est un peu plus complexe car on ne peut pas faire de vérification server-side contrairement au in-app. Il faut se baser entièrement sur les données locales qui peuvent donc être falsifié par le jailbreak.
Le fait de rajouter pour le in-app une vérification server side complexifie le hack mais ne le rend pas impossible. Cela demandera simplement un travail plus précis sur votre application (hack du binaire pour inverser des conditions de test de validité de reçu par exemple) ou faire un faux serveur de validation.
Bref, ça ne rend pas impossible la chose mais ça peut en décourager certains.
Je sais pas... une attaque MITM me semble bien plus simple à mettre en oeuvre qu'un hack du binaire.
Par exemple je sais configurer mon iPhone pour qu'il utilise un proxy, je sais démarrer Wireshark pour regarder les requêtes qui passent, donc faire un serveur pour agir en tant que MITM à partir de là n'est pas bien dur. Par contre je n'y connais pas grand chose en assembleur ARM et aurait du mal à suivre la logique d'un jeu d'instruction directement à partir d'un binaire, je ne sais pas lire dans la matrice à ce point. De plus les instructions d'un binaire iPhone sont chiffrées. Y'a bien sûr moyen de jailbreaker un iPhone puis attacher un LLDM ou GDB au binaire (du coup on a forcément les instructions non chiffrées à ce stade) mais de là à analyser le code à partir de là , j'aurais abandonné bien avant. Alors que lancer un Wireshark semble bien + à ma portée.
Bref, se baser plutôt sur une validation serveur n'est pas forcément + sécurisé qu'une validation locale par le binaire.
Je sais pas... une attaque MITM me semble bien plus simple à mettre en oeuvre qu'un hack du binaire.
Par exemple je sais configurer mon iPhone pour qu'il utilise un proxy, je sais démarrer Wireshark pour regarder les requêtes qui passent, donc faire un serveur pour agir en tant que MITM à partir de là n'est pas bien dur.
Par contre je n'y connais pas grand chose en assembleur ARM et aurait du mal à suivre la logique d'un jeu d'instruction directement à partir d'un binaire, je ne sais pas lire dans la matrice à ce point. De plus les instructions d'un binaire iPhone sont chiffrées. Y'a bien sûr moyen de jailbreaker un iPhone puis attacher un LLDM ou GDB au binaire (du coup on a forcément les instructions non chiffrées à ce stade) mais de là à analyser le code à partir de là , j'aurais abandonné bien avant. Alors que lancer un Wireshark semble bien + à ma portée.
Bref, se baser plutôt sur une validation serveur n'est pas forcément + sécurisé qu'une validation locale par le binaire.
Tout dépend comment est fait la validation au serveur.
Si le check au serveur est régulier et aléatoire ça demande d'avoir du MiTM en permanence, ce qui n'est pas forcément simple.
Si ta communication avec le serveur est chiffré via une pair de clef codé en dur c'est déjà plus complexe (clef publique dans ton binaire, le code n'accepte de communication avec le serveur que si c'est cette clef qui décode le flux et non une autre).
Le hack au binaire à l'avantage d'être facile pour les utilisateurs une fois que quelqu'un a fait le travail.
je remonte le sujet parce que je m'interroge sur la nouvelle organisation des données avec IOS 8.
Tout est structuré autrement, les apps d'un côté, leurs datas ailleurs, des codes pour les répertoires assez peu déchiffrables (d'ailleurs c'est un peu la zone pour s'y retrouver).
Pensez-vous que ça change quelque chose question sécurisation ?
Oui c'est assez simple ensuite, y'a juste une méthode de NSFileManager ou une classe du genre à appeler pour appliquer sur le fichier choisi l'attribut indiquant qu'on veut le chiffrer.
ça n'a d'effet que si l'utilisateur a mis un code de verrouillage sur son téléphone (ou TouchID) car sous le capot il se sert de ce code comme seed pour la clé de chiffrage (ce qui est logique sinon ça ne serait pas très robuste)
Oui c'est assez simple ensuite, y'a juste une méthode de NSFileManager ou une classe du genre à appeler pour appliquer sur le fichier choisi l'attribut indiquant qu'on veut le chiffrer.
ça n'a d'effet que si l'utilisateur a mis un code de verrouillage sur son téléphone (ou TouchID) car sous le capot il se sert de ce code comme seed pour la clé de chiffrage (ce qui est logique sinon ça ne serait pas très robuste)
C'est un peu le FileVault d'iOS en somme.
Pas vraiment comme FileVault 2 sur OS X.
FV2 sur OS X est un système qui s'active à la demande et qui donne accès à une clef de chiffrement aléatoire à stocker de son coté en cas de.
Le chiffrement sur iOS est totalement différent. Il est toujours actif, que vous ayez ou non un code personnel, les données stocké sont toujours chiffré.
La clef de chiffrement n'est pas unique, c'est un empilement de clef aléatoire et de clef déterministe donc une lié au matériel et l'autre au code personnel. Ce qui fait que le stockage d'un iPhone ne peut être lu par un autre (hardware différent donc impossible à déchiffré).
Le code personnel est utilisé pour chiffré la partie utilisateur d'une des clefs de déchiffrement. Si vous ne mettez pas ce code, cette partie n'est pas sécurisé donc le téléphone peut être lu en live, mais si l'iPhone est bloqué ou effacé (via iCloud), les données restent protégé.
C'est le principe du "data at rest". En gros, tout est chiffré et si besoin la clef principale est effacé de l'iPhone, rendant les données illisible d'un point de vue cryptographique.
Heu yoann je dis pas que tu as tort, dans mon message précédent je n'ai pas cité la doc en réponse à ta précision sur le fonctionnement du chiffrement iOS, mais plutôt en complément de mon message d'avant, c'est tout. Donc juste pour aider Booleane pour qu'elle sache quelles méthodes appeler, et ainsi préciser mon message précédent où j'étais un peu vague avec mon histoire de "une méthode sur NSFileManager à appeler"...
D'après ce que vous me dites, ça n'a donc rien à voir avec un chiffrement automatique, comme le fait SQLCypher par exemple sur ma base SQLite... puisque Data encryption est "à la demande de l'utilisateur", alors que moi, je veux que ce soit pour tous les utilisateurs...
Non ce n'est pas à la demande de l'utilisateur, c'est selon si tu l'actives pour ton application ou pas. Et selon si, par code, tu choisis de modifier la politique de chiffrement fichier par fichier, si tu veux tuner plus finement le chiffrement de chaque fichier de ta sandbox.
Et du coup, vu ce que yoann affirme, contrairement à ce que laisse penser la doc, même si l'utilisateur n'a pas mis de code de sécurité sur son iPhone dans ses Préférences Système, les données seront chiffrées.
En même temps faut être un peu fou pour ne pas mettre de code de sécurité sur son iPhone. Le jour où tu te le fais voler, si l'utilisateur peut allumer ton iPhone sans avoir à mettre de code, il va accéder à un peu tout ce que tu as dessus... Bon j'avoue, depuis que j'ai un iPhone 5S et donc TouchID, c'est facile à dire, à chaque fois que j'éteins (enfin met en veille via le bouton Power) mon iPhone pour le mettre dans ma poche, quand je veux le réveiller j'appuie sur le bouton Home et grâce à TouchID qui reconnaà®t mon empreinte sans que je n'aie à rentrer de code. A l'époque où j'avais mon 4S ça m'énervait un peu de devoir rentrer mon code de sécurité à chaque fois que je réveillais mon iPhone, donc je comprend que certains ait envie de le désactiver dans ce genre de situation, même si c'est au détriment de la sécurité la plus élémentaire.
Non ce n'est pas à la demande de l'utilisateur, c'est selon si tu l'actives pour ton application ou pas. Et selon si, par code, tu choisis de modifier la politique de chiffrement fichier par fichier, si tu veux tuner plus finement le chiffrement de chaque fichier de ta sandbox.
Et du coup, vu ce que yoann affirme, contrairement à ce que laisse penser la doc, même si l'utilisateur n'a pas mis de code de sécurité sur son iPhone dans ses Préférences Système, les données seront chiffrées.
C'est à dire que je n'ai pas du tout le même but.
Mon but est de chiffrer MA base fournie par l'application (pour ne pas qu'un concurrent s'en serve) et non LA base de l'utilisateur.
Donc, je le redis: je ne suis pas sûr que le Data Protection soit pour moi.
Mon but est de chiffrer MA base fournie par l'application (pour ne pas qu'un concurrent s'en serve) et non LA base de l'utilisateur.
Donc, je le redis: je ne suis pas sûr que le Data Protection soit pour moi.
Chiffrer TA base pour qu'un concurrent ne te la vole pas est assez inutile à vrai dire.
Chiffrer ta propre base locale voudrait dire avoir la clef de déchiffrement en local également. Donc totalement accessible à un attaquant qui cherche à te voler tes données.
Si tu veux être efficace, tu pose un brevet sur l'organisation de ta base de donnée si tant est qu'elle soit un minimum spécifique.
Les mécanisme de protection de données iOS sont présents pour protéger l'utilisateur d'un attaquant.
Par nature, il n'y a rien protégeant le développeur de l'extraction de données locales d'un utilisateur consentant.
Chiffrer TA base pour qu'un concurrent ne te la vole pas est assez inutile à vrai dire.
Chiffrer ta propre base locale voudrait dire avoir la clef de déchiffrement en local également. Donc totalement accessible à un attaquant qui cherche à te voler tes données.
C'est sûr.
Mais il faut tout de même s'y connaà®tre assez je pense ?
Si tu veux être efficace, tu pose un brevet sur l'organisation de ta base de donnée si tant est qu'elle soit un minimum spécifique.
Elle n'est pas spécifique.
Elle est juste bien organisée et ça m'a pris un temps fou et des recherches longues. Je ne peux déposer un brevet pour ça.
Par ailleurs, celui qui a du temps, un stylo, et des feuilles de papier pourra tout aussi la reproduire en parcourant mon application... ça ira p-e plus vite que de trouver la clé d'ailleurs.
Mais il faut tout de même s'y connaà®tre assez je pense ?
Pas beaucoup plus que pour taper dans la base de donnée d'une autre application pour en extraire les données.
Elle n'est pas spécifique.
Elle est juste bien organisée et ça m'a pris un temps fou et des recherches longues. Je ne peux déposer un brevet pour ça.
Les brevets sur les organisations de base de données sont les plus complexe à mettre en oe“uvre. À voir si c'est jouable. un brevet apporte une belle plus value à ton entreprise pour vendre et obtenir des financement.
Par ailleurs, celui qui a du temps, un stylo, et des feuilles de papier pourra tout aussi la reproduire en parcourant mon application... ça ira p-e plus vite que de trouver la clé d'ailleurs.
Sauf que là ce n'est pas scalable et chiant pour les mises à jour :-)
Réponses
Merci pour l'info.
Concrètement, ça veut dire que si on a mis dans le fichier pref des tags comme quoi une in-app est activée, l'utilisateur peut mettre la variable à true et donc accéder aux fonctionnalités ?
Exactement.
Ok. Bon, ben y a plus qu'à retrousser encore nos manches
Utilise le Keychain pour ça... Tu as des moyens de simplifier l'accès et du coup c'est une ou deux ligne pour lire et écrire ta valeur...
Par exemple : https://github.com/ldandersen/scifihifi-iphone/tree/master/security
Merci beaucoup, je me penche sur le sujet dès que possible.
Heu non. Keychain comme NSUserDefault sont des éléments modifiable par l'utilisateur avec le jailbreak (et en bidouillan un peut ça doit l'être aussi sans jailbreak via les sauvegardes).
Non, si vous voulez stocker des info d'achat il n'y a pas 36 options...
Par exemple, lorsqu'un utilisateur achète une application sur l'AppStore il y a un reçu dans l'application que vous êtes censé valider dans votre code. Ce reçu n'est valable que 30 jours de mémoire. Si pendant plus de 30 jours l'utilisateur ne s'est pas connecté à Internet avec son iOS les applications deviennent inutilisable.
Vous pouvez reprendre ce type d'idée, des reçu signé par un serveur après validation de l'achat depuis votre serveur au près de l'AppStore. Et éventuellement leur mettre une date de péremption.
C'est un exemple, c'est perfectible et d'autres méthodes existent. Dans tous les cas le simple stockage dans les container d'Apple ne suffisent pas.
Merci Yoann, je n'ai pas tout compris, mais c'est bon à savoir. En ce qui me concerne, dans un premier temps, je me contenterai de la méthode de Smy qui me semble un peu plus accessible. Et puis, je pense que pour une app ou une extension à moins de 2 euros, tout le monde n'a pas forcément envie de s'amuser à bidouiller, au risque de ne pas avoir les mises à jour, et de n'avoir aucune fiabilité dans le temps... je vais compter là -dessus...
Pourquoi s'épuiser à sécuriser les inapp pour les iPhone "jailbreakés" ? Leurs utilisateurs peuvent déjà télécharger tout ce qu'ils veulent gratuitement, non ?
Et j'ai des doutes sur la modification du keychain sur un iPhone non jailbreaké. Sa lecture via une sauvegarde peut être, mais ce n'est pas le débat.
Parce que si vous avez codé ça correctement (i.e.: avec une partie server side correctement monté et une vérification au près d'Apple, le jailbreak ne changera rien).
Pour info tous les outils existent pour accéder à une sauvegarde iOS et au keychain.
Après c'est comme toujours, à vous de choisir le niveau de sécurité en fonction du niveau de risque.
Tu veux dire qu'on peut éviter le téléchargement de notre appli sur un Iphone jailbreaké ?
Pour l'application en elle même c'est un peu plus complexe car on ne peut pas faire de vérification server-side contrairement au in-app. Il faut se baser entièrement sur les données locales qui peuvent donc être falsifié par le jailbreak.
Le fait de rajouter pour le in-app une vérification server side complexifie le hack mais ne le rend pas impossible. Cela demandera simplement un travail plus précis sur votre application (hack du binaire pour inverser des conditions de test de validité de reçu par exemple) ou faire un faux serveur de validation.
Bref, ça ne rend pas impossible la chose mais ça peut en décourager certains.
Ok, merci pour ces précisions.
Par exemple je sais configurer mon iPhone pour qu'il utilise un proxy, je sais démarrer Wireshark pour regarder les requêtes qui passent, donc faire un serveur pour agir en tant que MITM à partir de là n'est pas bien dur.
Par contre je n'y connais pas grand chose en assembleur ARM et aurait du mal à suivre la logique d'un jeu d'instruction directement à partir d'un binaire, je ne sais pas lire dans la matrice à ce point. De plus les instructions d'un binaire iPhone sont chiffrées. Y'a bien sûr moyen de jailbreaker un iPhone puis attacher un LLDM ou GDB au binaire (du coup on a forcément les instructions non chiffrées à ce stade) mais de là à analyser le code à partir de là , j'aurais abandonné bien avant. Alors que lancer un Wireshark semble bien + à ma portée.
Bref, se baser plutôt sur une validation serveur n'est pas forcément + sécurisé qu'une validation locale par le binaire.
Tout dépend comment est fait la validation au serveur.
Si le check au serveur est régulier et aléatoire ça demande d'avoir du MiTM en permanence, ce qui n'est pas forcément simple.
Si ta communication avec le serveur est chiffré via une pair de clef codé en dur c'est déjà plus complexe (clef publique dans ton binaire, le code n'accepte de communication avec le serveur que si c'est cette clef qui décode le flux et non une autre).
Le hack au binaire à l'avantage d'être facile pour les utilisateurs une fois que quelqu'un a fait le travail.
Bonjour à tous,
je remonte le sujet parce que je m'interroge sur la nouvelle organisation des données avec IOS 8.
Tout est structuré autrement, les apps d'un côté, leurs datas ailleurs, des codes pour les répertoires assez peu déchiffrables (d'ailleurs c'est un peu la zone pour s'y retrouver).
Pensez-vous que ça change quelque chose question sécurisation ?
Tu devrais aussi faire une recherche sur le Data Protection.
Est-ce aussi simple que ce qu'ils disent ?
Merci. Tout est toujours très simple après qu'on ait mis les mains dans le cambouis...
ça n'a d'effet que si l'utilisateur a mis un code de verrouillage sur son téléphone (ou TouchID) car sous le capot il se sert de ce code comme seed pour la clé de chiffrage (ce qui est logique sinon ça ne serait pas très robuste)
C'est un peu le FileVault d'iOS en somme.
Pas vraiment comme FileVault 2 sur OS X.
FV2 sur OS X est un système qui s'active à la demande et qui donne accès à une clef de chiffrement aléatoire à stocker de son coté en cas de.
Le chiffrement sur iOS est totalement différent. Il est toujours actif, que vous ayez ou non un code personnel, les données stocké sont toujours chiffré.
La clef de chiffrement n'est pas unique, c'est un empilement de clef aléatoire et de clef déterministe donc une lié au matériel et l'autre au code personnel. Ce qui fait que le stockage d'un iPhone ne peut être lu par un autre (hardware différent donc impossible à déchiffré).
Le code personnel est utilisé pour chiffré la partie utilisateur d'une des clefs de déchiffrement. Si vous ne mettez pas ce code, cette partie n'est pas sécurisé donc le téléphone peut être lu en live, mais si l'iPhone est bloqué ou effacé (via iCloud), les données restent protégé.
C'est le principe du "data at rest". En gros, tout est chiffré et si besoin la clef principale est effacé de l'iPhone, rendant les données illisible d'un point de vue cryptographique.
Je n'y peut rien si la documentation fournie aux développeur est trop légère :-)
Voilà un slide de base pour commencer à comprendre le mécanisme de sécurité d'iOS et le système de keychain et de keybag http://macadmins.psu.edu/wp-content/uploads/sites/1567/2014/07/iOS-Security-Decoded-Dave-Test.pdf
Je ne peux pas vous diffuser les autres support à ma disposition. Cela dit ça doit se trouver assez facilement sur le net.
Donc juste pour aider Booleane pour qu'elle sache quelles méthodes appeler, et ainsi préciser mon message précédent où j'étais un peu vague avec mon histoire de "une méthode sur NSFileManager à appeler"...
D'après ce que vous me dites, ça n'a donc rien à voir avec un chiffrement automatique, comme le fait SQLCypher par exemple sur ma base SQLite... puisque Data encryption est "à la demande de l'utilisateur", alors que moi, je veux que ce soit pour tous les utilisateurs...
Et du coup, vu ce que yoann affirme, contrairement à ce que laisse penser la doc, même si l'utilisateur n'a pas mis de code de sécurité sur son iPhone dans ses Préférences Système, les données seront chiffrées.
En même temps faut être un peu fou pour ne pas mettre de code de sécurité sur son iPhone. Le jour où tu te le fais voler, si l'utilisateur peut allumer ton iPhone sans avoir à mettre de code, il va accéder à un peu tout ce que tu as dessus...
Bon j'avoue, depuis que j'ai un iPhone 5S et donc TouchID, c'est facile à dire, à chaque fois que j'éteins (enfin met en veille via le bouton Power) mon iPhone pour le mettre dans ma poche, quand je veux le réveiller j'appuie sur le bouton Home et grâce à TouchID qui reconnaà®t mon empreinte sans que je n'aie à rentrer de code. A l'époque où j'avais mon 4S ça m'énervait un peu de devoir rentrer mon code de sécurité à chaque fois que je réveillais mon iPhone, donc je comprend que certains ait envie de le désactiver dans ce genre de situation, même si c'est au détriment de la sécurité la plus élémentaire.
C'est à dire que je n'ai pas du tout le même but.
Mon but est de chiffrer MA base fournie par l'application (pour ne pas qu'un concurrent s'en serve) et non LA base de l'utilisateur.
Donc, je le redis: je ne suis pas sûr que le Data Protection soit pour moi.
Chiffrer TA base pour qu'un concurrent ne te la vole pas est assez inutile à vrai dire.
Chiffrer ta propre base locale voudrait dire avoir la clef de déchiffrement en local également. Donc totalement accessible à un attaquant qui cherche à te voler tes données.
Si tu veux être efficace, tu pose un brevet sur l'organisation de ta base de donnée si tant est qu'elle soit un minimum spécifique.
Les mécanisme de protection de données iOS sont présents pour protéger l'utilisateur d'un attaquant.
Par nature, il n'y a rien protégeant le développeur de l'extraction de données locales d'un utilisateur consentant.
C'est sûr.
Mais il faut tout de même s'y connaà®tre assez je pense ?
Elle n'est pas spécifique.
Elle est juste bien organisée et ça m'a pris un temps fou et des recherches longues. Je ne peux déposer un brevet pour ça.
Par ailleurs, celui qui a du temps, un stylo, et des feuilles de papier pourra tout aussi la reproduire en parcourant mon application... ça ira p-e plus vite que de trouver la clé d'ailleurs.
Pas beaucoup plus que pour taper dans la base de donnée d'une autre application pour en extraire les données.
Les brevets sur les organisations de base de données sont les plus complexe à mettre en oe“uvre. À voir si c'est jouable. un brevet apporte une belle plus value à ton entreprise pour vendre et obtenir des financement.
Sauf que là ce n'est pas scalable et chiant pour les mises à jour :-)