Je suis tombé sur cet article du monde. J'avais déjà entendu parler
de ce type d'attaque, mais pas avec des temps de décryptages de l'ordre
de la seconde...
Est-ce que quelqu'un a des infos plus précises sur cette faille ? notamment
est-ce qu'elle permet de retrouver les clés lors de la génération des clés
assymétriques ou lors de l'utilisation d'une de ces clés ? (ce qui m'intéresse,
c'est
dans le cas de HTTPS, est-ce qu'il faut que l'espion soit sur le PC lors
de l'utilisation
de la clé publique du serveur par le navigateur ou sur le serveur lors de la
génération de clés...)
Si la faille ne concerne que la génération de clés... j'arriverai à ne pas
avoir
d'espion sur mon serveur le jour où je crée ma paire de clés :-)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Erwan David
Philippe Le Van écrivait :
Bonjour,
Je suis tombé sur cet article du monde. J'avais déjà entendu parler de ce type d'attaque, mais pas avec des temps de décryptages de l'ordre de la seconde...
Est-ce que quelqu'un a des infos plus précises sur cette faille ? notamment est-ce qu'elle permet de retrouver les clés lors de la génération des clés assymétriques ou lors de l'utilisation d'une de ces clés ? (ce qui m'intéresse, c'est dans le cas de HTTPS, est-ce qu'il faut que l'espion soit sur le PC lors de l'utilisation
Non, sauf utilisation de certificats clients il faudrait que l'espion soit sur le serveur avec des droits système. Donc en pratique il serait tout à fait capable de récupérer les infos déchiffrées...
de la clé publique du serveur par le navigateur ou sur le serveur lors de la génération de clés...)
Si la faille ne concerne que la génération de clés... j'arriverai à ne pas avoir d'espion sur mon serveur le jour où je crée ma paire de clés :-)
Le risque est que tu aies un certificat client sur ton PC (comme celui des impôts) que l'espion récupère ta clef privée et les infos publiques, et se fasse passer pour toi. Faible risque pour l'utilisateur lambda, plus génant en cas d'attaque ciblé dans une entreprise utilisant les certificats clients pour une authentification forte.
-- Erwan
Philippe Le Van <philippe.levan_nospam@kitpages.com> écrivait :
Bonjour,
Je suis tombé sur cet article du monde. J'avais déjà entendu parler
de ce type d'attaque, mais pas avec des temps de décryptages de l'ordre
de la seconde...
Est-ce que quelqu'un a des infos plus précises sur cette faille ? notamment
est-ce qu'elle permet de retrouver les clés lors de la génération des clés
assymétriques ou lors de l'utilisation d'une de ces clés ? (ce qui
m'intéresse, c'est
dans le cas de HTTPS, est-ce qu'il faut que l'espion soit sur le PC
lors de l'utilisation
Non, sauf utilisation de certificats clients il faudrait que l'espion
soit sur le serveur avec des droits système. Donc en pratique il
serait tout à fait capable de récupérer les infos déchiffrées...
de la clé publique du serveur par le navigateur ou sur le serveur lors de la
génération de clés...)
Si la faille ne concerne que la génération de clés... j'arriverai à ne
pas avoir
d'espion sur mon serveur le jour où je crée ma paire de clés :-)
Le risque est que tu aies un certificat client sur ton PC (comme celui
des impôts) que l'espion récupère ta clef privée et les infos
publiques, et se fasse passer pour toi. Faible risque pour
l'utilisateur lambda, plus génant en cas d'attaque ciblé dans une
entreprise utilisant les certificats clients pour une authentification
forte.
Je suis tombé sur cet article du monde. J'avais déjà entendu parler de ce type d'attaque, mais pas avec des temps de décryptages de l'ordre de la seconde...
Est-ce que quelqu'un a des infos plus précises sur cette faille ? notamment est-ce qu'elle permet de retrouver les clés lors de la génération des clés assymétriques ou lors de l'utilisation d'une de ces clés ? (ce qui m'intéresse, c'est dans le cas de HTTPS, est-ce qu'il faut que l'espion soit sur le PC lors de l'utilisation
Non, sauf utilisation de certificats clients il faudrait que l'espion soit sur le serveur avec des droits système. Donc en pratique il serait tout à fait capable de récupérer les infos déchiffrées...
de la clé publique du serveur par le navigateur ou sur le serveur lors de la génération de clés...)
Si la faille ne concerne que la génération de clés... j'arriverai à ne pas avoir d'espion sur mon serveur le jour où je crée ma paire de clés :-)
Le risque est que tu aies un certificat client sur ton PC (comme celui des impôts) que l'espion récupère ta clef privée et les infos publiques, et se fasse passer pour toi. Faible risque pour l'utilisateur lambda, plus génant en cas d'attaque ciblé dans une entreprise utilisant les certificats clients pour une authentification forte.
-- Erwan
Michael Spath
Philippe Le Van wrote:
Je suis tombé sur cet article du monde.
Un peu trop sensasionnaliste...
Est-ce que quelqu'un a des infos plus précises sur cette faille ?
L'article 'confidentiel' en question : http://eprint.iacr.org/2006/288 et meme la suite : http://eprint.iacr.org/2006/351
notamment est-ce qu'elle permet de retrouver les clés lors de la génération des clés assymétriques ou lors de l'utilisation d'une de ces clés ?
Il semblerait. Ils ont par exemple reussi a recuperer 508 des 512 bits de la cle privee en espionnant une seule signature (!).
Quelques remarques sur l'article :
- L'attaque ne marche apparemment que sur des environnements multi-processeurs (ou HT) dans lesquels l'espion tourne en parallele avec l'application cryptographique. Comme pour la precedente attaque du meme genre (http://www.daemonology.net/hyperthreading-considered-harmful/) un OS peut jouer sur l'affinite des processus pour mitiger le danger.
- Leur methode necessite de connaitre l'adresse en memoire de certaines instructions particulieres de l'application cryptographique, ce qui change de version en version et peut etre aussi modifie facilement.
- Leur methode necessite uniquement des droits de simple utilisateur (et encore, RDTSC sur x86 est un mauvais exemple), mais puisque l'espion doit utiliser les memes adresses memoire que la victime, dans ce cas seule une autre application peut ete espionnee (et pas un kernel module par exemple).
regards, --spath
Philippe Le Van wrote:
Je suis tombé sur cet article du monde.
Un peu trop sensasionnaliste...
Est-ce que quelqu'un a des infos plus précises sur cette faille ?
L'article 'confidentiel' en question : http://eprint.iacr.org/2006/288
et meme la suite : http://eprint.iacr.org/2006/351
notamment est-ce qu'elle permet de retrouver les clés lors de
la génération des clés assymétriques ou lors de l'utilisation d'une
de ces clés ?
Il semblerait. Ils ont par exemple reussi a recuperer 508 des
512 bits de la cle privee en espionnant une seule signature (!).
Quelques remarques sur l'article :
- L'attaque ne marche apparemment que sur des environnements
multi-processeurs (ou HT) dans lesquels l'espion tourne en parallele
avec l'application cryptographique. Comme pour la precedente attaque
du meme genre
(http://www.daemonology.net/hyperthreading-considered-harmful/)
un OS peut jouer sur l'affinite des processus pour mitiger le danger.
- Leur methode necessite de connaitre l'adresse en memoire de
certaines instructions particulieres de l'application cryptographique,
ce qui change de version en version et peut etre aussi modifie
facilement.
- Leur methode necessite uniquement des droits de simple utilisateur
(et encore, RDTSC sur x86 est un mauvais exemple), mais puisque
l'espion doit utiliser les memes adresses memoire que la victime,
dans ce cas seule une autre application peut ete espionnee (et pas
un kernel module par exemple).
Est-ce que quelqu'un a des infos plus précises sur cette faille ?
L'article 'confidentiel' en question : http://eprint.iacr.org/2006/288 et meme la suite : http://eprint.iacr.org/2006/351
notamment est-ce qu'elle permet de retrouver les clés lors de la génération des clés assymétriques ou lors de l'utilisation d'une de ces clés ?
Il semblerait. Ils ont par exemple reussi a recuperer 508 des 512 bits de la cle privee en espionnant une seule signature (!).
Quelques remarques sur l'article :
- L'attaque ne marche apparemment que sur des environnements multi-processeurs (ou HT) dans lesquels l'espion tourne en parallele avec l'application cryptographique. Comme pour la precedente attaque du meme genre (http://www.daemonology.net/hyperthreading-considered-harmful/) un OS peut jouer sur l'affinite des processus pour mitiger le danger.
- Leur methode necessite de connaitre l'adresse en memoire de certaines instructions particulieres de l'application cryptographique, ce qui change de version en version et peut etre aussi modifie facilement.
- Leur methode necessite uniquement des droits de simple utilisateur (et encore, RDTSC sur x86 est un mauvais exemple), mais puisque l'espion doit utiliser les memes adresses memoire que la victime, dans ce cas seule une autre application peut ete espionnee (et pas un kernel module par exemple).
regards, --spath
Nicob
On Mon, 20 Nov 2006 14:43:44 +0000, Erwan David wrote:
Le risque est que tu aies un certificat client sur ton PC (comme celui des impôts) que l'espion récupère ta clef privée et les infos publiques, et se fasse passer pour toi.
De toute façon, si on peut exécuter le code de notre choix sur le poste de la victime, on peut hooker le clavier et la souris et obtenir ainsi les infos, non ? Ou j'ai manqué quelque chose dans le raisonnement ?
Nicob
On Mon, 20 Nov 2006 14:43:44 +0000, Erwan David wrote:
Le risque est que tu aies un certificat client sur ton PC (comme celui
des impôts) que l'espion récupère ta clef privée et les infos
publiques, et se fasse passer pour toi.
De toute façon, si on peut exécuter le code de notre choix sur le poste
de la victime, on peut hooker le clavier et la souris et obtenir ainsi les
infos, non ? Ou j'ai manqué quelque chose dans le raisonnement ?
On Mon, 20 Nov 2006 14:43:44 +0000, Erwan David wrote:
Le risque est que tu aies un certificat client sur ton PC (comme celui des impôts) que l'espion récupère ta clef privée et les infos publiques, et se fasse passer pour toi.
De toute façon, si on peut exécuter le code de notre choix sur le poste de la victime, on peut hooker le clavier et la souris et obtenir ainsi les infos, non ? Ou j'ai manqué quelque chose dans le raisonnement ?
Nicob
Erwan David
Nicob écrivait :
On Mon, 20 Nov 2006 14:43:44 +0000, Erwan David wrote:
Le risque est que tu aies un certificat client sur ton PC (comme celui des impôts) que l'espion récupère ta clef privée et les infos publiques, et se fasse passer pour toi.
De toute façon, si on peut exécuter le code de notre choix sur le poste de la victime, on peut hooker le clavier et la souris et obtenir ainsi les infos, non ? Ou j'ai manqué quelque chose dans le raisonnement ?
Apparement l'attaque ne demande pas que tu travailles avec des droits système, juste que tu travailles sur le même processeur.
-- Erwan
Nicob <nicob@I.hate.spammers.com> écrivait :
On Mon, 20 Nov 2006 14:43:44 +0000, Erwan David wrote:
Le risque est que tu aies un certificat client sur ton PC (comme celui
des impôts) que l'espion récupère ta clef privée et les infos
publiques, et se fasse passer pour toi.
De toute façon, si on peut exécuter le code de notre choix sur le poste
de la victime, on peut hooker le clavier et la souris et obtenir ainsi les
infos, non ? Ou j'ai manqué quelque chose dans le raisonnement ?
Apparement l'attaque ne demande pas que tu travailles avec des droits
système, juste que tu travailles sur le même processeur.
On Mon, 20 Nov 2006 14:43:44 +0000, Erwan David wrote:
Le risque est que tu aies un certificat client sur ton PC (comme celui des impôts) que l'espion récupère ta clef privée et les infos publiques, et se fasse passer pour toi.
De toute façon, si on peut exécuter le code de notre choix sur le poste de la victime, on peut hooker le clavier et la souris et obtenir ainsi les infos, non ? Ou j'ai manqué quelque chose dans le raisonnement ?
Apparement l'attaque ne demande pas que tu travailles avec des droits système, juste que tu travailles sur le même processeur.
Une analyse de l'article et du papier en cause par Cédric Blancher : http://sid.rstack.org/blog/index.php/2006/11/22/152-la-fin-du-monde
-- CQ> Pourquoi chercher des ténors derrière les barreaux, CQ> ils ont été libérés, non ? Mais que fait la DDT ? Le DDT, c'est pour éradiquer les moustiques, pas les ténors. -+- ED in : Guide du Neuneu Usenet - J'en perds le ténor -+-
Philippe Le Van <philippe.levan_nospam@kitpages.com> writes:
Une analyse de l'article et du papier en cause par Cédric Blancher :
http://sid.rstack.org/blog/index.php/2006/11/22/152-la-fin-du-monde
--
CQ> Pourquoi chercher des ténors derrière les barreaux,
CQ> ils ont été libérés, non ? Mais que fait la DDT ?
Le DDT, c'est pour éradiquer les moustiques, pas les ténors.
-+- ED in : Guide du Neuneu Usenet - J'en perds le ténor -+-
Une analyse de l'article et du papier en cause par Cédric Blancher : http://sid.rstack.org/blog/index.php/2006/11/22/152-la-fin-du-monde
-- CQ> Pourquoi chercher des ténors derrière les barreaux, CQ> ils ont été libérés, non ? Mais que fait la DDT ? Le DDT, c'est pour éradiquer les moustiques, pas les ténors. -+- ED in : Guide du Neuneu Usenet - J'en perds le ténor -+-
Nicob
On Thu, 23 Nov 2006 14:19:50 +0000, Erwan David wrote:
Apparement l'attaque ne demande pas que tu travailles avec des droits système, juste que tu travailles sur le même processeur.
Sous Windows, il n'y a pas besoin de droits particuliers pour hooker sa propre souris et son propre clavier. Donc, dans le cas classique des malwares actuels, il y a déjà le risque d'interception d'une clé privée.
Nicob
On Thu, 23 Nov 2006 14:19:50 +0000, Erwan David wrote:
Apparement l'attaque ne demande pas que tu travailles avec des droits
système, juste que tu travailles sur le même processeur.
Sous Windows, il n'y a pas besoin de droits particuliers pour hooker sa
propre souris et son propre clavier. Donc, dans le cas classique des
malwares actuels, il y a déjà le risque d'interception d'une clé privée.
On Thu, 23 Nov 2006 14:19:50 +0000, Erwan David wrote:
Apparement l'attaque ne demande pas que tu travailles avec des droits système, juste que tu travailles sur le même processeur.
Sous Windows, il n'y a pas besoin de droits particuliers pour hooker sa propre souris et son propre clavier. Donc, dans le cas classique des malwares actuels, il y a déjà le risque d'interception d'une clé privée.
Nicob
Emmanuel Florac
Le Mon, 20 Nov 2006 20:15:30 +0000, Michael Spath a écrit :
Il semblerait. Ils ont par exemple reussi a recuperer 508 des 512 bits de la cle privee en espionnant une seule signature (!).
En fait ils ont observés 10 décodages et ils ont pris le meilleur, ils ont utilisé un openSSL un peu bricolé, l'envvironnement était quasiment en mono-utilisateur... Bref tout cela est loin de la méga-faille-critique du monde réel, il me semble.
-- Si non confectus non reficiat.
Le Mon, 20 Nov 2006 20:15:30 +0000, Michael Spath a écrit :
Il semblerait. Ils ont par exemple reussi a recuperer 508 des
512 bits de la cle privee en espionnant une seule signature (!).
En fait ils ont observés 10 décodages et ils ont pris le meilleur, ils
ont utilisé un openSSL un peu bricolé, l'envvironnement était quasiment
en mono-utilisateur... Bref tout cela est loin de la méga-faille-critique
du monde réel, il me semble.
Le Mon, 20 Nov 2006 20:15:30 +0000, Michael Spath a écrit :
Il semblerait. Ils ont par exemple reussi a recuperer 508 des 512 bits de la cle privee en espionnant une seule signature (!).
En fait ils ont observés 10 décodages et ils ont pris le meilleur, ils ont utilisé un openSSL un peu bricolé, l'envvironnement était quasiment en mono-utilisateur... Bref tout cela est loin de la méga-faille-critique du monde réel, il me semble.
