Si il à bien compris... Il parle de la façon dont traite le processeur les infos qu'il recoit, en outre les clefs de cryptage...

Seul souci : "Un petit logiciel "taupe" pourrait donc écouter la puce en toute discrétion, et renvoyer la clé à des hackers, à des services de renseignement ou à des espions à la solde de concurrents."

Mais voilà si le logiciel taupe est déjà sur la machine à Pirater, c'est qu'elle est déjà piratée !???

...plouf !

Software is like sex !
It's better when it's Free !

Poste le Saturday 18 November 2006 19:01:09

Je rajoute un bémol à mes dire....
Je ne sais pas comment fonctionne les processeurs, et donc la façon dont ils gèrent ses flux !

Software is like sex !
It's better when it's Free !

Poste le Saturday 18 November 2006 19:02:28

J'ai lu l'article (sur papier), et je n'ai pas compris les détails.

L'article semblait dire qu' en mesurant avec précision le temps d'exécution d'une routine de cryptage, et compte tenu du comportement des unités de branchement, on pouvait en déduire la clef. Il semblait donc évoquer le processeur de nos simples PC accédant à des sites cryptés.

J'ai du mal à gober l'argument. Je veux bien qu'en mesurant ce temps on apprenne quelque chose sur la clef (càd qu'on en réduise l'espace combinatoire, donc qu'on trouve quelques bits), mais j'ai du mal à comprendre qu'on puisse la trouver en totalité, car il y a probablement bien moins de temps d'execution différents (ils sont tous multiples du cycle d'horloge, par exemple 2,4GHz) que de clefs.
(mon intutition, c'est que l'espace des durées possibles, quelques millions ou milliards de durées différentes -certainement moins que 2[^]35[/^] , à la nanoseconde près, est bien plus faible que l'espace des 2[^]108[/^] clefs; il y aurait donc beaucoup de clefs dont la durée d'encryption est exactement la même.).

Mais je ne suis pas du tout spécialiste de cryptographie ou de microarchitecture. J'ai juste des vagues notions (càd un vernis culturel) dans ces deux domaines.

De manière générale, je me méfie des articles sensationnels.


----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Saturday 18 November 2006 19:10:30

Il y aurait peut-être une faille dans mon raisonnement, car on pourrait itérer l'argument, et trouver petit à petit des bits...


C'est confus dans ma tête.... car les explications sont trop vagues dans l'article du Monde (et car je ne suis pas cryptologue).

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Saturday 18 November 2006 22:19:22

Le papier scientifique est ici [eprint.iacr.org]

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Saturday 18 November 2006 23:12:35

Oui, tout cela aussi je l'ai compris, mais ce qui m'interroge, c'est qu'elle type de transaction est prise en compte par ce type de 'cassage de clé' ? Le titre laisse entendre que ce sont les transactions via internet qui sont en cause, mais si c'est le cas, aucune de nos transaction via internet n'utilise la puce de notre carte bancaire, et le cassage de la clé ne peut donc être que la clé de communication entre le client et le serveur. Et il me semble que le temps de traitement de la clé est faible (voir négligeable) devant les vicissitudes d'une communication internet et donc mesurer le temps de traitement de la clé à distances est donc fatalement faussé par la communication elle-même.

Je dis n'importe quoi ?

Poste le Sunday 19 November 2006 10:54:58

La clé cassée ne serait pas celle de la carte bancaire, mais celle de l'encryption SSL.

Si les faits sont avérés, un petit soft pourrait casser une clé rapidement.
Le temps mesuré est le temps processeur consommé par le cryptage, et est donc indépendant des I/O.

Pour être cassée, il faudrait que l'utilisateur lance le logiciel espion avant de faire sa connection SSL.
Un tel soft pourrait être installé facilement dans un crack_windows_vista.exe.

Et sous Linux? Même problème. A partir du moment où c'est un processus utilisateur qui tourne, la sécurité est plus difficile à mettre en oeuvre.
Les utilisateurs ont le droit de lecture pour la majorité des fichiers de /proc (dont le /proc/pid quelque soit l'utilisateur. Il est donc éventuellement (je ne suis pas assez compétent dans la matière pour être 100% affirmatif), possible de récupérer la clé de n'importe quel utilisateur.
Pour avoir un peu plus de sécurité, il faudrait que ce soit un autre utilisateur dont la seule fonction est de lancer le navigateur web (oudoubahweb par exemple). Ainsi, une "attaque" en passant par une page web vérolée n'aura pas d'incidence (pas de modification du .bashrc par exemple). Ensuite, c'est à l'utilisateur de savoir ce qu'il installe (utilisation exclusive de code source et de repository sûrs).

Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"

Poste le Monday 20 November 2006 12:07:28

Donc si je comprends bien, il faut un processus utilisateur soit sur le serveur, soit sur le client pour casser la clé

En gros il faut de toutes les façons que le méchant réussisse à s'introduire sur la machine et à faire lancer/à lancer un processus espion. Est-ce qu'un programme qui réussirait à se faire lancer en lieu et place du navigateur pourrait faire la même choses sans avoir besoin de casser la clé (vue que c'est lui qui établirait la connexion il aurait connaissance de ce qui s'y dit) ?

Poste le Tuesday 21 November 2006 20:59:10

Citation
Léa (Fred)
Donc si je comprends bien, il faut un processus
utilisateur soit sur le serveur, soit sur le
client pour casser la clé

Exact.

Citation
Léa (Fred)
En gros il faut de toutes les façons que le
méchant réussisse à s'introduire sur la machine et
à faire lancer/à lancer un processus espion.
Est-ce qu'un programme qui réussirait à se faire
lancer en lieu et place du navigateur pourrait
faire la même choses sans avoir besoin de casser
la clé (vue que c'est lui qui établirait la
connexion il aurait connaissance de ce qui s'y
dit) ?

Pour récupérer les infos de M. lambda, ce serait plus simple.
Le plus facile pour le méchant serait de faire un "fork" de firefox :
Faire un logiciel qui modifie l'adresse où firefox cherche à se mettre à jour pour pointer sur une version modifiée.
Le méchant n'aura plus qu'à appliquer son patch sur les nouvelles versions de firefox (pour être le plus transparent possible pour l'utilisateur).
Le firefox modifié pourra ainsi transmettre toutes les infos qu'il souhaite où il veut.

Les firewalls applicatifs seront inopérants (car firefox serait, si on en utilise un, une appli autorisée). Ce genre de faille est, amha, plus critique que celle d'ssl.

Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"

Poste le Wednesday 22 November 2006 08:43:16

Citation
Fred
Les puces ne garantiraient pas la sécurité des échanges en ligne

Pas plus que les tiques ne garantissent la sécurité des échanges sur les marchés... aux puces. #%b

.:! L'être humain est au sommet de la chaîne alimentaire. Certes. Mais il est surtout au sommet de la connerie et de la bêtise... !:.
-- Pour les nouveaux linuxiens : Ce n'est pas en continuant de faire ce que l'on connaît que l'on pourra faire ce que l'on ne connaît pas --

Poste le Monday 11 December 2006 14:59:00