Altération de données cryptées en temps réel - méthode ?

Espace de discussions générales sur l'informatique. Tant au niveau matériel que logiciel.
Post Reply
User avatar
Latinus
Admin
Posts: 24773
Joined: 18 Mar 2002 01:00
Location: complètement à l'Ouest
Contact:

Altération de données cryptées en temps réel - méthode ?

Post by Latinus »

Bonjour,

Certains/es d'entres vous auront certainement remarqué le début de débat qui a eu lieu entre Pixel et moi à ce sujet.
J'ai supprimé sa dernière phrase à ce sujet dans le topic et je l'invite donc à faire la démonstration de ce qu'il avance ici, dans ce topic créé dans "Informatique".
Cela nous permettra de discuter clairement du sujet sans continuer à polluer l'autre topic.
Ce n'était donc pas une modération "de mauvaise fois" ( :roll: ), comme certains esprits limités pourraient l'avoir suggéré.

Pour rappel, voici un bref historique :
Pixel :
Un truc énorme de ce matin, en cours de sécurité informatique (lisez
juste qu'au bout pour voir où je veux en venir).
Mon prof disait que malgré l'utilisation d'un algorithme de cryptage
parfait, dans certaines conditions, on peut modifier de l'information.
Exemple : si on sait que l'on a "oui" ou "non" en entrée et que
celle-ci est cryptée, on peut réussir, sans toutefois connaître cette
entrée, à produire l'inverse et donc à faire passer un "oui" pour un
"non" et vice-versa, ni vu ni connu.
Là, quelqu'un pose la question : oui, mais là, faut savoir qu'on a que
"oui" ou "non" en entrée, non ?
Et le prof : "Ben oui, mais c'est possible... Si on pense aux
élections entre Bush et Kerry, par exemple, voyez ce qu'on pourrait
faire... "

Latinus:
Je lui dis que c'est quand même "gros" cette histoire, surtout pour
une modif "en direct" de l'information et que le raisonnement émis
"par le prof" est assez fantaisiste... que le mot "oui" n'a pas pour
inverse le mot "non" en langage informatique et d'autant plus si il y
a encryption et aussi qu'on ne se contente pas de véhiculer le seul
paramètre "0" ou "1" pour valider une transaction sécurisée

Pixel:
Pourquoi tu ne crois jamais les gens ? Si je te prouvais qu'on peut
modifier des valeurs en live sans posséder de clés quelconques, ça
changerait quelque chose ?
Tu sais, je suis en dernière année d'école d'ingés... c'est pas comme
si j'avais dit ça à la va-vite
Voilà...

@+
Lat
Les courses hippiques, lorsqu'elles s'y frottent.
Pixel
Guest

Post by Pixel »

Bon, alors bien sûr, j'avais simplifié le problème, mais l'idée reste la même : modifier le contenu d'un message de sorte que le réceveur comprenne l'inverse de ce qu'on lui a envoyé.

Comme je l'ai dit, partons d'un message envoyé à 2 entrées possibles, schématisées par : "oui" et "non". Supposons que ces mots sont en binaire (suites de 0 et de 1). On peut supposer aussi que ces "mots" ont la même longueur, quoi que ce ne soit pas fondamental. Notons cette entrée E.

Une solution d'encodage parfait serait de générer une clé complètement aléatoire de la longueur de E, que nous noterons K, et d'appliquer l'opérateur XOR entre E et K.

Le message codé est : MC = E XOR K. Normalement, seul le réceveur connaît K et peut décrypter le message envoyé : ME = MC XOR K.

Sauf que j'ai dit qu'on connaissait les deux entrées possibles. Donc si on fait, sur le message codé :

MC XOR "oui" XOR "non", l'entrée initiale "s'annule" et donne l'inverse.

Exemple : quelqu'un envoie "oui".

MC = "oui" XOR K.

Mais je fais :

MC XOR "oui" XOR "non" = "oui" XOR K XOR "oui" XOR "non" = K XOR "non" (les "oui" s'annulent).

Ainsi, lorsque le gars voudra décrypter son message, il lira "non", alors que c'est "oui" qui a été envoyé.

:hello:
devres
Guest

Post by devres »

Je viens illustrer les propos de Pixel.

Supposons :
bus = 01100010 01110101 01110011 (vraies valeurs)
ker = 01101011 01100101 01110010 (vraies valeurs)
clé = 00011101 01010100 11101011 (tirage aléatoire, c'est plus sécuritaire)

Encrytion(KER) = KER XOR clé = (1)
01101011 01100101 01110010 (KER)
00011101 01010100 11101011 (clé)
01110110 00110001 10011001 (1) le message encrypté à envoyer

Maintenant, notre pirate fait : (le message encrypté) XOR KER XOR BUS :

(1) XOR KER = (2)
01110110 00110001 10011001 (1)
01101011 01100101 01110010 (KER)
00011101 01010100 11101011 (2)

(2) XOR BUS = (3)
00011101 01010100 11101011 (2)
01100010 01110101 01110011 (BUS)
01111111 00100001 10011000 (3)

Voilà (3) est le nouveau message encrypté, détourné par le pirate. Maintenant la personne recevant le message le décrypte :
Décryption(3) = (3) XOR clé
01111111 00100001 10011000 (3)
00011101 01010100 11101011 (clé)

01100010 01110101 01110011 = BUS !

Le pirate a renversé le sens du message original sans le connaître, cqfd.

Merci Pixel pour ton post fort intéressante :) .
User avatar
Latinus
Admin
Posts: 24773
Joined: 18 Mar 2002 01:00
Location: complètement à l'Ouest
Contact:

Post by Latinus »

Marrant, vous avez la même IP tous les deux...

L'exemple est intéressant, mais il fait très "cas d'école" :
- données simples
- valeurs connues d'avances
- on admet qu'une transaction sécurisée ne transmet qu'un "oui" ou qu'un "non", alors que c'est loin d'être le cas dans la réalité.
- tu ne parles pas de la méthode de communication utilisée (ssh, ssl, ...)
- tu ne parles pas de l'algorithme utilisé non plus, c'est pourtant important puisque les méthode d'encryption diffèrent en fonction.
- tu parles binaire, que dire des données codées autrement ?
- autre aspect pratique : à quel moment modifies-tu ces données et comment ?

La théorie se tient (à moins que j'ai raté quelque chose), mais dans la pratique je doute fort qu'elle puisse s'appliquer... à moins bien entendu de "construire" un pilote qui réponde parfaitement aux conditions.

Depuis le début je te parle d'application pratique... et je ne reçois que de la théorie. C'est sans doute notre parcours qui créé cette différence, toi tu es encore à fond dans la théorie et moi suis tombé dans la marmitte dès le début... cela ne fait pas de l'un de nous celui qui a raison, mais il n'empêche que je voudrais une application pratique de ce que tu avances (l'exemple des élections me semble plus farfelu qu'autre chose... sans doute pris parce que d'actualité).

J'ai pris la liberté de consulter des collègues (qui sont plus théorie que moi) afin d'avoir un avis plus clair de ce qui est exposé, plus facile de discuter de ces choses et des les comprendre 'en live' que via le clavier.

Merci pour ta réponse :hello:
Les courses hippiques, lorsqu'elles s'y frottent.
Pixel
Guest

Post by Pixel »

Latinus wrote:Marrant, vous avez la même IP tous les deux...
Ouais, normal, c'était mon coloc ci-dessus et on est derrière un routeur. Ca pose un problème ? (Merci à lui pour l'illustration d'ailleurs :jap: )
L'exemple est intéressant, mais il fait très "cas d'école" :
- données simples
- valeurs connues d'avances
- on admet qu'une transaction sécurisée ne transmet qu'un "oui" ou qu'un "non", alors que c'est loin d'être le cas dans la réalité.
- tu ne parles pas de la méthode de communication utilisée (ssh, ssl, ...)
- tu ne parles pas de l'algorithme utilisé non plus, c'est pourtant important puisque les méthode d'encryption diffèrent en fonction.
- tu parles binaire, que dire des données codées autrement ?
- autre aspect pratique : à quel moment modifies-tu ces données et comment ?
Petit rappel :
Mon prof disait que malgré l'utilisation d'un algorithme de cryptage parfait, dans certaines conditions, on peut modifier de l'information.
Exemple : si on sait que l'on a "oui" ou "non" en entrée et que celle-ci est cryptée, on peut réussir, sans toutefois connaître cette entrée, à produire l'inverse et donc à faire passer un "oui" pour un "non" et vice-versa, ni vu ni connu.
Là, quelqu'un pose la question : oui, mais là, faut savoir qu'on a que "oui" ou "non" en entrée, non ?
Et le prof : "Ben oui, mais c'est possible... Si on pense aux élections entre Bush et Kerry, par exemple, voyez ce qu'on pourrait faire... "
Donc :
- Je n'ai pas dit que ça pouvait s'appliquer tout le temps.
- J'ai bien dit que cela supposait qu'on connaisse les différentes entrées possibles.
- La méthode d'encryption, je l'ai dit, c'est un XOR ; i.e., un "ou exclusif" entre le message à crypter et la clé générée aléatoirement. Le chiffre de Vernam, ça te dit quelque chose ?

Question : tu penses à quoi quand tu dis "tu parles binaire, que dire des données codées autrement ?" ? Pour moi, tout peut se ramener au binaire... Enfin, je peux me tromper, évidemment !

Je te rappelle également que je n'ai pas dit que ceci était quelque chose que l'on peut souvent mettre en pratique - étant donné que certaines conditions doivent être réunies -, j'ai juste dit que c'était possible.
Ton argument principal était de dire qu'il fallait connaître les clés pour modifier un message ; je t'ai prouvé que non.

Enfin, j'avoue ne pas savoir exactement comment on pourrait le mettre en pratique ; sans doute en récupérant le signal, en le modifiant, et en le ré-émettant, comme si de rien n'était.
Mon prof en a parlé pour nous montrer que ce n'est pas parce qu'on utilise un cryptage parfait que l'on est à l'abri.
Depuis le début je te parle d'application pratique... et je ne reçois que de la théorie. C'est sans doute notre parcours qui créé cette différence, toi tu es encore à fond dans la théorie et moi suis tombé dans la marmitte dès le début... cela ne fait pas de l'un de nous celui qui a raison, mais il n'empêche que je voudrais une application pratique de ce que tu avances (l'exemple des élections me semble plus farfelu qu'autre chose... sans doute pris parce que d'actualité).
Mon exemple est théorique, certes. Mais si l'on connaît certaines choses sur un système, il pourrait être mis en pratique.
Exemple : je suis informaticien, et je sais que quand on appuie sur un bouton, ça envoie soit "ker", soit "bus" (c'est simplifié, bon d'accord... mais pourquoi pas ? ça pourrait être une partie isolée du système, ou des données que l'on saurait extraire...). Or, je pressens que les élections seront gagnées par Kerry. J'ajoute un petit truc qui change l'entrée en son "opposée", et voilà, c'est Bush qui gagne.
Encore une fois, ce n'est qu'un exemple. Mais il y a peut-être d'autres cas où ça pourrait s'appliquer.

De plus, je ne suis pas que la théorie, vu qu'on a appris en cours à utiliser les failles de sécurité pour craquer un programme et générer des clés d'activation (de programmes) - tout ceci dans un but pédagogique évidemment. Mais nous l'étudions, c'est clair. Et elle est nécessaire pour bien connaître les failles des systèmes je pense...
Merci pour ta réponse :hello:
De rien ;)
User avatar
arkayn
Membre / Member
Posts: 12219
Joined: 09 Dec 2002 02:02
Location: Nogent-le-Rotrou
Contact:

Post by arkayn »

A mon avis, tout le débat tient dans l'expression "en temps réél".

En théorie, oui, il est toujours possible de décrypter un message quelconque et, partant, de le modifier.

Mais il faut bien voir que les transmissions sont sécurisées et qu'il faut donc déjà pouvoir capter le message, le modifier, et réinjecter le message dans le bon circuit. Très loin d'être facile.

D'autre part, le message en lui-même (surtout au niveau d'une élection de cette importance) ne sera pas crypté avec un simple XOR. Une clef de 256 bits (et même moins) suffirait à produire un message dont la longueur d'un oui ou d'un non ne pourrait-être calculée que si on connait d'avance la longueur de la clef.

Avec XOR on pourrait retrouver une séquence sur plusieurs messages codés de la même façon et de là intervertir les oui et les non, mais pas avec une clef.

Compliquons même le problème. Le message est codé avec une clef publique et une clef privée et là, une chatte n'y retrouverait pas ses petits.

Alors oui, on pourrrait modifier un message composé uniquement de oui et de non, avec un système obsolète de permutation. Mais alors autant transférer les résultats sur un bout de papier et codés selon la technique de César.
La folie des uns est la sagesse des autres
Post Reply