Kernel d’iOS 10 : les explications d’Apple ne convainquent pas tout le monde
À la grande surprise de tout le monde, les données du cache du kernel d’iOS 10 ne sont pas chiffrées. Suite à cette découverte, beaucoup se sont demandé s’il s’agissait d’une bévue d’Apple ou d’un acte volontaire. Chose rare, la firme de Cupertino a fini par s’exprimer sur le sujet et a déclaré que « le cache du kernel ne contient aucune information utilisateur, et qu’en le laissant déchiffré cela [nous] permet d’optimiser les performances du système sans compromettre sa sécurité ».
L'argument sur les performances n'a pas convaincu tout le monde, surtout pas le chercheur en sécurité, Stefan Esser, qui n'a jamais sa langue dans sa poche. Sur Twitter, il se demande pourquoi Apple ne chiffre pas les données du cache sur les systèmes 64 bits et le fait sur les 32 bits, qui sont pourtant plus lents et bénéficieraient sans doute plus d'une telle décision. Pour lui, Apple s'est tout simplement loupé et a publié ce communiqué pour sauver la face.
Est-ce que tout cela porte à conséquence ? Pas tellement selon lui. Si cela peut permettre à certains de mieux comprendre les mécanismes (et les failles) de sécurité d’iOS, cela ne change pas grand-chose pour les personnes malintentionnées. Selon lui, seuls les mauvais hackers n’avaient pas accès aux clés de déchiffrement permettant de lire les données en cache écrites par le noyau. La conséquence la plus importante sera peut-être l’évolution du prix de ces clés qui se vendent sous le manteau. Un argument déjà repris par un autre chercheur en sécurité, Jonathan Zdziarski, qui estimait cette semaine que cette méthode pourrait contribuer à affaiblir le marché de la "vente de failles".
Quoi qu’il en soit, il faudra voir comment la situation évolue au fil des bêtas. Stephan Esser estime qu’en matière de performances, une telle « décision » (si cela en est vraiment une) permettrait éventuellement aux terminaux iOS de démarrer un peu plus vite.
Stefan Esser a fait de nombreux travaux dans la sécurité iOS, il a depuis longtemps prouvé ses compétences, une simple recherche sur le net t'aurais permis de le savoir...
@iDuplo
+1
Mais c'est la question réthorique d'un adepte de Schopenhauer débutant: quand on ne sait pas comment traiter le contenu on attaque la personne... c'est pitoyable de bêtise.
Par contre dans le grand n'importe quoi qui tourne au sujet de ce sujet éminemment technique on commence a avoir de l'info.
Il n'est donc pas question de chiffrement du kernel, comme sur les systemes militaires, mais du chiffrement du cache, donc des données mise en mémoire pour accélérer le traitement.
Pourquoi Apple a auparavant chiffrer cette mémoire et plus maintenant. La réponse officielle c'est: «parce que cela n'expose pas la sécurité de l'appareil»
C'est recevable. Si les données en cache sont bien gérées il va être très difficile de les exploiter. Y a bien des virus de bas niveau qui s'attaquent aux cache des processeurs, meme certains qui passent sous les hyperviseur. Apres la question c'est de connaitre l'architecture de fonctionnement pour recuperer par exemple des cles déchiffrées en cache, mais de ce coté Apple utilise des "enclaves" et de la "randomisation" qui garantissent un haut niveau de securtité.
Et observer un cache bien utilisé ne permet pas de décortiquer le fonctionnement d'un systeme bien fait.
Par contre, le chiffrement a un cout, en temps et en énergie. Mais les processeurs disposent d'unité dédiées (des coprocesseurs intégrés) qui réduisent le temps de traitement.
Est ce que supprimer le chiffrement va faire gagner beaucoup en temps et en énergie: non pas sensiblement pour l'utilisateur. Par contre cela contribue a optimiser l'efficacité énergétique de la machine et a grappiller quelques minutes bien venues au niveau général.
Donc a l'inverse, si Apple dit vrai, le fait d'abandonner le chiffrage du cache, implique d'Apple a amélioré et audité ses systèmes de sécurité en amont et en aval et qu'il va être plus difficile de trouver des failles. Si Apple dit vrai...
Que le materiel et le logiciel et le discours d'Apple est une farce?
ou tout simplement en mettant a disposition tout ca les petits mongoles qui trouveront des failles les feront tournés encore plus rapidement et apple les bouchera deux fois plus vite ;-) un peu de logique voyons les amis. On ne laisse pas la porte grande ouverte à un voleur sans lui préparer une petite surprise.
Pour qu'un chercheurs, ne voient pas les plans à l'intérieur des plans, et nous au milieu de ces plans … il y a fort à parier que nous serions déjà intéressés, informés et formés pour nous faire un avis par nous même.
Pas mot de passe root par choix en utilisation quotidienne – Ce n'est pas le cas lorsqu'on a administrer du code serveur pour son déploiement, avec les outils de développement pour maintenir la sécurité et l'inviolabilité jusqu'au terminaux iOS.
Faire l'impasse sur le système de ré-écriture qui formellement re-copie le traitement à travers des caches d'entrées/sorties, vers d'autres couches communicantes de traitement nécessairement en dehors du champ du nouveau programme … naïf, serait une grossière approximation du mécanos déployé pour son exécution et de la trace qu'il laisse derrière lui.
Idéalement la démarche n'est pas des plus simples, car un maximum d'étapes sont confiés à des traitements tiers en mode boîte noire, sur lesquels on ne peut qu'envisager des situations de stress … improbables.
et bien si les device 32 bits on tjr un cache kernel chiffré c claire que qq dans Apple à oublier de le faire pour les devices 64 bits !
Tout cela va dans la meme direction que les versions ios/mac pleine de bug ou qui bloc les devices !! Je suis un fun d'Apple et dev iOS mais là ca devient ridicule..
@RedMak :
Ah bon iOS 10 fonctionne sur des bidules 32 bits ?
@marc_os :
Compatible avec l'iPhone 5 donc oui.
@RedMak
Non,
L'architecture des Ax 32bit et 64bit est différente, il peut y avoir des composants dans les versions 64bits qui sont plus efficaces pour chiffrer des éléments plus sensibles en aval et en amont et qui rendent le chiffrement du cache superflu.
Par contre, on voit aussi que le niveau de connerie de programmation est stupéfiant chez Apple avec le bug de l'horloge, toujours pas corrigé semble-t-il.
"On ne laisse pas la porte grande ouverte à un voleur sans lui préparer une petite surprise."
Ce n'est pas dans la politique d'Apple de laisser la porte grande ouverte, surtout aux voleurs.. mais pas tous sont estampillés officiellement "voleurs".
J'aime bien Esser, mais là il est complètement à la ramasse. Il essaie de faire croire que parce qu'apple fait un truc illogique, il a raison. Sauf qu'à pôle n'a jamais rien fait de logique. Et Apple à bien prouvé que le 32bits ne l'intéressait plus. Donc non, la franchement, il tire des plans sur la comète.
@Nesus :
Lol comme si Apple ne commettait pas d erreurs mdrrrr
Ne sois pas naïf voyons.
C'est bien là la question..
Personnelement, je ne crois pas à l'erreur notament à cause des évènements récents qui font qu'Apple a dû redoubler de vigilance sur le domaine du cryptage.. Je crois à la version délibérée.
Cependant si c'est le cas, elle a dû être sacrément réfléchi dans tous les sens tout en haut de la hierarchie.. je crois moins à une raison d'optimisation sans qu'il y ait une intention économique / politique plus lointaine qui ait fait pencher en faveur de ce choix. C'est juste mon opinion.. :)
Bah, le 32bit est sur la voie de garage, faut pas trop s'emballer non plus : ils restent sur des bases qu'ils maîtrisent et qu'ils ne devront bientôt plus améliorer.
Le 64bit par contre est au cœur (c'est là cas de la dire) de chaque nouveau produit iOS, la différence entre 32 et 64 ne m'étonne pas plus que ça. Stratégiquement c'est défendable. Après reste à voir si c'est juste un erratum d'Apple à propos d'une bourde ou tout simplement une bonne (?) idée…