[MàJ] iOS 10 : un kernel non chiffré pour « optimiser les performances »

[MàJ] iOS 10 : un kernel non chiffré pour « optimiser les performances »

Oui, mais... pour combien de temps ?

Avatar de l'auteur
Vincent Hermann

Publié dans

Société numérique

23/06/2016 4 minutes
22

[MàJ] iOS 10 : un kernel non chiffré pour « optimiser les performances »

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.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

La course aux vulnérabilités

Moins d'obscurité, plus de failles détectées ?

Commentaires (22)


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.


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.) ?


JAILBREAK OWIIIII


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


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.








zogG a écrit :



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.





En y réfléchissant c’était évident. Quand on voit l’impact du chiffrement sur les performances… On le voit sur les perfs des iPhones avant 5S.









Soriatane a écrit :



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.







Oui mais si il y a assez de gens “honnetes” pour faire la même chose, on peut parier sur le fait qu’un autre decouvre la meme faille et la reporte.









Loufute a écrit :



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.) ?







Ni plus ni moins que si le kernel etait chiffré. La sécurité par l’obscurité n’a jamais permis d’empecher des pirates de decouvrir et exploiter des failles.

Par contre, ca decourage tres vite les honnetes gens de reporter des bugs.









Loch a écrit :



En y réfléchissant c’était évident. Quand on voit l’impact du chiffrement sur les performances… On le voit sur les perfs des iPhones avant 5S.







Bof, je suis pas sur que ce soit si important que ca. Les CPU ont tous des circuits dédiés pour accelerer ce genre d’operation.



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 !








KP2 a écrit :



Bof, je suis pas sur que ce soit si important que ca. Les CPU ont tous des circuits dédiés pour accelerer ce genre d’operation.





Oui mais l’accélération aussi bénéfique qu’elle soit ne rend peut être pas l’opération transparente en terme de performance, et peut être d’autonomie.

Après, je pense que ca devrait permettre aux possesseur de terminaux moins récents de continuer à être sur des versions récentes sans trop d’impact.



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








KP2 a écrit :



Bof, je suis pas sur que ce soit si important que ca. Les CPU ont tous des circuits dédiés pour accelerer ce genre d’operation.





Oui depuis les proc 64bits qui ont une partie dédiée. C’est depuis l’A7 chez Apple, la génération S805/810 chez Qualcomm.



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) ?


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é.


Ah bon ? Ce n’est pas *BSD ? <img data-src=" />


«&nbsp;En retirant le chiffrement, nous pouvons optimiser les performances du système d’exploitation sans compromettre la sécurité&nbsp;».

<img data-src=" /><img data-src=" /> GG WP EZ





<img data-src=" />


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 :https://en.wikipedia.org/wiki/XNU



Il y a même un dépôt Github :https://github.com/opensource-apple/xnu

Ceci dit le dernier commit date de fin 2015, donc ils publient peut-être les sources avec du retard par rapport aux versions en production.


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


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.


Ok, merci pour l’info. C’est pas clair du tout sur les pages wikipedia de iOS et macOS.








KP2 a écrit :



Ni plus ni moins que si le kernel etait chiffré. La sécurité par

l’obscurité n’a jamais permis d’empecher des pirates de decouvrir et

exploiter des failles.

Par contre, ca decourage tres vite les honnetes gens de reporter des bugs.





&nbsp;

&nbsp;Merci pour vos éclaircissements&nbsp;<img data-src=" />