Sécurité info - Page 4

Mais je comprends pas, il y a une option qui permet au client d'envoyer sa clé privée au serveur ?! Comment c'est possible ça ?

Non, c'est une faille dans la feature qui permet de lire au-delà d'un buffer, et de récupérer la clé privée en mémoire.

Ah OK, ouf

http://motherboard.vice.com/read/how-white-hat-hackers-stole-crypto-keys-from-an-offline-laptop-in-another-room
Flippant.

Flippant mais ca marche que dans des conditions particulières, on est loin d'un machin de la taille d'une montre qu'ils suffit de passer a coté de la machine en 3s pour recuperer les 3Po de données

C'est déjà assez inquiétant, à ma connaissance c'est la première fois que ça fonctionne aussi rapidement et dans des conditions aussi proches de la réalité.

Certes

Pas mal...

decryption of a carefully-chosen ciphertext,

basé sur des bugs probables de libgcrypt-1.6.3

et il a fallu observer 75 fois la même opération (ce qui est moins qu'avant, certes, mais pas très réaliste)

bah té:

Current Status.
We worked with the developers of Libgcrypt and GnuPG to evaluate and deploy countermeasures preventing the attacks described in this paper (CVE 2015-7511). GnuPG's Libgcrypt 1.6.5, containing such countermeasures, was released simultaneously with the public posting of our results.

Cela signifie donc que c'était un bug de l'implémentation de GnuPG et non pas une faille de ECDSA. Comme d'habitude. Il faut programmer de manière sécurisée et c'est loin d'être trivial.

donc marrant mais pas de panique, c'est avant tout une opération de com'.

Mouais, enfin, "bug de l'implémentation", c'est quand-même chercher loin de dire que c'est une erreur dans le code. Le code crypte et décrypte tout correctement, la mesure des émissions électromagnétiques émises par le processeur lors de l'exécution du code ne fait pas partie du modèle théorique de la machine. En principe, comme le code est écrit en C, ce genre d'effets n'est pas du tout défini, il n'y a d'ailleurs rien qui garantit qu'une contremesure quelconque fonctionne. (Le compilateur a le droit de l'éliminer parce que le vieux code donnait le même résultat.)

dis le comme tu veux mais oui, c'est un bug spécifique a libgcrypt, qui a été corrigé.

Un CPU "general purpose" n'est, par définition, pas adapté aux calculs sécurisés, donc ce genre de leak n'est pas du tout étonnant.

D'autre part, quand on fait du code crypto sérieux, on prend en compte les side channels DÈS LA CONCEPTION.

Donc a fortiori, quand on fait du code crypto sérieux sur un cpu non sécurisé, la moindre des choses voudrait qu'on fasse le double d'efforts pour essayer d'atténuer les problèmes qu'on ne peut pas résoudre complètement.

Apres ca depends de la sériosité du truc, si c'est le cryptage/hashage de mise a jour pour un systeme embarqué, ce n'est pas la meme chose que des communications interne a un gouvernement

#POINTCYBERCRYPTAGEDIGITAL§§§#

Note: il faut avoir SSLv2 enabled

I accidentally your water.

encore un...

tout ça à cause de la standardisation... quand chacun avait son protocole, non documenté, mal implémenté, au moins c'était blindé tellement les gens n'avaient pas envie d'acquérir le matériel proprio pour la connexion/communication puis les heures de reverse engeneering

vince (./111) :
tout ça à cause de la standardisation... quand chacun avait son protocole, non documenté, mal implémenté, au moins c'était blindé tellement les gens n'avaient pas envie d'acquérir le matériel proprio pour la connexion/communication puis les heures de reverse engeneering

Non c'est parce que les gens ne savent pas coder.

Non, c'est parce que les gens veulent connecter tout et n'importe quoi par Internet, Bluetooth etc. La meilleure sécurité reste l'absence de connexion.

Kevin Kofler (./114) :
Non, c'est parce que les gens veulent connecter tout et n'importe quoi par Internet, Bluetooth etc. La meilleure sécurité reste l'absence de connexion.

Non c'est vraiment qu'ils ne savent pas coder.
Ils utilisent des protocoles pas fait pour ça et généralement mal implémenté.
Connecter tout et n'importe quoi par Internet ça a toujours été a peu près le but, en tout cas y'avais pas de raison pour ne pas le faire.
Par contre utiliser HTTP et Oauth pour des objets connecté c'est vraiment con.

y'a des alternatives propres (et secure) pour les zob jet embarqués ?

puis sinon non, on a pas besoin de dérouleur de PQ connecté.

Non l'absence de connection est la meme chose que la securité par obfuscation.

Ce n'est pas parce que ton post-it avec tout tes mots de passes, ou les liasses de billets sous ton matelas ne sont pas connecté que c'est sécurisé.

Comment veux-tu que quelqu'un pirate ta télé non connectée? Parce qu'à moins de:
1. irrompre faire irruption dans ton appartement (auquel cas tu as déjà un problème de sécurité beaucoup plus grand que la sécurité informatique) et
2. ouvrir l'appareil pour reprogrammer le firmware ou quelque chose du genre,
je ne vois vraiment pas. Ça n'a rien à voir avec l'obfuscation.

Kevin Kofler (./118) :
irrompre

Tiens, c'est un joli néologisme (on dit faire irruption, il n'y a pas de verbe existant)

Kevin Kofler (./118) :
Comment veux-tu que quelqu'un pirate ta télé non connectée? Parce qu'à moins de:
1. irrompre dans ton appartement (auquel cas tu as déjà un problème de sécurité beaucoup plus grand que la sécurité informatique) et
2. ouvrir l'appareil pour reprogrammer le firmware ou quelque chose du genre,je ne vois vraiment pas. Ça n'a rien à voir avec l'obfuscation.

3 programmer une télécommande infrarouge avec un led plus puissante que celle de la télécommande pour pouvoir jouer avec la TV depuis dehors