Connexion
Abonnez-vous

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

Oui, mais... pour combien de temps ?

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

Le 23 juin 2016 à 08h00

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.

Commentaires (22)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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

votre avatar

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.

votre avatar

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

votre avatar







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;Merci pour vos éclaircissements&nbsp;<img data-src=" />


votre avatar

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.

votre avatar

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

votre avatar

JAILBREAK OWIIIII

votre avatar

Apple a communiqué après coup à vos confrères de TechCrunch, c’est intentionnel pour les raisons suivantes :&nbsp;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

votre avatar

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.

votre avatar







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.


votre avatar







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.


votre avatar







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.


votre avatar







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.


votre avatar

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 !

votre avatar







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.


votre avatar

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

votre avatar







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.


votre avatar

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

votre avatar

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

votre avatar

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

votre avatar

«&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=" />

votre avatar

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 :en.wikipedia.org WikipediaIl y a même un dépôt Github :github.com 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.

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

Fermer