[MàJ] iOS 10 : un kernel non chiffré pour « optimiser les performances »
Oui, mais... pour combien de temps ?
Le 23 juin 2016 à 08h00
4 min
Société numérique
Société
L’un des mouvements les plus importants pour la sécurité dans iOS 10 est probablement passé inaperçu jusqu’ici : le kernel du système n’est plus chiffré en grande partie. L’éditeur n’a pas communiqué sur ce point, et si l’on peut y voir une erreur, il peut s'agir aussi d’une réelle volonté. Explications.
Le site Technology Review du MIT s’est penché sur une découverte que l’on n'attendait pas : au sein de la première préversion d’iOS 10, le kernel n’est plus chiffré, du moins en grande partie. Ses rouages sont donc exposés à l’air libre, permettant à tout un chacun d’en explorer la délicate mécanique. Si l’on part du principe que l’observateur a les connaissances techniques requises évidemment.
Il n’y a que deux explications possibles à une telle « révélation » : soit il s’agit d’une erreur grossière, soit d’un mouvement parfaitement calculé. Au MIT, la seconde hypothèse remporte les suffrages. Apple aurait très bien pu décider d’un tel changement pour que tout le monde, justement, puisse non seulement voir comment les choses se font en interne, mais pour y détecter d’éventuelles failles. C’est justement là tout l’intérêt.
La course aux vulnérabilités
Les failles de sécurité sont un sujet d’autant plus sensible qu’au-delà de leur exploitation par d’éventuels pirates, elles sont un puissant relai pour les forces de l’ordre et les agences de renseignement. L’affaire qui a opposé Apple au FBI en a montré tout l’intérêt : il a suffi que quelques « grey hats » proposent au Bureau d’exploiter une faille pour que l’agence saute sur l’occasion. Et non seulement la méthode a fonctionné, mais Apple n’a jamais pu obtenir les détails de la vulnérabilité.
Mais si les entrailles du kernel sont exposées, le nombre de failles découvertes ne risque-t-il pas d’augmenter ? Si, et c’est sans doute sur ce point que compte Apple : puisque tout le monde peut regarder, le nombre de failles rapportées à l’éditeur devrait augmenter plus rapidement que celui des brèches gardées secrètes. Car en plus des « white hats », hackers divers et chercheurs, les entreprises de sécurité devraient s’en donner à cœur joie.
Moins d'obscurité, plus de failles détectées ?
Il se pourrait également qu’Apple limite cette « ouverture » à la seule phase bêta. Que des failles soient détectées dans les préversions est moins problématique : tant que les signalements se font, les vulnérabilités ne devraient pas se retrouver dans la version finale prévue pour cet automne. Une fois cette dernière en piste cependant, il n’est pas certain qu’Apple souhaite continuer cette petite expérience.
Enfin, il est possible que la firme ait pris en compte certaines critiques formulées à son encontre sur la sécurité. Elle travaille essentiellement dans l’obscurité, comme l’a montré récemment le bulletin sur ses bornes AirPort. Il n’y avait ainsi presque aucun détail, le bulletin lui-même n’apparaissant que plusieurs semaines après la mise à disposition du correctif. Cette transparence n’aura cependant de réel intérêt que si elle se poursuit avec la version finale d’iOS 10. Dans le cas contraire, il s’agira seulement d’une opportunité de collecter des signalements de failles à moindre coût.
On signalera cependant qu'Apple ne possède toujours aucun programme de chasse aux bugs. Il n'y a donc, contrairement à ce qu'on peut trouver chez Google par exemple, de récompense financière quand une faille est découverte. Il ne faudrait donc pas que l'ouverture ait les retombées inverses, les grey hats ne les exploitant certes pas, mais les revendant au plus offrant.
[MàJ] iOS 10 : un kernel non chiffré pour « optimiser les performances »
-
La course aux vulnérabilités
-
Moins d'obscurité, plus de failles détectées ?
Commentaires (22)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 23/06/2016 à 15h01
Vu le prix d’une faille 0-day sur iOS, on peut comprendre la tentation des grey hats.
Si Apple veut de l’ouverture que cela ne soit pas juste pendant la période de développement
Le 23/06/2016 à 15h06
Non il n’est pas open source. Le kernel d’iOS est un fork de celui d’OS X, lui-même un fork de XNU.
Le 23/06/2016 à 15h29
Ok, merci pour l’info. C’est pas clair du tout sur les pages wikipedia de iOS et macOS.
Le 24/06/2016 à 07h39
Le 23/06/2016 à 08h04
Le souci de l’ouverture en phase béta, c’est sa période limitée. Un malveillant peut profiter de cette ouverture pour trouver plusieurs failles, se les garder sous le coude et voir si la version finale chiffrée les conservent ces failles.
Le 23/06/2016 à 08h11
Petite question naïve: est-ce que cela peut impacter la robustesse du chiffrement réalisé sur les données (récupération plus simple de la clé, etc.) ?
Le 23/06/2016 à 08h11
JAILBREAK OWIIIII
Le 23/06/2016 à 08h12
Apple a communiqué après coup à vos confrères de TechCrunch, c’est intentionnel pour les raisons suivantes : The kernel cache doesn’t contain any user info, and by unencrypting it we’re able to optimize the operating system’s performance without compromising security
Le 23/06/2016 à 08h13
Apple a précisé que c’était volontaire et pour des raisons de performance :
https://www.technologyreview.com/s/601762/apple-now-says-it-meant-to-open-up-iph…
Edit : Brrrrr.
Le 23/06/2016 à 08h27
Le 23/06/2016 à 08h43
Le 23/06/2016 à 08h45
Le 23/06/2016 à 08h46
Le 23/06/2016 à 08h53
Selon le principe de Kerckhoffs : « la sécurité d’un cryptosystème ne doit reposer que sur le secret de la clef ».
Autrement dit, un bon algorithme de chiffrement (par exemple AES) est un algorithme dont les mécanismes internes sont publiquement connus (ainsi que son implémentation !) et dont la seule inconnue est la clé (le mot de passe).
Si un algorithme de chiffrement est gardé secret (et il y en a), le jour ou celui-ci est découvert, la sécurité offerte par cet algo en prend un sacré coup !
Le 23/06/2016 à 08h53
Le 23/06/2016 à 09h12
C’est vrai, il existe des puces pour accélérer l’opération. Mais c’est faux, ça a quand même un impact sur les performances et sur l’autonomie, deux points complètement cruciaux sur un mobile.
C’est d’autant plus vrai quand on parle du kernel, puisque tout le système passe par lui in fine
Le 23/06/2016 à 09h21
Le 23/06/2016 à 09h34
Lapin compris…
Ça veut dire quoi un kernel “chiffré” ? Si le binaire du kernel est stocké chiffré dans la mémoire de l’iPhone, j’imagine que le bootloader a la clé de chiffrement et doit le déchiffrer au boot pour pouvoir le charger en RAM et l’exécuter (mais il ne serait donc plus chiffré à l’exécution).
Au passage, je pense donc que ça aurait pas un impact important sur les performances car cela concernerait juste les modules du kernel qui ne sont pas chargés au boot (et qu’il faut déchiffrer à la volée à l’exécution).
Ça ne serait donc pas plutôt que le code binaire du kernel était jusque-là obfusqué et qu’il ne l’est plus (auquel cas l’impact sur les performances doit être quasi-nul) ?
Le 23/06/2016 à 09h36
Je crois aveuglement tout ce que les autres me dis. Merci Apple d’ouvrir aux quatre vents l’un des système grand publique le mieux protégé.
Le 23/06/2016 à 11h22
Ah bon ? Ce n’est pas *BSD ? " />
Le 23/06/2016 à 13h19
« En retirant le chiffrement, nous pouvons optimiser les performances du système d’exploitation sans compromettre la sécurité ».
" />" /> GG WP EZ
" />
Le 23/06/2016 à 13h35
Euh ? Il est pas open source tout le système bas niveau chez Apple de tout façon ? Open source signifiant droit de voir le code source, mais pas libre, donc pas de modification / redistribution autorisée. En tout cas c’est ce que dit la page wikipedia : WikipediaIl y a même un dépôt Github : GitHubCeci dit le dernier commit date de fin 2015, donc ils publient peut-être les sources avec du retard par rapport aux versions en production.