 Bonjour tout le monde, c'est un véritable plaisir de pouvoir parler dans cette conférence. J'attends la confirmation que le stream marche. Est-ce que ça marche ? Il y a un délai, on va à peu près tout. Ok, on dirait que je suis en live. Alors c'est vraiment super d'être ici, c'est génial de pouvoir parler dans cette conférence, le Divoque, digital C3Voq. Et je vais parler de la génération d'ombres aléatoires dans les puces Bluetooth. C'est quelque chose sur lequel j'ai travaillé avec Maté Dila. C'était Maté Dila qui était son sujet de thèse, de mémoire de master et j'ai continué ensuite. Et donc la question est donc comment est-ce que les choses fonctionnent en termes de qu'est ce que c'est des nombres aléatoires par exemple, à quoi ça ressemble quelque chose d'aléatoire. Par exemple, ce lapin que j'ai trouvé sur net peut vous donner quelque chose d'aléatoire, mais la vraisation c'est est-ce que c'est vraiment aléatoire. Si on regarde, on voit qu'il y a des paternes qui se répètent et ça c'est pas aléatoire. Et donc Maté Dila m'a demandé s'il pouvait faire son mémoire de master avec moi et à l'époque j'avais quelque chose comme une dizaine d'étudiants qui travaillaient sur des questions de Bluetooth avec moi et je savais pas trop quoi les donner parce que j'avais des gens qui bossaient sur Bluetooth sous l'inuc, Bluetooth sous ma quoi, etc. J'avais pas trop de sujets et ils me disaient je veux vraiment faire mon mémoire avec toi, est-ce que je peux avoir quelque chose. Et donc j'ai dit j'ai quand même ce truc sur les générateurs de nombres aléatoires, il faudrait vraiment que quelqu'un regarde ça. Et donc il a commencé cette thèse comme ça. Et donc la première question c'est pourquoi c'est intéressant de regarder les générateurs de nombres aléatoires. Si on regarde les specs du Bluetooth dans les specs il est écrit que le générateur de nombres aléatoires doit respecter les normes Philips parce qu'il est utilisé pour l'authentication, la chiffrement et pour d'autres choses qui ont un trait à la sécurité. Donc ce que ça veut dire en pratique c'est que la sécurité sera compromise si le générateur aléatoire n'est pas réellement aléatoire. Excusez-moi, je ne suis pas sûr que membol fonctionne. Ok, c'est bon. Donc le générateur de nombres aléatoires est très important pour tout ce qui est trait à la sécurité, pour le chiffrement, l'authentification et tous les autres aspects de la sécurité. Donc ça doit respecter les normes Philips, c'est-à-dire que ça doit satisfaire certains tests statistiques et la spec dit qu'il ne faut pas que on peut par exemple remplacer la fonction chat 1 par la fonction chat 256 et d'autres choses. Alors ce qui est important c'est que même si un générateur de nombres aléatoire satisfait un test statistique, ça ne veut pas dire qu'il a des défauts. Alors si il ne passe pas, si il ne satisfait pas la condition du test, il est certainement cassé, mais ça ne va pas parce qu'il passe avec succès à ces tests qu'il est fort cryptographiquement. Donc la question qui vient après c'est dans une puce Bluetooth quels peuvent être les sources d'entropie. Alors je peux demander à Malikorn, qui est ici comme toujours, et la question que je pose à Malikorn c'est comment obtenir de l'entropie ? Alors la question, la réponse peut être 42, qui est la réponse à peu près tout. Il y a aussi la mémoire accès aléatoire, dont vous avez sûrement entendu parler. Vous avez peut-être pas entendu parler de la random only memory ou quatrième option un générateur de nombres aléatoire dans le hardware. Donc je n'avais pas la réponse, Malikorn n'avait pas la réponse et donc j'ai demandé à l'Internet, j'ai demandé à Twitter, j'ai fait un sondage pour que tous les gens qui s'y connaissent en sécurité puissent me donner leur opinion et j'ai regardé les réponses. Alors 42 était la réponse à la plus populaire, mais les gens préféraient, d'autres préféraient un générateur de nombres aléatoire, d'autres préféraient la mémoire accès aléatoire et personne n'avait gêné en tout dans les random only memory, parce que c'est pas quelque chose qui existe. Donc comment ça marche en pratique ? Une des choses que m'a été leur encadée, c'était, il a pris quatre périphériques existants, le premier était Nexus 5 de chez Google qui est un périphérique sur lequel beaucoup de mes étudiants ont travaillé. Il y avait trois autres équipements que j'ai listés ici, parce qu'on a des informations, des symboles pour travailler là-dessus. Donc on n'a pas forcément d'informations très complètes, on a peut-être juste quelques strings, mais c'est mieux que rien. Et donc dans ces quatre devices, il a déjà pu trouver deux variantes. Les deux premiers ont un générateur de nombres qui est in-liner et pas de cache, la deuxième variante, certains ont un cache et d'autres ont des fixes dans le software pour changer ce générateur aléatoire dans une autre fonction. Alors à quoi ça ressemble en pratique ? Donc ça marche comme ça aussi pour la variante numéro 3 avec le générateur aléatoire. Donc d'abord, ça vérifie si le générateur aléatoire est disponible, si il est disponible. On regarde, est-ce qu'il a un nouveau nombre à nous donner. Alors on appelle le watchdog avant parce que la génération nombre aléatoire peut prendre un moment. Donc on ne voit pas que le watchdog soit s'activer et nous interrompre pendant qu'on attend pour un nouveau nombre. Donc c'est un algorithme très simple, juste on bloque, jusqu'à recevoir un nouveau nombre aléatoire. Donc on ne sait pas vraiment d'où viennent ces nombres, ils sont un peu magiques. Mais ça c'est comme ça que ça marche globalement. Le générateur de nombres pseudo aléatoire est bien plus intéressant parce que lui prend plusieurs valeurs dans le disponible système. Par exemple on prend l'horloge Bluetooth qui est partagé pour la communication entre plusieurs membres de la communication Bluetooth. On prend aussi une horloge qui est utilisée par le système qui fait tourner la puce et d'autres valeurs qui sont dans des buffers ici et là. Et on passe ça globalement à CRC32 pour obtenir juste quatre optets et on dit qu'il y a assez d'entropies dans ces 7 éléments pour générer un nombre aléatoire. Donc les deux variantes, que ce soit le générateur aléatoire ou le générateur pseudo aléatoire, les deux ont à peu près la même API. Une chose qui est intéressante quand même, c'est que le générateur pseudo aléatoire a besoin d'être initialisé, mais c'est à peu près la seule différence. Alors ça ça peut avoir l'air bizarre et c'est pas quelque chose qu'on aime bien, qu'on ne voit, parce que les entrées qu'on a là-dedans, on peut être prédictibles à utiliser des horloges, c'est très facile à prédire et CRC32, c'est pas forcément quelque chose de très robuste. Donc on a fait quelques mesures. Donc vous avez ici des histogrammes et chacun de ces histogrammes a des valeurs de 0 à 255. Donc pour l'horloge Bluetooth, c'est juste un octet parmi les quatre et on peut voir que les valeurs basse sont beaucoup plus fréquentes. La seule chose qui est vraiment l'air aléatoire là- dedans, c'est ce qu'il y a dans l'histogramme H en bas à droite, qui est la dernière valeur aléatoire. Donc c'est c'est l'anthropie, la seule entrepied final que le PRNG, le générateur pseudo aléatoire, obtiendrait. Et donc ça, c'était la fin de son mémoire et on a signalé ça à Broadcom et donc on a demandé à Mitra de nous donner une CVE et on a obtenu ce numéro de CVE puis on l'a envoyé à Broadcom et Cyprus et leurs clients, parce que Broadcom peut mettre très longtemps des semaines à répondre et ils ne fournissent pas forcément les CVE et il ne fournissent pas forcément d'identification du bug. Donc si moi je ne fais pas l'effort d'admenter une CVE, j'ai aucun moyen de suivre l'évolution de cette vulnérabilité. Alors c'est un peu bizarre pour les clients de Broadcom, parce qu'ils pourraient s'attendre, parce que Broadcom fournissent une CVE, mais non. Donc on a fait une responsible disclosure, on a signalé le bug de façon responsable à Broadcom en demandant pourquoi est-ce que vous vous introduisiez ce générateur pseudo aléatoire alors que vous avez un générateur aléatoire qui marche bien. Et la réponse était mais pourquoi est-ce qu'on devrait utiliser ça et ça donne un peu un dialogue de sourd dans lequel tout le monde dit, oui il y a eu une problème mais personne ne peut dire quel est le problème. Et au final Broadcom a fini par conclure. On n'utilise jamais le générateur pseudo aléatoire, il n'y a pas de problème. Le PRNG n'est pas utilisé, il n'y a rien à voir. Et donc pour Mathédéleur c'était la fin de son mémoire de master et donc ça a été la conclusion. Voilà c'est la fin. C'était la fin seulement en termes de tout va bien, tout le monde est heureux, tout est sécurisé, il n'y a aucun problème nulle part. Ce qui est intéressant ici c'est qu'un de mes autres étudiants qui avait, un autre étudiant va pouvoir prendre beaucoup de temps pour vous expliquer l'exécution de code à distance. Sauf que ça c'est qu'une partie de la vérité. C'est pas vraiment la fin. Parce que bien sûr j'ai regardé ce qui se passait dans d'autres équipements parce que dans ces autres équipements si y a ce PRNG sur lequel le système peut se rabattre dans certains cas et le code peut changer avec le temps donc il y a sûrement d'autres choses à trouver intéressantes. Et on a aussi décidé de faire des mesures sur le générateur aléatoire en hardware et en utilisant la suite de tests die-harder c'est une suite de tests qui a besoin d'extraire un giga aux têtes de données. Donc on a pris ce device et il n'est pas vraiment rapide pour extraire autant de données. Donc qu'est ce qu'on a fait ? Alors d'abord il faut essayer de trouver un gros espace vide en mémoire dans la puce. Alors ça dépend des puces. Il y en a qui ont de plus ou moins grosses régions utilisables. Et puis il faut faire attention parce que ce n'est pas parce qu'une région en mémoire est marquée comme free. Ça veut juste dire qu'elle n'est pas utilisée à leur accueil par un autre processus mais ça peut changer. Donc je faisais des tests uniquement sur 5000 bytes, enfin 5000 en hexadecimal. Et j'ai aussi désactivé la fonction originale RBG RAND. J'ai désactivé le juste sonnerre d'événement HCI qui n'est pas de polling possible pour que rien ne puisse m'interrompre. Et enfin j'ai enregistré aussi un octet test 0x42 qui me permet de vérifier si quelque chose d'autre écrivait sur cette zone en mémoire. Donc désactiver le gestionnaire HCI c'était important parce que dans certains de mes devices j'étais interrompu tout le temps. Et il a aussi fallu corriger un bug dans certains de ces devices notamment le Nexus 6p iPhone 7. Launchram avait un bug qui causait des écritures sur cette zone de mémoire. Donc j'ai pu extraire quelques octets depuis ces CPS. Et puis c'est juste des données latoires donc on s'en fout. J'ai mis ça sur Google Cloud et ça m'a déconnecté de Google Cloud. Ce qui est un petit peu bizarre. C'est pas quelque chose que je fais d'habitude d'éploader beaucoup de données là-bas. Donc Philippe m'a dit la prochaine fois que j'ai upload ça je n'entais pas l'appeler randomdata.bin. Je vais peut-être l'appeler un petit backup.bin. La raison pour laquelle il y a autant de données pour le Nexus 5 c'est parce que j'ai pu faire un gros backup de ces données. Donc les données qu'on a déjà recette le giga octet pour le Nexus 5 et parfois juste 1,2 giga octet pour certaines bandes d'évaluation. Et donc les tests de Diodeur sont, ont été passés avec succès, pas de problème. La raison pour laquelle il y a moins de données dans certaines CPS c'est que c'est des CPS qui sont beaucoup plus lentes ou qui ont beaucoup moins de mémoire. Par exemple sur LiveMac de 2009 c'était le cas ou sur le Samsung Galaxy S10 ou sur l'iPhone 11. C'était difficile, il fallait écrire du Bluetooth à la main puisque les outils que j'utilise ne supportaient pas ces puces là. Donc il fallait que j'écrive vraiment les octets un par un. Mais mes tests ont quand même montré que ça appelait correctement le générateur de domes relatoires dans le hardware. Alors on peut vérifier physiquement que le générateur relatoires hardware change quand une nouvelle valeur est requise pour le protocole Bluetooth. Donc j'ai pas collecté de données mais j'ai quand même quelque chose qui me dit que ça utilise le générateur relatoires hardware. Alors c'est bien ça mais le firmware c'est juste un binaire et trouver les variantes ou trouver ce qui change d'une puce à l'autre c'est très difficile parce que à chaque fois que vous faites une erreur en essayant de trouver le code assembleur ou si vous trouvez la mauvaise instruction, chacune de ces erreurs a créé une erreur dans le graph qui représente le code. Et si votre assembler est un peu plus agressif comme Amnesia par exemple, vous aurez des choses qui ne sont pas forcément utilisables. Si vous utilisez AIDA 6.8 ou si vous utilisez Gaidra vous avez des compilations un peu agressives, ça trouve des instructions ARM un peu trop facilement mais ça crée trop de faux positifs. Donc un de mes étudiants a essayé un autre outil qui n'essayait pas de désassembler, qui fait des diff directement au niveau binaire. Ce sera disponible bientôt mais j'ai pas pu utiliser ça non plus puisque si vous avez des options de compilations différentes et ça c'est quelque chose qui peut arriver si vous avez des versions de firmware qui ont été compilées à des moments différents avec des compilateurs probablement différents au fil du temps, vous aurez des builds différents même si le code assemblant aurait pu être le même. Donc ça rend les choses difficiles quand on cherche les différentes variantes de firmware. Donc la première variante qu'on peut identifier c'est celle qu'il y a dans l'IMAC 2009 et dans un dongle USB chez ASUS. Dans cette variante c'est bizarre parce que ça se base uniquement sur la clock qui s'incrémente avec le temps et c'est tout. Donc ce générateur pseudo aléatoire est vraiment très mauvais mais je n'ai pas l'impression que ce soit utilisé dans des périphériques plus modernes. Donc il y a beaucoup de chips à des variantes 2 et 3 donc c'est une généreterre pseudo aléatoire que je vous ai montré tout à l'heure. Une chose qui change c'est l'adresse à laquelle est mappé le registre du générateur de nombre aléatoire hardware. Donc ça ça a changé avec le temps, avec les versions mais les données qui sont dans le firmware qui est compilé pour le chip n'indique pas forcément où est réellement le le registre. Et il y a aussi la variante numéro 5. La variante numéro 5 celle qu'on peut trouver dans l'iPhone 11 et mais aussi dans l'iPhone 8, X et XR. Je ne sais pas ces variantes là sur le iPhone XS. On le trouve aussi sur les Samsung Galaxy S10 et S20 et donc ces variantes sont une réécriture complète de la librairie de générations pseudo aléatoires. Ça utilise un cache asynchronous mais cette librairie est toujours utilisée de la même façon. Donc ça utilise toujours les appels que je vais montrer tout à l'heure dans le graphe d'appel. Et donc ce qu'ils ont fait c'est qu'ils ont déplacé le générateur de nombre pseudo aléatoire. C'est toujours difficile de déchiffrer ça parce que c'est toujours difficile de transister dans un informat. Mais il semblerait que dans ces versions ils aient carrément désactivé le générateur de nombre pseudo aléatoire en software. Et donc ça veut dire que s'il y a un problème avec le générateur aléatoire hardware il n'y a pas d'alternatives. Alors j'ai fait l'impasse sur la variante numéro 4 et dans la variante numéro 4 ils ont oublié d'inclure un générateur de nombre aléatoire. Oups. Donc c'est pour ça que je l'ai appelé la variante numéro 4. Ça rappelle un peu le bug des nombres aléatoires sur DBian qui a donné lieu à cet excellent XKCD. Donc si on regarde sur ce périphérique dont je n'ai pas nommé, qui utilise la variante 4, on a un système qui ressemble à la variante numéro 2. C'est à dire qu'on a la valeur aléatoire précédente. On a deux clocks et on a deux entrées qui sont basées sur des signaux. Donc la clock vous pouvez voir c'est une mesure que j'ai fait sur 15 minutes. On peut regarder le clock Bluetooth et la clock hardware. La clock hardware commence à ffffffffffffff et converge vers 0. La clock Bluetooth elle s'incrémente. Alors elles sont corrélées. Mais elles peuvent être recettes à des moments différents. Donc il faut quand même pour un attaqueur, quelqu'un qui s'attaque à ce type d'eau, à ce générateur pouvoir deviner la clock hardware du système. Si on arrive à cracher à distance la puce Bluetooth, la clock sera remise à FFFFF. Donc ça, c'est triste parce que ça veut dire qu'une attaque qui peut juste cracher la machine à état de la puce Bluetooth, qui n'est pas un bug d'accès aux mémoires, qui n'est pas un bug d'exécution à distance, juste un bug qui crache et déjà un bug qui permet de diminuer l'entrepi du générateur pseudo-léatoire. Donc on a aussi des entrées qui viennent des processeurs de signaux. On a ici donc DCFH out, qu'on peut grapher en tant qu'histogramme au fil du temps. Donc vous pouvez voir l'histogramme à gauche et à droite vous pouvez voir ce à quoi ça ressemble au fil du temps. Et c'est pas parfaitement lisse, mais on peut voir qu'il y a un pattern qui ne se répète clairement avec le temps. Donc c'est certainement pas une entrée qui a l'air très aléatoire. Et on a deux autres entrées. La première, c'est RxInitAngle. Vous pouvez voir l'histogramme à gauche. Et le deuxième, c'est AGC status. Donc le premier, c'était une mesure où la valeur changeait tout le temps. Et l'autre, c'était essentiellement zéro et quelquefois une autre valeur. Ce que ça veut dire, c'est que ces deux générations ne sont pas aléatoires. On peut voir à gauche que par exemple zéro est beaucoup moins présent. Donc comme ces entrées ne sont pas aléatoires, ça peut rendre l'attache beaucoup plus facile pour quelqu'un qui veut essayer de deviner le prochain nombre aléatoire. Alors, la question qui se pose après, c'est pourquoi est-ce qu'on a arrêté de faire cette recherche après 17 plus différente? Bah tout simplement parce que 17 est le nombre le plus aléatoire. Vous vérifiez sur Internet qu'il y a plein d'études qui montrent que 17 est bien le nombre le plus aléatoire. C'était la devise d'un Easter egg il y a quelques années. Et donc quelque chose d'intéressant s'est passé. C'est qu'un des clients de Broadcom a devenu un petit peu nerveux et a dit, est-ce que je peux demander à Qualcomm? Parce que peut-être aussi que l'or plus à eux sont ce genre de problèmes, non? Alors, moi je dis, vous pouvez leur dire. Nous on n'a pas fait de tests, on n'en sait rien. Ils ne vont probablement pas nous le dire si ils ont des bugs comme ça. Je vois pas pourquoi ce qu'ils vous le direaient non plus si ils ont des bugs comme ça. Mais bien sûr, vous pouvez leur demander si cette boîte noire magique qui génère des nombre aléatoires s'y allait casser ou pas. Donc ils ont demandé, ils nous ont donné quelques réponses que je ne peux pas montrer ici. Et ensuite ils ont donné une autre réponse que je peux montrer ici. La réponse est qu'ils n'ont pas trouvé d'indication que leurs implementations du Bluetooth avaient des problèmes similaires pour leur générateur de nombre pseudo aléatoire. Donc ils disent, pour nous on pense que notre aléatoire est parfaitement sécurisé. Mais ça c'est quelque chose qu'on ne saurait pas à moins de faire des mesures comme ça. Donc, est-ce que c'est vraiment sûr, allez savoir. Alors, c'est quoi l'impact de tout ça? Donc il y a cinq variantes. Et dans toutes ces variantes, la fonction RBG RAND est appelée de la même façon. Ça, ça veut dire qu'il y a une variante dans laquelle pardon, n'est pas appelée de la même façon, je sais quoi. Dans une des variantes, cette fonction est frappée dans une fonction SHAGET128B RAND qui extrait 16 octets. Donc ça appelle RBG RAND et ça met ces octets dans un point H-SHAF. Et ça, ça le fait dans une boucle. C'est un point prédictif en termes de timing puisque les appels à RBG RAND vont être fait de façon consécutive. Et ce qu'on a pu voir, c'est que les valeurs tendent à être similaires au fil du temps. Donc il est très probable que la même valeur ait été utilisée à chacun des rounds. Donc on a une autre variante, ILP en score RAND. Ça c'est pour ultra low power, très basse consommation électrique. Ça s'appelle juste RBG RAND et ça vous donne directement l'état de la valeur précédente comme valeur de retour. La valeur aléatoire générée précédemment. Donc ça, c'est utilisé pour générer les IV, les vecteurs d'initialisation de la crypto, ce qui veut dire que les nombres aléatoires sont directement transmis à des pairs sur les ondes. Si on fait une attaque de money in the middle d'hommes du milieu entre deux périphériques, normalement ce protocole empêche ce genre d'attaque par avoir une promesse, un commitment sur un nombres aléatoire qui est ensuite révélé. Donc ça ça permet de dire moi je promets que j'ai la clé pour un coffre. Je vous donne le coffre et je m'engage à quelque chose mais je ne vous dis pas à quoi et plus tard je divule ce que j'avais. Ça c'est une propriété qui garantit l'absence d'interception mais uniquement si les nombres aléatoires utilisés par les pairs ne peuvent pas être prédits. Si l'attaquant au milieu peut prédire les nombres aléatoires, il peut honorer cette promesse sans avoir besoin de connaître le nombre secret du périphérique BAC. Donc j'ai regardé ce qui se passe dans Android. Alors ils ont eu une bonne idée. Si la puce Bluetooth respecte FIPS, ça veut dire si la puce Bluetooth respecte la nombres FIPS, ça veut dire que la puce sur ce périphérique Android est une source de nombres aléatoires qui est sûre. Donc c'est très bien d'utiliser ça pour le résistème puisque c'est certifié et Android fonctionne sur beaucoup de périphériques et vous savez pas, si vous faites ton Android sur un périphérique pas cher, peut-être qu'il n'y a pas de générateur aléatoire qui vient donc. Si on a un générateur Bluetooth qui certifie FIPS, autant utilise ça comme source de nombres aléatoires. Et ce que vous pouvez voir dans cette trace Wearshark c'est que la fonction LE RUND qui appelle le générateur aléatoire et va gérer RUND directement est appelée quatre fois de suite et encore deux fois après. Donc ça, ça génère une clé elliptique privée puis publique et la deuxième série ici est envoyée directement sur les zones. Vous pouvez regarder ça directement dans le code Android aujourd'hui. Ce que ça veut dire ici c'est que si vous avez un générateur aléatoire qui est cassé, les clés privés qui sont initialisés directement par ce générateur aléatoire vont être publiés sans qu'il y ait même d'attaques manu de middle active. Simplement le fait de pouvoir observer les autres nombres qui sont envoyés sur les zones ça permet de deviner l'état précédent du générateur aléatoire et donc de deviner les clés qui ont été générés localement sur le périphérique. Donc la question est, est-ce que ça va être patché? Alors, j'ai volontairement pas donné le nom de ce périphérique puisque celui-là n'a pas été... ça fait moins de 90 jours que j'ai reporté que j'ai signalé ce bug mais le problème c'est que ni Broadcom ni leur client ne peuvent nous donner le patch en avance ils vont même pas nous donner le binaire ou quoi que ce soit. Donc moi je vais régulièrement sur les sites des fournisseurs de matériel et je regarde est-ce qu'il y a une mise à jour qui adresse la CVE que j'ai eue sur Mitra et si oui, je peux me dire ok peut-être que je peux reverse engineer le patch mais si il n'y a pas le numéro de la CVE que j'ai eue attribué à ça ça va probablement dire qu'ils n'ont pas corrigé le problème. Donc je vais pas faire une... je vais pas regarder les mises à jour tous les mois de tous les périphériques parce que c'est énormément de travail de faire du reversant de générique pour tout je vais juste attendre qu'une mise à jour soit publiée qui annonce officiellement une correction de ce bug donc ça fait plus de 90 jours que j'ai annoncé ça ça fait même... et je me suis dit même attendre 2 semaines de plus ne changera pas grand chose à ça on va attendre de voir comment ça va se passer mais personnellement je ne pense pas qu'il y aura un patch à temps donc... qu'est-ce qu'on peut retenir de ça ? d'abord ne pas faire confiance à un générateur de nombreux aléatoires embarqués c'est peut-être simplement un mauvais générateur pseudo aléatoire qui ne passe pas avec succès les tests statistiques la sortie... si on regarde la sortie d'un nombre d'aléatoires peut-être qu'on peut se rendre compte que c'est pas sûr même si c'était garantie comme étant sûr et quelque chose d'intéressant aussi c'est de voir chez Broadcom à quel point se faire moir à plus de 10 ans et que chaque version il y a des bugs différents et qu'il faut être capable de comprendre chacun de ces bugs pour pouvoir extraire les données c'était quelque chose d'intéressant dans ce projet beaucoup de travail, m'intéressant et donc maintenant aussi bien sûr Mathedieler pour avoir survécu à son mémoire avec moi et à Félix qui s'est occupé de toutes ces choses en crypto que moi je ne comprends pas merci aussi à Mathias, mon boss qui m'a permis d'acheter un smartphone et un autre smartphone et encore un autre smartphone merci aussi à Jacob qui a rendu possible qui a rendu possible et qui a fait d'utiliser des périphériques comme ça à distance et merci aussi aux gens qui ont relu notre publication à la dernière minute merci à Mathias et à Maximilian puisque bien sûr les papiers sont toujours publiés à la dernière minute et donc merci à eux pour leur lecture rapide c'est ainsi c'est tout pour ma présentation vous pouvez poser des questions il y a un pad hier c'est et je vais répondre aux questions c'est que je les aurais alors juste une minute est ce que vous voyez maintenant en grand j'espère alors les questions la première question oui vous pouvez uniquement m'entendre sur live stream c'est pas grave je peux déjà lire les questions donc pas de soucis alors je peux entendre les questions et les gens qui me parlent sur le mumble mais vous ne pouvez pas m'entendre sur le mumble mais vous pouvez m'entendre sur le live stream ici vous avez des questions pour Yesta vous pouvez les poser sur di.c3voc.de la première question alors la première question est ce que on peut accéder au cpu principal à partir d'un exploit dans la puce bluetooth la réponse c'est c'est compliqué c'est difficile de donner une réponse complète mais donc donc les gens demandent est ce qu'il y a un exploit qui permet de passer de la puce bluetooth à l'os globalement alors d'abord à beaucoup de drivers et notamment les plus intéressants depuis l'iphone xs et l'iphone 11 sur cpu aphirique la puce bluetooth est attachée en pc express donc c'est quelque chose intéressant les gens demandent aussi combien d'entropies il y a non c'est pas vraiment aléatoire on a juste la cloque on a peut-être un octet d'aléatoire mais on ne peut même pas c'est même pas dit que l'intégralité de cet octet soit utilisée donc c'est clairement un niveau d'entropie qui est dans la zone qu'on peut pour forcer autre question comment est-ce que j'ai pu accéder avec l'iphone 11 éternal blue marche très bien par exemple ici j'ai cet iphone 6 sur l'iphone 6 avec ios 12 et aussi ios 13 on peut juste utiliser éternal blue et jailbreaker le téléphone et ça permet d'accéder du coup à la puce bluetooth directement non non non éternal blue pardon éternal blue pas éternal blue éternal blue pas éternal blue est-ce que ça a quelque chose à voir avec les applications de tracking pour le covid 19 le coronavirus qui utilise le bluetooth alors non on n'a rien à l'heure actuelle ça serait cool de trouver des attaques mais à l'heure actuelle si on publie un exploit ce serait pas génial parce que le bug n'est pas corrigé et il y a des enjeux importants pour l'instant on se contente de publier nos mesures les mesures qu'on a prises alors la question suivante combien d'argent pourrait être économisé par les fabricants si ils se contentaient s'ils n'incluent pas un générateur normalatoire de qualité non la réponse c'est ils ont pas le choix en fait c'est requis d'avoir un générateur normalatoire correct alors il est possible que sur les smartphones dans lequel il n'y a pas un générateur normalatoire de qualité c'est possible qu'il y en ait un mais que simplement il ne soit pas utilisé je pense pas qu'il y ait de fabricants qui activement décident de ne pas mettre de générateur normalatoire par économie d'argent est-ce qu'on peut faire des tests statistiques plus précis alors Dyerder est déjà une très très bonne suite de tests statistiques le problème est simplement que si vous avez un nombre un générateur normalatoire et que vous ne connaissez pas les entrées la sortie aura l'air très aléatoire mais ça veut pas dire que le générateur lui-même est aléatoire et si les entrées sont prévisibles toute la sécurité c'est cool pourquoi avoir publié dans cette conférence et pourquoi ce qu'on n'a pas publié sur archive ou quelque chose parce que on inclut les modèles du téléphone donc quoi ? la question suivante est très bonne travail et qu'est-ce que la Alicorn pense de tout ça ? alors la Alicorn est à nouveau sur le stream vous dites bonjour à tous ok, prochaine question alors comment est-ce qu'il pourrait corriger le générateur d'un nombre pseudo aléatoire en utilisant les autres sourds disponibles alors je ne sais pas c'est difficile, c'est pour ça que je leur ai demandé comment est-ce que vous allez corriger ça et ils ont juste répondu on va le faire, on va corriger ça et ça c'est un problème récurrent en matière de patching et c'est un vrai problème parce que je ne sais pas quand ni comment ce problème pourrait être corriger j'en ai pas la moindre idée donc est-ce que je peux expliquer ce que c'est la random holy memory c'est la random access memory la RAM, mémoire accélératoire peut-être que non peut-être qu'il y a une random only memory comme la ROM la mémoire c'est un problème c'est un problème c'est un problème c'est un problème c'est un problème c'est un problème c'est un problème la random only memory comme la ROM la mémoire morte c'était juste une blague à propos de où est-ce qu'il pourrait trouver une source d'entropie qui pourrait utiliser une autre question pourquoi est-ce qu'il n'y a pas d'enregistrement dns spf à jour sur le domaine bluetooth dot lol bluetooth dot lol pardon honnêtement je sais pas, j'ai juste j'ai juste des trucs dessus et donc dernière question pourquoi est-ce que l'alicorn a une antenne sur sa sur sa corne alors c'est la controverse éternelle est-ce que un chapeau en papier d'allu prévient les radiations et les empêches d'atteindre votre cerveau ou est-ce qu'au contraire ça les concentre en l'occurrence ici je pense juste que c'est plutôt stylé d'avoir ce chapeau comme ça donc voilà c'est sympa là vous pouvez sûrement mieux le voir sur cette angle-là c'est un magnifique chapeau en papier d'allu que mon ami a fait pour malicorn ok je pense que c'est tout pour les questions ok super eh bien s'il y a plus de questions à moins que quelqu'un me pose des questions sur membol maintenant sinon on peut arrêter ici et rendre la main à Yann