tu generes une clef de la mort qui tue tout les combiens toi ?
ensuite un processeur pour l’armée ca doit etre dans les 50 roros surtout si tu en commandes des dédies pour ca.
une dizaine de clef puis hop tu le jettes.
Donc bon.
Mais apres l’utilisateur et la becane physique sont effectivement les points faibles. Je pourrais en raconter de bonnes la dessus d’ailleurs (comme la fois ou dans une tres tres grosse boite d’info medical on appelait les gens en leur disant qu’on etait le service info et qu’on avait besoin de leur mot de passe. Ou la fois ou on s’est pointé en tecos bleu de travail pour reparer l’electricité de la salle serveur et qu’on s’est barré avec les disques durs (on se faisait chier aussi)).
[quote=“Bussiere, post:21, topic: 31825”]tu generes une clef de la mort qui tue tout les combiens toi ?
ensuite un processeur pour l’armée ca doit etre dans les 50 roros surtout si tu en commandes des dédies pour ca.[/quote]
Je crois que tu n’as pas compris ce dont parle cette article. Ils parlent d’une “faille” qui permet à un processus espion en mode utilisateur et qui tourne en parallèle sur le même CPU de dévoiler plus ou moins la clé privée. Je ne vois pas en quoi jeter le CPU après utilisation apporte quelque chose…
Bah simple tu montes une becane coupée du net de tout reseau exterieur, tu generes tes clefs ensuite tu detruis le processeur.
Là le mec qui veut faire tourner un truc espion sur ta becane il l’a un peu dans l’os.
Et en detruisant le proc tu es sur qu’on ne pourra pas le reutiliser pour l’espionner ou essaie de trouver le mode de fonctionnement du proc pour intuiter sa clef.
Tu fais des machines one shot que tu montes et n’utilise que pour la generation de clef.
Si le proc est infecté hop tu vires l’infection a chaque changement.
Ca evite de générer des clefs pour tout tes agents et de te rendre compte qu’a la fin ton proc etait infecté
La si tu prends tu jettes ton proc tu prends deja moins de risque.
[quote=« Bussiere, post:25, topic: 31825 »]Si le proc est infecté hop tu vires l’infection a chaque changement.
Ca evite de générer des clefs pour tout tes agents et de te rendre compte qu’a la fin ton proc etait infecté
La si tu prends tu jettes ton proc tu prends deja moins de risque.
Bussiere[/quote]
Et l’écologie ? tu penses un peu à l’écologie ? B)
tssss
[quote=« Bussiere, post:25, topic: 31825 »]Si le proc est infecté hop tu vires l’infection a chaque changement.
Ca evite de générer des clefs pour tout tes agents et de te rendre compte qu’a la fin ton proc etait infecté
La si tu prends tu jettes ton proc tu prends deja moins de risque.
Bussiere[/quote]
Mais, euh, un processeur, ça ne contient que de la mémoire volatile non? A priori tu coupes le courant et ton proc est comme neuf?
J’avais étudié le principe de la prédictivité dans les proc, en gros c’est des statistiques : on sait que quasiment tout les calculs s’effectuent dans des boucles, donc quand on a un embranchement il y a une bonne chance que ce soit celui d’une boucle “for” ou “while”, et comme on boucle plusieur fois en général on dit que si un embranchement fait tel comportement une fois, il devrait le faire les fois suivantes.
Après ça permet de faire plusieurs opérations dépendantes les unes des autres sans avoir à stopper le proc jusqu’à ce que le résultat sorte du pipeline, on vérifie juste aux embranchement que la prédictivité soit juste, si oui on continue tranquillement, sinon on annule les opérations pour lesquelles on s’est trompé et on reprend à la dernière opération juste.
En gros lire la BPU, c’est lire la table où il y a les addresses des embranchement et avoir une idée de leur comportement dans la plupars des cas où on passe dessus.
Ok pour rajouter une couche par rapport à ce qui a été dit. Histoire courte: l’impact est complètement exagéré.
Explication:[ol]
[li]Cette attaque permet d’obtenir les éléments privés lors de calculs basés sur eux. Seul le serveur a les éléments privés de la clef dans une session SSL standard avec chiffrement RSA (pour du DH c’est autre chose, mais je ne pense pas que l’attaque puisse fonctionner dans ce cas);[/li][li]Il faut compromettre le serveur pour exécuter un programme dessus. Ouah j’ai hacké le serveur je peux prendre les clefs asymétriques! Bravo bonhomme, tu peux aussi prendre directement les numéros de carte bleues;[/li][li]Les clefs actuelles font au minimum 1024 bits. Si l’attaque est limitée à 512 bits ça fini d’anéantir le peu d’intérêt pratique. Je rappelle qu’on sait casser en temps raisonnable du 640-bit actuellement.[/li][/ol]Rien ne change suite à cette attaque, excepté la mise au point de nouvelles techniques de “sniffing”. Bref c’est intéressant pour les experts, sans impact pour les utilisateurs.
Le nombre d information passant par un processeur etant enorme et codé en binaire.
Il me parait difficile de recuperer une information precise et de la rendre exploitable avec un petit log sachant que cette info n est pas faite pour etre utilisable par autre chose que le processeur lui meme.
[quote=“Ronan, post:32, topic: 31825”]Le nombre d information passant par un processeur etant enorme et codé en binaire.
Il me parait difficile de recuperer une information precise et de la rendre exploitable avec un petit log sachant que cette info n est pas faite pour etre utilisable par autre chose que le processeur lui meme.[/quote]
Difficile mais possible. Il existait déjà des failles dûes à l’hyperthreading.
Si vous cherchez un peu, vous pourrez trouver une préversion du “papier” des gens. Leurs tests ont été effectués sur un Pentium 4, avec une vielle version d’Open SSL. Du coup l’impact est beaucoup trop largement amplifié, en grande partie parce que le journaliste de Le Monde n’a strictement rien compris à ce qu’il raconte et mélange beaucoup trop de choses.
En fait je me pose une question bête suite à cet article.
Voila j’ai un ADM DUAL CORE d’un génération donnée. Je peux donc supposer que tout les procésseurs de la même génération (même version de coeur) calculerons de la même façon.
Dès lors si j’ai le message crypté (normal sinon y a rien à décoder) ainsi que le soft utilisé par la destinataire pour le decrypter. Il ne me reste donc plus qu’à trouver la clé.
Je prends donc mon proc identique à celui de la personne qui a émis le message et je devine la clef via le procédé indiqué par anticipation des branchements que va faire le procésseur. Cela me semble réaliste et dans ce cas je n’ai absolement pas besoin de benéficier d’un accès sur la machine qui a émit le message non?
Je n’ai donc besoin que d’un panel de tout les procs existant, vu que le calcul de la clef me prends moins d’une seconde en moins d’une minute (le temps de lancer l’appli sur tout les procs B) ) j’ai la clef de cryptage du mesage.
Je dis n’importe quoi, ou il y a un semblant de verité dans ce que je dis ?
en fait, pour trouver la clef cette méthode se base sur les réactions du module devinant les réactions du processeur (notamment ses erreurs, et les cycles perdus lorsqu’il se plante), pendant que le dit processeur est en train de décrypter quelque chose avec la dite clef.
il n’y a aucune magie dans ce procédé, il faut déjà avoir la clef quelque part pour pouvoir la devnier. à mon sens il y a des methodes bien plus faciles à mettre en oeuvre pour un résultat similaire.
[quote=“Rabban, post:36, topic: 31825”]tu dis n’importe quoi.
en fait, pour trouver la clef cette méthode se base sur les réactions du module devinant les réactions du processeur (notamment ses erreurs, et les cycles perdus lorsqu’il se plante), pendant que le dit processeur est en train de décrypter quelque chose avec la dite clef.
il n’y a aucune magie dans ce procédé, il faut déjà avoir la clef quelque part pour pouvoir la devnier. à mon sens il y a des methodes bien plus faciles à mettre en oeuvre pour un résultat similaire.[/quote]
Merci c’est plus clair maintenant, et je comprends mieux les message au dessus qui précise l’inutilité de l’ampleur de cette niews.
