Voici la traduction d'un article de Saurik à propos de tout ceci expliquant et détaillant la situation :
http://www.saurik.com/id/15------------------------------------------------------
Où sont passées mes données TSS iOS 6 ?Normalement, j'arrive à écrire des articles (ou donner des conférences, ou laisser un grand nombre de pages de commentaires sur les différents sites et forums) sur les aspects intéressants de la technologie, confondant les aspects des affaires, les protocoles et les personnes qui les ont standardisé ou de nouveaux outils que lesquels je travaille ; la rédaction de ces articles peuvent être exténuant par moments, mais à un certain niveau, la tâche n'est pas qu'enrichissante, mais amusante.
Malheureusement, ce n'est pas pour ça que je rédige cet article: à la place, je suis ici pour être le porteur de mauvaises nouvelles qui vont probablement me faire obtenir une tonne de mails haineux. Plus précisément, je vous écris ceci pour dire à tous que les données TSS enregistrées sur Cydia pour iOS 6.0-6.1.2 sont inutilisables. Je vais aussi tenter d'expliquer quelques informations sur le processus, d’où vient l'erreur et ce que les utilisateurs peuvent maintenant faire à la place.
Dans le processus, je vais vous expliquer quelques parties du mécanisme de sécurité logiciel iOS que je n'ai pas vu souvent décrits en dehors des présentations lors de conférences techniques de sécurité. En outre, je vais résumer, du point de vue d'un utilisateur, ce qui est actuellement possible avec les informations APTicket mises en cache (quelque chose dont je ne savais pas vraiment grand chose avant d'écrire cela).
Mon objectif est que d'ici la fin de cette article, vous lecteurs, allez comprendre suffisamment sur le processus pour apprécier l'erreur, l'historique de la question et pourquoi çà n'a pas été détecté avant. En outre, il faut espérer que cela sera un peu plus clair lorsque l'information en cache APTicket sera utilisable (car il s'avère que les APTickets cachent une fourchette assez étroite des usages) et la façon dont les utilisateurs affectés pourraient-être encore en mesure d'obtenir ces données.
(Pour ceux qui ne se soucient pas de la longue explication ci-dessous: les seuls appareils où sont enregistrés les APTickets iOS 6 sont en fait les l'iPhone 3G(S), iPhone 4, et l'iPod Touch 4. Sur ces appareils, les utilisateurs peuvent , et probablement «devraient» enregistrer le APTicket qui existe actuellement en permettant leur appareil de démarrer. Cela peut être fait avec un outil qui peut récupérer cette information en utilisant l'exploit bootrom limera1n, tels que redsn0w ou iFaith, et télécharger le nouveau dans Cydia.)
Qu'est-ce que TSS ?Un des aspects pour maintenir un système "sécurisé" est de vérifier que le logiciel qui est installé est le logiciel que vous attendiez. Ceci est fait en utilisant des "signatures" cryptographiques qui peuvent démontrer l'authenticité d'un bloc de données, tels que le système d'exploitation l'exécute sur un appareil tel qu'un iPhone. Apple "signe" tous les logiciels qu'ils mettent sur un iPhone.
Quand le périphérique démarre, chaque étape vérifie la signature de la prochaine étape avant de passer à la suivante. En supposant que chaque étape fonctionne correctement, vous pouvez vous sentir en sécurité que tout le système exécute le logiciel qu'il a été conçu pour fonctionner sans aucune modification et qui pourrait faire des choses que vous ne voulez pas (que ce soit malware réelle, ou l'ajout de fonctionnalités intéressantes que vous n'avez pas autorisé).
Bien sûr, cette hypothèse n'est pas réaliste pour un système aussi complexe que l'iPhone : il ya de nombreux bugs, petites et grandes, qui permettent aux "attaquants" de contourner les divers contrôles. Il est particulièrement difficile que les attaques peuvent permettre des choses comme evasi0n : un "jailbreak untethered", où le logiciel a été modifiée en permanence d'une manière qui va à chaque réinitialisation, ré-attaquer les exploits à chaque démarrage.
Par conséquent, on doit planifier la manière dont les corrections de bugs seront mis en place et seront nécessaires : il ne suffit pas de simplement signer des logiciels, car une fois qu'un bug est trouvé, les utilisateurs peuvent toujours juste revenir à cette version "boguée" connue, prendre le contrôle, puis éventuellement travailler sur leur chemin de retour, certainement, mais, même s'ils sont coincés à l'ancienne version, cela peut déjà être une perte assez coûteux.
La façon dont les fournisseurs généralement résolvent ce problème est de mettre des restrictions juste "signature valide" lorsqu'un nouveau logiciel est installé : le plus commun étant "le logiciel en cours d'installation ne doit pas être plus âgé que le logiciel qu'il remplace, soit en vérifiant le numéro de version ou un code daté (qui est, vraiment, juste une autre façon de coder un numéro de version) ". La plupart des systèmes utilisent ce système.
Toutefois, Apple a décidé que ce n'était pas suffisant, car cela permet de maintenir activement un dispositif efficace à une ancienne version pendant une longue période. En outre, cela signifie que si vous avez un appareil que vous n'avez pas utilisé durant très longtemps et que les révisions de nombreux logiciels ont été libérés entre alors et maintenant, vous pouvez choisir de mettre à niveau vers l'une de ces versions, et pas seulement la dernière.
La Solution d'Apple qui e été déployée avec iOS 3.x (iOS 2.x était signée, mais n'avait pas de protection du tout pour le downgrade), était d'avoir chaque installation unique du système d'exploitation et de vérifier, à ce moment sur Internet, que la version du logiciel installé est "celle que nous avons pour but de vous permettre d'installer". Le vérificateur est le Tatsu Signing Server,, ou «TSS».
Qu'est-ce que le SHSH?Le détail important du processus de signature est alors de savoir exactement ce qui est signé. Au fil des ans, cela a changé. Le système que j'avais décris il ya quelques années dans un article précédent, «Mise en cache du serveur de Signature d'Apple", consistait à «personnaliser» les fichiers qui étaient utilisés dans le cadre du processus du logiciel d'installation du système exploitation iOS (qui est connu comme «restauration») .
Cette personnalisation se fait par l'ajout de données pour chaque fichier qui est spécifique à l'appareil sur lequel le logiciel sera installé, puis d'avoir le résultat "personnalisé" dans un dossier qui soit à nouveau signé par Apple. (Je dis signé à "nouveau", comme les fichiers originaux distribués par Apple sont déjà signés, mais ils ne contiennent pas cette information spécifique à l'appareil et sont entièrement générique).
Les informations spécifiques à l'appareil qui ont été utilisées pour ce processus sont appelées, selon l'endroit où vous le trouvez, la '"puce unique ID" ou le «ECID» (un acronyme dont personne n'est sûr de la signification derrière, mais cela signifie probablement quelque chose comme "identité à puce exclusive"). Cette ECID est un petit bloc de données représentées par un nombre qui est unique pour chaque appareil iOS d'Apple qui a été expédié.
Cette ECID est ensuite envoyé à Apple, ainsi que la liste des fichiers qui sont signés. Apple renvoie alors un "blob" pour chaque fichier, qui est un bloc de données qui remplace la signature existante sur le fichier des informations de personnalisation (qui est l'ECID), parfois quelques données aléatoires en apparence seulement "pour faire bonne mesure", c'est ainsi qu'une nouvelle signature signe l'intégralité du fichier.
La signature réelle à l'intérieur de ce blob est le SHSH, ou signature hash (peut-être "signé hash", encore une fois, personne n'est vraiment sûr, mais nous sommes largement d'accord sur la "signature"). Comme l'ECID d'un dispositif ne change jamais, si vous pouvez ensuite sauvegarder le SHSH d'un dossier personnalisé, vous pouvez toujours l'utiliser plus tard pour installer ce fichier, même si Apple ne veut plus de le signer: nous préférons les sauver.
Comment est compilé chaque SHSH?Je dois maintenant faire un léger détour pour décrire les signatures : la manière dont ces travaux implique ce qu'on appelle un "hash", lorsque vous «signez» un fichier, vous devez d'abord prendre un "hash" du fichier, puis "crypter" ce hachage en utilisant une clé de chiffrement que vous seul avez (une «clé privée»), mais qui peut être décrypté par une seconde clé "publique" que vous êtes en mesure de diffuser largement à l'avance pour toute personne qui s'en soucis.
Le résultat de «hachage» est parfois appelé un "digest" parce que ce qui fait un hachage efficace est de faire une plus petite version du fichier. Ce fichier plus petit a généralement une longueur fixe qui n'est pas lié à la taille du fichier d'origine : elle est plutôt déterminée par le choix de l'algorithme de hachage. L'algorithme qui est utilisé pour vérifier iOS est SHA-1, ce qui génère un résumé de 160-bit.
Lorsque vous construisez un condensé en utilisant SHA-1, vous pouvez effectivement le faire «à la pièce» : vous pouvez obtenir une partie des données et d'arrêter, puis y revenir plus tard quand vous avez la deuxième partie. A tout moment, les données dont vous avez besoin sont 160 bits des données et la longueur que vous avez haché au préalable. Cela signifie qu'il existe un moyen efficace de «continuer de hacher un fichier, où vous l'avez laissé" en utilisant SHA-1.
Apple utilise cette astuce pour générer ses signatures personnalisées : au lieu d'envoyer l'ensemble du dossier sur le serveur, ou même stocker l'intégralité du fichier sur le serveur, l'obligeant à toujours exécuter l'algorithme de hachage sur potentiellement des centaines de mégaoctets de données, Apple envoie seulement une "digestion partielle" sur le serveur dans le cadre d'une demande de TSS, qui est ensuite complétée par le serveur et signé avec sa clé.
Enfin, à l'intérieur d'un fichier de mise à jour logicielle iPhone (IPSW) (qui est en fait un fichier ZIP) il y a un «manifeste de version» qui contient une liste des noms de fichiers et, pour chacun, son empreinte (ce qui est le hachage de ses données, y compris la signature qui est attaché chez Apple) ainsi que l'une de ses digestions partielles pour le fichier sans le bloc signature sur la fin (de sorte qu'il puisse être complété par TSS).
Le processus de personnalisation implique en prenant ainsi le manifeste de construction, la construction d'une demande de TSS, l'envoyer à Apple, d'obtenir le résultat, puis en modifiant chacun des fichiers qui ont été énumérés par le remplacement de la section de signature avec les blobs retournés par TSS. Les fichiers résultants modifiés sont envoyés vers le dispositif, qui vérifie l'intérieur de leur ECID, et valide également la signature de hachage.
La mise en cache du serveur de Signature d'AppleQuand Apple a commencé à le faire, nous avons compris comment ça marchait, et le cours de l'action était clair : mettre en place une attaque en plein milieu sur ce serveur qui pourrait tout simplement stocker tous les SHSH unique qui ont été renvoyés pour chaque fichier de chaque version du micrologiciel pour chaque appareil appartenant à toutes les personnes sont intéressées de pouvoir downgrader (les jailbreakers, et les développeurs de l'App Store qui ont besoin de tester leurs applications sur les premières versions du firmware).
J'ai construit ce système comme un service et j'avais écrit un article sur la façon dont le processus fonctionne et comment il pourrait être utilisé. Initialement, le système a agi seul "au milieu", mais il a été immédiatement renforcée pour enregistrer toutes les ECID de tous les utilisateurs dans une gigantesque base de données, afin qu'il puisse continuer à chaque fois qu'Apple publie une nouvelle version du firmware de demander des informations SHSH à tous "en masse".
Finalement, cependant, vous vous retrouvez avec autant d'ECID dans le fichier que vous essayez de demander à un certain nombre de serveurs des centaines de milliers de fois moins, il devient donc très évident de savoir comment arrêter une telle opération. Pendant quelques années, je n'ai ainsi pas pu lancer le serveur proxy "man in the middle", ni être en mesure de fournir le service d'enregistrement automatique des SHSH des gens.
Cependant, j'ai toujours été en mesure d'aider les utilisateurs à obtenir automatiquement leurs données stockées par l'application Cydia "sur le terrain": Cydia demande les blobs SHSH d'Apple et les télécharge vers mes serveurs chaque fois qu'il constate que vous n'avez pas l'information stockés sur mes serveurs. En outre, je vous propose une API qui permet des outils tiers que récupérer et gérer les mêmes informations pour le télécharger pour moi pour le garder en lieu sûr.
Comment APTicket a changer les choses?Lorsque iOS 5 est sorti, Apple a changé le jeu un peu : SHSH, le système dont je connaissais beaucoup de choses et avait passé énormément de mon temps à développer des outils pour récupérer et stocker des données étaient en chemin mais un nouveau système de vérification appelé APTicket avait été mis en place pour remplacer entièrement dans un certain nombre de dispositif à venir.
La personne qui a ensuite passé beaucoup de temps à étudier APTicket n'était pas moi : c'est effectivement MuscleNerd, le développeur de redsn0w. De plus, pas plus tard que fin Septembre2012, au JailbreakCon, j'ai pu entendre poser des questions de l'auditoire à iH8sn0w sur APTickets après sa présentation, comme si toutes mes connaissances sur la façon dont ils fonctionnent était secondaires; P.
Depuis lors (il y a quelques mois), j'ai passé un peu de temps sur la rétro-ingénierie du système de vérification APTicket et ainsi en savoir un peu plus à ce sujet, mais j'étais surtout concentré sur la recherche de bogues dans l'analyseur de certificat et ne regardait qu'une seule étape du processus de démarrage, j'ai donc continué à ne pas savoir comment APTicket était utilisé, ou en tout cas comment les divers périphériques étaient affectés par leur présence.
Cependant, à un niveau élevé, ce qu'est l'APTicket est un seul bloc de données qui est signé dans son ensemble et qui contient le résumé de tous les fichiers qui seront utilisés pour démarrer le périphérique. De diverses manières, ce qui est beaucoup plus efficace que d'avoir à personnaliser chaque pièce unique : vous n'avez même pas besoin de réécrire les fichiers, comme l'APTicket peut simplement stocker l'empreinte vierge d'origine des fichiers à partir du fichier IPSW.
En outre, il réduit considérablement le nombre de signatures dont le serveur d'Apple a besoin pour fonctionner : chaque fois qu'il publie une nouvelle version d'iOS, il exigence que le logiciel soit signé pour chaque périphérique spécifique qui nécessite un très grand nombre de signatures cryptographique, le mécanisme APTicket réduit le nombre de signatures qu'ils ont à calculer par un facteur compris entre 10 et 20 fois.
En outre, l'APTicket a une particularité spéciale : un "nonce" (
un mot avec une histoire assez intéressante) est stocké à l'intérieur de celui-ci (ce qui signifie que, lui aussi, est signé au cours du processus de restauration par TSS) qui est vérifié en plus de la ECID. Ce "nonce" est un nombre généré de façon aléatoire pendant le processus de restauration, et qui rend ainsi l'APTicket spécifique à chaque restauration simple et non mis en cache.
Mettre en cache le non mis en cacheLa question est alors, et si les APTickets résolvent les problèmes qu'avaient les SHSH : pourquoi les gens les sauvent encore ? On aurait pu s'attendre à ce point que, quand Apple avait introduit les APTickets, que tout le travail d'essayer de stocker et de traiter ces données pour une utilisation ultérieure serait arrêté. Évidemment, ce n'est pas le cas. Il y a deux choses qui se passent ici : la compatibilité en arrière et un peu d'erreurs de mise en œuvre.
Tout d'abord, Apple ne peut pas juste reflasher le bootloader sur les dispositifs existants qui sont sur le terrain et ceux-ci vérifiés par la première étape en utilisant SHSH. Cela signifie que si vous avez des données SHSH stockées pour cette première étape, il n'y a pas d'importance si vous avez un APTicket pour les étapes restantes ou non: vous pouvez tromper la première étape. Si rien d'autre, cela vous permet de revenir à des versions iOS qui n'utilisaient pas APTicket.
Deuxièmement, il s'agit d'un système de vérification complexe, impliquant un grand nombre de petites étapes, comme, par exemple, à un certain moment vous devez réinitialiser le nonce : si le nonce ne change jamais, alors vous pouvez enregistrer les données APTicket quelle qu'en soit le nombre de nonce fixe que vous avez. Je crois comprendre que c'est comme ça que l'astuce de MuscleNerd "re-restore" fonctionne.
Profitant de ces erreurs qui ont permis quelques trucs intéressants, tels que permettre aux gens de passer d'une version d'iOS 5 à une autre, ou de permettre à l'iPad 2 d'être downgradé vers iOS 5 depuis iOS 6 (si vous avez les informations TSS enregistrés pour iOS 4, à utiliser en tant qu'intermédiaire). Pour plus d'informations sur la façon dont vous pouvez utiliser ces techniques, les utilisateurs peuvent s'il le souhaitent lire la FAQ
JailbreakQA sur SHSH et APTicket.
Alors qu'est-ce qui est possible actuellement ?Alors que ai mentionné un certain nombre d'astuces intéressantes, elles sont principalement liées soit à des anciennes versions d'iOS ou d'anciens appareils. Avec les nouveaux appareils, les APTickets sont plus profondément ancrés dans le processus de démarrage et avec les nouvelles versions d'iOS, la plupart des erreurs qui ont été utilisés ont été résolues. Comme les nouveaux appareils n'ont jamais eu accès à installations des versions plus anciennes d'iOS, ces limitations commencer à se chevaucher.
En particulier, de nombreux anciens appareils sont soumis à un exploit appelé limera1n, qui attaque le bootloader de premier niveau de l'appareil : c'est quelque chose qu'Apple ne peut pas résoudre et nous permet de contourner ou de modifier tout ce qui vient après lui dans la séquence de démarrage. En utilisant cet exploit, il est possible de downgrader ces dispositifs exploitables pour toute les version pour laquelle vous avez vos informations TSS enregistrés.
Une autre possibilité vous permet de contourner le processus APTicket au moyen d'iOS 4, qui est antérieure à l'introduction de cette fonctionnalité. Ceci permet aux périphériques qui ont des informations TSS à la fois pour iOS 4 et iOS 5 de revenir à iOS 4 (même à partir d'iOS 6) momentanément, puis de mettre à niveau vers iOS 5. Il n'y a qu'un seul appareil, cependant, où cette question est importante : l'iPad 2. Les appareils plus anciens ont limera1n, et les nouveaux appareils n'ont pas iOS 4.
Enfin, pour les appareils exécutant iOS 5, nous avons la possibilité de restaurer n'importe quelle autre version de l'iOS 5. Ceci n'est valable que sur l'iPad 2, iPad 3 et l'iPhone 4S (en tant que dispositifs antérieurs ils sont exploitables avec limera1n et les périphériques iOS d'après sont sortis après 6 et ne peuvent donc pas utiliser iOS 5). Alors que l'iPad 2 est aussi le dispositif de la catégorie précédente, cela peut fonctionner, même si vous n'avez pas d'informations TSS iOS 4 sauvés.
La suite en dessous !