iPhone Explorer - Attention à  la sécurisation de vos applis

SmySmy Membre
janvier 2011 modifié dans Apple Developer Programs #1
Bonjour

Connaissez vous iPhone Explorer sur Mac ou PC, qui permet d'accéder aux fichiers d'un iPhone non jailbreaké, et surtout de modifier ces fichiers  >:( ?
http://www.macroplant.com/iphoneexplorer/

Je viens de le tester, et l'on peut très simplement naviguer dans l'arborescence de l'iPhone, accéder à  tous nos précieux fichiers de nos applis, et modifier les prefs.

Du coup, attention à  vos logiques de sécurisations dans le cas d'In App Purchase !

J'ai deux projets en cours sur lesquels je vais revoir pas mal de choses...
«134

Réponses

  • SmySmy Membre
    janvier 2011 modifié #2
    Ah, j'oubliais, Aligator va forcément répondre que c'est dans les docs Apple, page 73 du Securing Guide :)

    (ne le prends pas mal, j'apprécie beaucoup tes réponses :) )
  • 23:26 modifié #3
    Ouaip mais est-ce qu'on peut accéder à  vraiment tout l'iPhone? Même les prefs du système? Non parce que j'en ai marre que le son maximal de l'iPod soit bridé en europe.
  • menfoumenfou Membre
    23:26 modifié #4
    Super, et en plus freeware
    Merci pour le liens  ;)
  • SmySmy Membre
    23:26 modifié #5
    dans 1294407797:

    Ouaip mais est-ce qu'on peut accéder à  vraiment tout l'iPhone? Même les prefs du système? Non parce que j'en ai marre que le son maximal de l'iPod soit bridé en europe.


    Heu, le but de mon post n'est pas de hacker ou vous expliquer comment hacker un iPhone, mais au contraire de vous faire réaliser qu'il faut proprement sécuriser vos applis.
  • AliGatorAliGator Membre, Modérateur
    23:26 modifié #6
    Non c'est page 74, paragraphe 16, alinéa 3, mais t'étais pas loin :D
  • DrakenDraken Membre
    23:26 modifié #7
    Prouve-le !

  • SmySmy Membre
    23:26 modifié #8
    dans 1294420796:

    Non c'est page 74, paragraphe 16, alinéa 3, mais t'étais pas loin :D


    Pfff, encore raté, tu es trop fort pour moi  :)

    Bon, je suis surpris qu'il n'y ai pas de réaction. Suis-je le seul à  découvrir que iOS est une catastrophe coté sécurisation ?

    Sur Mac, j'avais l'habitude du clic droit/afficher le contenu du paquet, mais je pensais que c'était plus protégé sur iPhone. Avec tout leur blah blah sur la compartimentation des applications, l'arborescence "chrootée", etc.

    Du coup, il va falloir crypter les prefs, mettre des clés, et galérer avec les déclarations à  l'exportation pour l'usage de cryptage. Ou au minimum utiliser du md5 qui ne rentre pas dans les déclarations...

    Grrrrr
  • LeChatNoirLeChatNoir Membre, Modérateur
    23:26 modifié #9
    Bof je serai toi, je me prendrai pas la tête...
    T'as peur de quoi en fait ? Qu'on craque ton appli ? Bah, de toutes façons, elle sera crackée donc autant pas perdre de tps la dessus....
  • SmySmy Membre
    23:26 modifié #10
    dans 1294479013:

    Bof je serai toi, je me prendrai pas la tête...
    T'as peur de quoi en fait ? Qu'on craque ton appli ? Bah, de toutes façons, elle sera crackée donc autant pas perdre de tps la dessus....


    Je m'en doute, mais une appli craquée sur un iPhone jailbreaké, je ne peux rien faire. Afficher le contenu d'une appli, je ne peux rien faire non plus puisqu'il suffit de renommer un .ipa en .zip.

    Par contre, que la modification des prefs soit si simple sur un iPhone normal, ça me choque beaucoup plus, c'est tout.

    Si tu veux un exemple, il était possible sur une version de Wired sur iPad de modifier les prefs pour faire comme si tous les numéros étaient achetés (je ne sais pas si c'est encore possible)...

    C'est donc à  nous développeurs de sécuriser au maximum les prefs et la façon de stocker les achats In App Purchase.

  • DrakenDraken Membre
    23:26 modifié #11
    Donc renoncer aux plist, pour stocker les infos dans des fichiers binaires cryptés.

  • AliGatorAliGator Membre, Modérateur
    23:26 modifié #12
    Pourquoi renoncer aux plists ? On peut les crypter, les plists, ou on peut crypter les données dans le plist.

    Et puis quand on doit stocker des données sécurisées, il faut utiliser tout ce que iOS nous fournit pour ça ! La KeyChain, la Security API, la lib CommonCrypto pour crypter les données, etc... c'est fait pour justement !

    Security Architecture Overview : iOS
    GenericKeychain Sample Code
    CryptoExercise Sample Code
    etc., etc.
  • LeChatNoirLeChatNoir Membre, Modérateur
    mars 2011 modifié #13
    Slt,
    Je me suis un peu penché sur le sujet...

    Pour les property list, on peut déjà  enregistrer au format binaire.
    Si on l'ouvre dans un éditeur de texte, c'est illisible.
    Par contre, si on l'ouvre dans property list editor, c'est parfaitement lisible.

    En butinant un peu sur le net, j'ai trouvé des catégories de NSData qui permettent d'encrypter/décrypter les données.
    Je vous colle plus bas le code.

    Sur le site, il est indiqué que ce code peut être utilisé sans déclarer de cryptage à  Apple (quand on soumet l'appli) car c'est des fonctions embarquées, standards Apple.

    Qu'en pensez vous ?
    <br />@implementation NSData (AES256)<br /><br />- (NSData *)AES256EncryptWithKey:(NSString *)key {<br />	// &#039;key&#039; should be 32 bytes for AES256, will be null-padded otherwise<br />	char keyPtr[kCCKeySizeAES256+1]; // room for terminator (unused)<br />	bzero(keyPtr, sizeof(keyPtr)); // fill with zeroes (for padding)<br />	<br />	// fetch key data<br />	[key getCString:keyPtr maxLength:sizeof(keyPtr) encoding:NSUTF8StringEncoding];<br />	<br />	NSUInteger dataLength = [self length];<br />	<br />	//See the doc: For block ciphers, the output size will always be less than or <br />	//equal to the input size plus the size of one block.<br />	//That&#039;s why we need to add the size of one block here<br />	size_t bufferSize = dataLength + kCCBlockSizeAES128;<br />	void *buffer = malloc(bufferSize);<br />	<br />	size_t numBytesEncrypted = 0;<br />	CCCryptorStatus cryptStatus = CCCrypt(kCCEncrypt, kCCAlgorithmAES128, kCCOptionPKCS7Padding,<br />										&nbsp; keyPtr, kCCKeySizeAES256,<br />										&nbsp; NULL /* initialization vector (optional) */,<br />										&nbsp; [self bytes], dataLength, /* input */<br />										&nbsp; buffer, bufferSize, /* output */<br />										&nbsp; &amp;numBytesEncrypted);<br />	if (cryptStatus == kCCSuccess) {<br />		//the returned NSData takes ownership of the buffer and will free it on deallocation<br />		return [NSData dataWithBytesNoCopy:buffer length:numBytesEncrypted];<br />	}<br />	<br />	free(buffer); //free the buffer;<br />	return nil;<br />}<br /><br />- (NSData *)AES256DecryptWithKey:(NSString *)key {<br />	// &#039;key&#039; should be 32 bytes for AES256, will be null-padded otherwise<br />	char keyPtr[kCCKeySizeAES256+1]; // room for terminator (unused)<br />	bzero(keyPtr, sizeof(keyPtr)); // fill with zeroes (for padding)<br />	<br />	// fetch key data<br />	[key getCString:keyPtr maxLength:sizeof(keyPtr) encoding:NSUTF8StringEncoding];<br />	<br />	NSUInteger dataLength = [self length];<br />	<br />	//See the doc: For block ciphers, the output size will always be less than or <br />	//equal to the input size plus the size of one block.<br />	//That&#039;s why we need to add the size of one block here<br />	size_t bufferSize = dataLength + kCCBlockSizeAES128;<br />	void *buffer = malloc(bufferSize);<br />	<br />	size_t numBytesDecrypted = 0;<br />	CCCryptorStatus cryptStatus = CCCrypt(kCCDecrypt, kCCAlgorithmAES128, kCCOptionPKCS7Padding,<br />										&nbsp; keyPtr, kCCKeySizeAES256,<br />										&nbsp; NULL /* initialization vector (optional) */,<br />										&nbsp; [self bytes], dataLength, /* input */<br />										&nbsp; buffer, bufferSize, /* output */<br />										&nbsp; &amp;numBytesDecrypted);<br />	<br />	if (cryptStatus == kCCSuccess) {<br />		//the returned NSData takes ownership of the buffer and will free it on deallocation<br />		return [NSData dataWithBytesNoCopy:buffer length:numBytesDecrypted];<br />	}<br />	<br />	free(buffer); //free the buffer;<br />	return nil;<br />}<br /><br />@end<br />
    

  • muqaddarmuqaddar Administrateur
    23:26 modifié #14
    Et pour crypter tout un fichier SQLite ? C'est possible ça ?
  • AliGatorAliGator Membre, Modérateur
    23:26 modifié #15
    A mon avis c'est pas parce que ça utilise des libs standard genre CommonCrypto que ça veut dire qu'on peut dire lors de la soumission à  Apple qu'on ne crypte pas les données. C'est n'importe quoi. Evidemment qu'il faut indiquer qu'il y a des données cryptées si on crypte des données.
    CommonCrypto permet de faire de la crypto, avec plein d'algos, que ce soit AES ou autre. Ca reste de la crypto, qui doit être signalée comme tel lors de la soumission de l'appli. Mais bon je vois pas en quoi ça serait gênant de devoir le signaler à  Apple (et si on ne le signale pas y'a des chances que l'appli soit refusée)

    Par contre pourquoi ne pas utiliser La protection des fichiers proposée par Apple, qui crypte à  la volée ?
  • LeChatNoirLeChatNoir Membre, Modérateur
    23:26 modifié #16
    ah ?
    Ca fait quoi ça ?
    Ils expliquent pas vraiment... A part que ça protège les fichiers...
    Imaginons que je fasse ça sur une property list. Ca veut dire qu'une fois récupérée via iphone explorer, elle sera illisible ?
  • AliGatorAliGator Membre, Modérateur
    23:26 modifié #17
    A tester j'ai jamais regardé en détail
  • SmySmy Membre
    23:26 modifié #18
    Comme le proposais AliGator, je penche plutôt sur la Keychain dans mes prochaines appli pour les données critiques comme l'inAppPurchase, et les méthodes classiques pour le reste des prefs (plist, fichiers binaires en fwrite, etc).

    Pour les données de vos applis, par exemple les recettes de muqaddar :), un cryptage tout simple à  l'intérieur des champs sqlite peut suffir pour les pirates en herbe (genre XOR).
  • LeChatNoirLeChatNoir Membre, Modérateur
    23:26 modifié #19
    Je ferai le test et vous dirai
  • LexxisLexxis Membre
    23:26 modifié #20
    dans 1299492853:

    Et pour crypter tout un fichier SQLite ? C'est possible ça ?


    Il me semble qu'il est possible de compiler la librairie SQLite avec une option permettant de crypter les pages de données. Tout est transparent pour l'utilisateur (le développeur en fait). Mais (car il y a un mais) les fonctions ce cryptages ne sont pas libre et il faut acheter un option de support auprès de l'auteur de SQLite. Enfin c'était le cas lorsque j'ai ajouté le support sqlite pour une application sur un TPE. Cependant (oui il y a aussi un cependant) il me semble qu'il est possible d'écrire ses propres API de cryptages... évidemment pour avoir plus d'infos à  ce sujet rien ne vaut un petit détour sur www.sqlite.org et plus spécifiquement là  www.sqlite.org/support.html.
  • muqaddarmuqaddar Administrateur
    23:26 modifié #21
    dans 1299511650:

    dans 1299492853:

    Et pour crypter tout un fichier SQLite ? C'est possible ça ?


    Il me semble qu'il est possible de compiler la librairie SQLite avec une option permettant de crypter les pages de données. Tout est transparent pour l'utilisateur (le développeur en fait). Mais (car il y a un mais) les fonctions ce cryptages ne sont pas libre et il faut acheter un option de support auprès de l'auteur de SQLite. Enfin c'était le cas lorsque j'ai ajouté le support sqlite pour une application sur un TPE. Cependant (oui il y a aussi un cependant) il me semble qu'il est possible d'écrire ses propres API de cryptages... évidemment pour avoir plus d'infos à  ce sujet rien ne vaut un petit détour sur www.sqlite.org et plus spécifiquement là  www.sqlite.org/support.html.


    Je vais regarder tout ça de plus près. C'est intéressant en effet.
    Merci pour cette info. ;)
  • LeChatNoirLeChatNoir Membre, Modérateur
    23:26 modifié #22
    dans 1299501723:

    A tester j'ai jamais regardé en détail


    Test effectué. C'est négatif.
    Visiblement, en mettant cet attribut, le fichier est effectivement crypté mais uniquement quand l'appareil est locké.
    Sinon, le fichier est normal.

    J'ai fait le test d'enregistrer mon fichier en mode "protégé", et avec iphone explorer, je le récupère tranquille et l'ouvre comme avant.
    Donc c'est pas une alternative visiblement (dommage, ca aurait été simple :-))

    A+
  • SmySmy Membre
    23:26 modifié #23
    Je relance ce sujet.

    Je vais lancer ma prochaine appli sur un modèle payant, mais je garde en tête de la faire évoluer en freemium si jamais le payant ne prends pas. Dans ce cas, une mise à  jour la passerait en gratuit avec fonctionnalités réduites + inAppPurchase pour la version complète.

    Je ne veux cependant pas pénaliser les acheteurs de la première heure, et je dois donc mémoriser dès la 1.0 qu'ils sont déjà  sur une version complète, au cas où la 1.1 serait freemium.

    Comment à  votre avis mémoriser cette info critique, puisque l'on sait que les prefs sont modifiables facilement.

    Le Key Chain est-il adapté ? Sur Mac il est possible de modifier une valeur avec le Trousseau d'accès, mais je n'ai pas l'impression que ce soit possible en iOS.

    Merci
  • Eddy58Eddy58 Membre
    23:26 modifié #24
    Pour l'encryption de bases SQLite : SQLCipher

    Pas encore eu le temps d'essayer mais ça m'a l'air très efficace et transparent à  l'utilisation une fois tout en place.
  • LeChatNoirLeChatNoir Membre, Modérateur

    Tiens, je déterre ce sujet...


     


    L'utilisation de Magical Record + CoreData s'étant révélée "magique" pour  les nouvelles datas de mon appli, je songe à  transférer mes fichiers plist en CoreData.


     


    Seulement autant mes nouvelles données n'étaient pas critiques, autant les anciennes, c'est le coeur de notre passion et ça me ferait suer qu'on me le repique. Mes plist étaient cryptés en AES256. Mais si je bascule tout sur CoreData, comment ça marche ?


     


    Sachant que c'est pour du iOS6/7. Quelles sont les best practices ?


     


    Merci :)


  • AliGatorAliGator Membre, Modérateur
    Utilise le mécanisme de Data Protection intégré à  iOS (attribut NSFileProtectionComplete) sur ton fichier sqlite de ta base CoreData, il sera protégé.


    - Doc Apple : Protecting Data Using On-Disk Encryption

    - Et un article de Nick Harris (qui date de 2010 mais est toujours d'actualité même s'il parle de CoreData sans MagicalRecord) mais il suffit d'appliquer le même principe sur le fichier sqlite utilisé par MagicalRecord si tu utilise MR, le principe est le même.
  • Les gens, vous serriez gentil de parler de chiffrement et de chiffrer au lieu d'encryption ou de cryptage...


     


    Sinon, avant d'aller plus loin dans ce domaine il est important de vous demander ce que vous chercher à  faire :


    • protéger les données personnelles de l'utilisateur pour en éviter l'espionnage de la personne ?
    • protéger vos propres données pour éviter le vol de vos données par un concurrent ?

    Si nous somme dans le premier cas, c'est bien, mais arrêter de vous emmerder, la seule chose à  faire c'est se reposer sur les API de cryptographie d'Apple et indiquer que vos données doivent être accessible uniquement lorsque le terminal est déverrouiller. Sauf à  faire entrer un mot de passe à  l'utilisateur à  chaque fois, il est fort peu probable que vous fassiez une meilleur sécurité que ça.


     


    Si nous sommes dans le second cas, rendez-vous bien compte que cela ne sert strictement à  rien. La clef de déchiffrement étant forcément stocké sur le système (que ce soit via le keychain ou directement dans le binaire), 5min de reverse engineering amèneront quelqu'un de motiver à  comprendre le système de chiffrement et trouver la clef. L'AES256 ne sera pas plus intéressant ici que du ROT13...


  • LeChatNoirLeChatNoir Membre, Modérateur

    Perso, je suis dans le second cas...


    /* mode provoc' */


    Prouve moi que 5 mn suffisent en m'envoyant mes plist en clair ;)

  • muqaddarmuqaddar Administrateur

    Moi j'utilise ça pour mon Sqlite:


    http://sqlcipher.net




  • Perso, je suis dans le second cas...


    /* mode provoc' */


    Prouve moi que 5 mn suffisent en m'envoyant mes plist en clair ;)




     


    Le plus intéressant est que tu t'essaye toi même au reverse pour comprendre ce qu'est et ce que n'est pas une sécurité logicielle :-)


    http://lightbulbone.com/post/27887705317/reversing-ios-applications-part-1



  • Les gens, vous serriez gentil de parler de chiffrement et de chiffrer au lieu d'encryption ou de cryptage...




     


    C'est un combat perdu d'avance :-) D'ailleurs il me semble que le terme cryptage apparaà®t dans les dico.

Connectez-vous ou Inscrivez-vous pour répondre.