Version imprimable du sujet

Écrit par : Lionel 11 Jul 2019, 13:07

Apple a désactivé dans l'urgence l'application Walkie-Talkie disponible pour les Apple Watch et permettant d'échanger entre deux montres.
Une faille de sécurité a été découverte. Elle permet de déclencher une conversation sans que l'utilisateur de la montre n'ait à l'accepter.
En résumé, n'importe quelle Apple Watch peut devenir un micro espion à l'insu de son utilisateur.

Dans un communiqué Apple annonce qu'elle rétablira la fonction aussi vite que possible, mais qu'à sa connaissance elle n'a pas été exploitée par des personnes malveillantes.

En tout cas, cette faille était grave. C'est d'autant plus ennuyeux que la société ne cesse de communiquer sur la sécurité de ses produits et des données de ses clients.

http://macbidouille.com/news/2019/07/11/apple-watch-apple-desactive-lapplication-walkie-talkie-a-cause-dun-probleme-de-securite

Écrit par : otto87 11 Jul 2019, 13:57

Au moins, c'est franc du collier avec réaction immédiate. Fini le temps des failles qui restent ouvertes bien longtemps après leur publication?

Écrit par : Lionel 11 Jul 2019, 14:06

Apple amorce enfin de timides changements de paradigme. Elle sait que ses clients ne sont plus enclins au pardon aveugle.

Écrit par : Xample 11 Jul 2019, 14:20

Avec facetime et zoom ça fait quand même la 3e faille du genre en relativement peu de temps.

Écrit par : iAPX 11 Jul 2019, 14:47

Apple communique beaucoup sur le coté marketing "end-to-end encryption", ce qui était justement le cas du Talkie-walkie (en fait du FaceTime audio!) et n'a pas empêché ce beau joujou de leaker les conversations, permettant d'espionner des personnes, finalement une bug similaire à celle de FaceTime en groupe.

Ça devrait faire réfléchir sur la réelle sécurité des produits Apple, ou à chaque fois qu'on veut nous bourrer le mou avec "end-to-end encryption"...

Écrit par : Lionel 11 Jul 2019, 14:59

Je suis persuadé que certains salariés d'Apple (et de toutes les société US) sont de fervents défenseurs de la sécurité nationale (ce n'est pas une critique) et plus fidèles à leur pays qu'à leur patron.
Le code de ces failles est plus que certainement made in NSA.
Lz seul vrai choix que l'on ait n'est pas d'être en sécurité, mais de choisir qui écoute, Chine, Etats-Unis, Russie...

Écrit par : captaindid 11 Jul 2019, 16:06

je pense que ça n'a rien à voir avec un changement d’éthique ou de comportement d'Apple.
ce ne sont pas des bugs qui ont été corrigés, ce sont des fonctionnalités cachées qui ont été sciemment introduites (à la demande de certaines agences américaines ?) et destinées à nous espionner. le problème c'est qu'elles ont été grossièrement implémentées et ça s'est vu ou ça n'allait pas tarder à se voir.

Apple s'étant déjà fait gauller avec ce genre de "bug" très louche (https://forum.macbidouille.com/index.php?showtopic=411185&view=findpost&p=4259382), il est urgent pour eux de faire bonne figure;
et comme ils ne sont pas les seuls à s'être fait gauller, je pense à Zoom il y a quelques jours, à whatsapp il n'y a pas longtemps, et plein d'autres, il est d’autant plus urgent pour Apple de s'extraire de cette suspicion généralisée qui doit bien commencer à monter auprès des utilisateurs

Écrit par : marc_os 11 Jul 2019, 16:07

C'est clair, ce serait bien mieux si Apple ne disait rien au lieu de tenter de jouer la transparence.

En vérité, au contraire je pense que « communiquer sur la sécurité de ses produits » c'est bien, mais que communiquer également sur les failles comblées au lieu de les passer sous silence c'est mieux, ce n'est pas « ennuyeux » non non, au contraire ça rappelle qu'aucune "sécurité" n'est donnée à priori, et je ne critiquerai pas comme toi le fait de se remettre en question et de corriger ses erreurs. (Petit rappel : Errare humanum est, et il n'y a que ceux qui ne font rien qui ne font jamais d'erreurs.) Tu ne fais jamais d'erreur ?

De plus, je ne doute pas une seconde que si Apple n'avait rien dit, et que si un petit malin avait découvert la chose, alors tu aurais crié, non hurlé au scandâle. Pour preuve, tu viens de le faire pour rien - même si c'est de manière soft en qualifiant la chose d' « ennuyeuse ».

Écrit par : JayTouCon 11 Jul 2019, 17:12

Et quand on sait que la montre collecte des données de santé on a un joli combo. Oui oui oui anonymisee bla blabla blah. Il y aura d’autres failles.

Écrit par : vlady 11 Jul 2019, 18:12

Et pour le moment c'est toi qui hurles.

Écrit par : iAPX 11 Jul 2019, 18:55

Pour rebondir là-dessus, le Talkie-Walkie est du FaceTime audio, et a hérité de la même "bug" (backdoor) que FaceTime sous iOS: Apple a la capacité d'ajouter un correspondant dans une conversation (et sa clé publique) sans action ni information des personnes déjà présentes dans la conversation.

Apple a raison de dire qu'ils ne peuvent déchiffrer les messages précédemment échangés, aussi que la communication est chiffrée "end-to-end", mais il y a un mécanisme dans FaceTime et Talkie-Walkie permettant de ne pas notifier certains ajouts et de garder ces correspondants cachés de la liste des intervenants dans une conversation.
Dit autrement, Apple gère les clés publiques et leur injection, ainsi que leur non-notification et non-affichage, c'est le Maître des clés.
Je doute fort que ça soit une action individuelle par patriotisme, ça ressemble pour moi à une fonctionnalité qui n'est pas destinée au grand-public!!!

À chaque fois que vous entendez chiffrement bout-à-bout "end-to-end encryption", attendez-vous à une arnaque et surtout cherchez qui gère les clés: comme à Fort Boyard c'est le Maître des clés qui a le pouvoir

PS: une description des mécanismes utilisés pour le fun, sachant que chaque correspondant à une clé privée (connue de lui seul) et une clé publique (accessibles à tous), Apple stockant la clé privée chiffrée, lui interdisant son accès si on utilise un mot-de-passe très fort, elle est récupérée via l'authentification iCloud/machin-chose, un dérivé du mot-de-passe permettant alors de la déchiffrer temporairement, par exemple pour un nouvel appareil, le déchiffrage étant alors fait dans celui-ci si proprement implémenté.

Authentification du message et chiffrement:

1. Génération d'une clé de message (MessageKey) aléatoire pour éviter l'attaque par cryptanalyse différentielle
2. Chiffrement du message avec la MessageKey, ne pouvant donc être déchiffré qu'en ayant connaissance de celle-ci (le message est donc protégé une fois pour toute)
3. Chiffrement de la MessageKey par la clé privée de l'émetteur, pour l'authentifier, obtenant une AuthenticatedKey (phase d'authentification)
4. Pour chaque destinataire, chiffrement de l'AuthenticatedKey par la clé publique de celui-ci (on a donc une liste destinataire->une clé à déchiffrer + un message chiffré une seule fois)

Déchiffrement avec vérification de l'authenticité:

1. Le destinataire utilise sa clé privée pour déchiffrer la clé qui lui est destinée, obtenant ainsi l'AuthenticatedKey
2. Le destinataire déchiffre alors l'AuthenticatedKey avec la clé publique de l'émetteur, obtenant la MessageKey (authentification de l'émetteur)
3. Avec la MessageKey, le destinataire déchiffre le message commun (pas besoin de le dupliquer ni de le chiffrer différemment quelque-soit le nombre de destinataires)

Écrit par : otto87 11 Jul 2019, 19:11

En même temps, existe-t-il encore des gens avec un minimum de culture informatique qui puissent encore avoir un soupçon de confiance dans du matériel dont le design hardware et software, à tout les niveaux, est américain?

Écrit par : chombier 11 Jul 2019, 20:30

Nan mais

Écrit par : linus 11 Jul 2019, 21:08

Je serais bien intéressé à savoir comme on fait pour choisir cela selon toi.
Si tu penses au fait de choisir le pays du constructeur, c'est juste augmenter la probabilité d'écoute par son pays de référence, sans annuler celles des autres. Apple conçoit, mais ne fabrique pas. Pour macOS, des parts sont sans doute soutraitées en Inde ou ailleurs.

Écrit par : arnobacle 11 Jul 2019, 21:37

bonsoir à tous,
existe-t-il encore des gens avec un minimum de culture informatique qui puissent imaginer qu'un logiciel soit sans bug en particulier au niveau de la sécurité où les "hackeurs" sont des des codeurs ou décodeurs particulièrement pointus ?
je ne nie pas le côté très "intéressé" de nos fabricants-vendeurs de machine et logiciel, mais, sans être particulièrement bisounours, je pense qu'il faut quand même modérer la parano générale et voir n'importe quel bug comme un acte volontaire !

Arnauld
PS ça faisait bien longtemps que je n'avais pas posté, mais là, je n'ai pas résisté

Écrit par : iAPX 11 Jul 2019, 21:44

C'est que ça n'est pas une "bug", pas plus que le problème affectant similairement FaceTime audio+video (là il s'agit de FaceTime audio techniquement), mais de la possibilité de rajouter un interlocuteur dans une conversation sans que celui-ci soit signalé à ceux déjà présent, ni ne soit affiché dans la liste des interlocuteurs.

C'est une volonté.

Et dès qu'on entend "end-to-end encryption", on devrait se méfier car on s'apprête à nous la mettre profond.
Aucun système de chiffrement "end-to-end" actuellement populaire n'a pas eu de failles de sécurité qui casse absolument tout ça dans sa configuration par défaut, et j'inclus WhatsApp, le système du gouvernement Français (ayant hérité d'une bug backdoor similaire), PGP, etc.

Écrit par : arnobacle 11 Jul 2019, 21:59

J'ai vu tellement d'effet "bizarre" de bug logiciel dans près de 40 ans de frottement aux systèmes logiciels que je ne suis plus étonné de rien !
Tu as peut-être raison sur ce point, faudrait voir le code, mais ma réaction était plus générale que sur ce sujet particulier, sitôt qu'un truc louche sur la sécurité arrive, on tombe dans le pseudo-complot, et ça, je pense que ça fausse la réalité et dessert le débat...

Écrit par : JayTouCon 11 Jul 2019, 22:05

il y a différentes méthodes. du constructeur au 'cloudeur'. parfois c'est plus à l'ancienne en se 'connectant' terme poli sur des câbles sous marins comme ce fut le cas il y a quelques années.
la pomme applique le patriot act et le cloud act avec un renversement total de la charge de la preuve pour ce dernier. c'est valable pour microsoft évidemment mais la pomme est plus gentille, plus sympa et préserve la vie privée en la repeignant en or rose.
porter en permanence une 'montre' qui indique les pulsations cardiaques, une géolocalisation et un déverrouillage du bidule par le visage, en rajoutant le paiement c'est à dire les données bancaires c'est juste magnifique. ensuite on rajoute les éléments de langage pour le vendre et 'sauver des vies'

vendre le matos est une chose, détenir les données en est une autre. la pomme se rapproche de plus en plus de Facebook & en plus le fait payer.

edit : le slogan quand c'est gratuit c'est vous le produit, et pour faire croire le contraire le slogan inversé : si vous nous payez vous êtes protégé.

Écrit par : iAPX 11 Jul 2019, 22:14

Ça n'a rien de "louche", c'est que ce que des gouvernements étrangers (aux USA) demandent, comme l'Australie par exemple, et il se trouve que le comportement est déjà parfaitement implémenté: on peut appeler cela un hasard, parler de bug, mais ça marche si bien et sur différentes plateformes que...

Au passage il se trouve que je connais un peu la cryptographie (voir plus haut pour l'explication du fonctionnement du système), même un peu "chercheur en sécurité" avec un exploit publique très lourd sur MySQL en dehors de tout ce qui n'est pas publique. Mais @malloc et @Marc_OS vont expliquer qu'il faut des preuves avec des liens sur des pages nowhere sur Internet, sans pouvoir eux-même s'appliquer cette même norme (je les attends )

Écrit par : EricDu 11 Jul 2019, 23:56

Dans une société comme Apple, je présume que chaque ligne de code est documentée et revue par plusieurs personnes. Ça m'étonnerait qu'un codeur puisse ajouter une porte dérobée ou une autre fonctionnalité sans que ses supérieurs ne le remarque.

Écrit par : otto87 12 Jul 2019, 00:46

@rnobacle
Les erreurs de codes sont humaines comme tout un chacun peut en faire (je suis le premier à en faire )
Mais autant d'erreur dans le même sens, ça pue la NSA a plein nez! Et c'est dans la lois de ce pays. Ne pas le reconnaître est juste un signe d’analphabétisme avancé...
Ne pas le voir est soit une jeunesse d'esprit pré snowden, soit un aveuglement massif!
Et ça empêche pas que de vieux bugs existent sans la NSA et ça n’empêche pas que de nouveaux bug existent avec la NSA!
Les gens n'ont pas compris que nous sommes en guerre depuis des dizaines d'années, pas besoin d'armes conventionnelles pour la faire, il y a les guerres juridiques, économiques, même pas besoin de mort directement imputables, même s'ils existent...
Les Usa passent à la vitesse supérieure avec l'extraterritorialité de leurs droits sur le dollars, qui est la plus grosse fumisterie de tout les temps!

Écrit par : flan 12 Jul 2019, 05:39

Quelle « backdoor » similaire ?

Écrit par : cyril1 12 Jul 2019, 06:43

Dommage ! Certainement la meilleure fonction de la Watch qui disparaît !

Je ====>

Écrit par : VSD 12 Jul 2019, 06:44

Une faille peut en cacher une aitre ...c'est bien connu !
Un jour il y en aura une énorme et on viendra à se taper dessus !
Mes montres m'ont indiquées depuis plus de 54 ans l'heure et la date cela me suffit !
Je n'ai pas besoin de savoir comment va mon coeur, si je pête de travers etc...
Les montres gadgets et autres fioritures (enceintes etc...) très peu pour moi !

Écrit par : Lionel 12 Jul 2019, 07:23

Tu ne comprendras décidément rien dans ton aveuglement.
Je ne critique pas qu'ils aient annoncé la faille, c'est bien et de toute façon elle aurait été connue dans tous les cas.
Je constate seulement que cela tombe mal au niveau médiatique.


Il suffit alors que le code soit ajouté par le dernier de la chaîne avant le déploiement, ou plus simplement que certains ferment les yeux.
Tu sais, ces bouts de code ne sont pas targués, code pirate, ce sont des chaînes disséminées, parfois déjà utilisées par ailleurs, et il suffit d'un bon branchement pour que la bonne cascade soit lancée.
Ici, on parle d'un interlocuteur invisible qui s'ajoute (ce que demandent les services secrets anglais en passant). Donc, il faut juste un bout de code qui contourne l'invitation et la notification, pas besoin d'être long, puisqu'il ne fait que se brancher après les vérifications de sécurité.

Écrit par : iAPX 12 Jul 2019, 13:16

Il y avait une gross bug Française dans le système de communication du gouvernement Français, mais aussi une backdoor permettant de suivre des conversations de groupe sans être visible dans la conversation.
Le code vient d'un système Open-Source utilisé dans des messageries chiffrées "end-to-end", et comme d'hab...

Écrit par : flan 12 Jul 2019, 18:01

Oui, je me souviens bien du bug pour la version internet de Tchap (qui n'est pas « Le système de communication du gouvernement français », juste un outil mis à disposition des gens pour leur éviter d'utiliser WhatsApp ou Telegram).
Mais cette backdoor ne me dit rien, aurais-tu quelque chose de plus précis ?

Écrit par : iAPX 12 Jul 2019, 20:41

"La messagerie de l'État Français", j'ai trouvé cette formulation http://www.tchap.fr/, et principalement utilisée au sein du gouvernement, avec "500 utilisateurs des cabinets ministériels".

Pour le reste ça vient de la description des problèmes rencontrés par le hacker après avoir réussi à s'inscrire (la bug franco-française étant sur l'inscription, le reste étant d'origine).

Écrit par : chombier 12 Jul 2019, 20:57

Tu connais un peu, mais lorsque tu expliques, tu déchiffres un message avec la clé publique de l'émetteur ?

Écrit par : iAPX 12 Jul 2019, 21:00

Oui, c'est une des étapes!

Celle-là est l'authentification de l'Émetteur, puisque seul celui-ci peut avoir chiffré la clé "AuthenticatedKey" avec sa clé privé, prouvant ainsi sans-équivoque son identité.
La précédente consiste à déchiffrer la clé de l'émetteur via sa clé privée (que seul le récepteur peut faire), c'est là où se trouve ce qu'on appelle couramment le "chiffrement", bien que ça soit le chiffrement d'une clé de chiffrement/déchiffrement symétrique.

Sans cette étape n'importe qui pourrait chiffrer n'importe quoi avec la clé publique du destinataire en se faisant passer pour l'émetteur, c'est pour cela qu'aussi surprenante qu'elle soit à première vue, elle est indispensable!

Pour résumer, pour pouvoir déchiffrer la clé permettant d'accéder au message, il faut qu'elle ai été chiffrée avec la clé publique du destinataire (seul lui peut le faire) et aussi avec la clé privée de l'émetteur, authentifiant l'émetteur et ne donnant accès qu'au destinataire.

Écrit par : chombier 12 Jul 2019, 21:05

Mais tu te rends compte que TOUT LE MONDE a accès à cette clé publique, et que ça ne sert à rien pour "déchiffrer" ? ou pas du tout ?

Écrit par : iAPX 12 Jul 2019, 21:11

Mais si, seul l'émetteur peut avoir chiffré la clé avec sa clé privée: ça authentifie la provenance du message.
C'est pour ça que ça doit être fait avec la clé publique (connu de tous) de l'émetteur!

Et il s'agit d'une action de déchiffrement de clé et non de message, prenant en entrée la clé déjà déchiffrée par le destinataire (avec sa propre clé privée) et à laquelle seul lui a accès.

Écrit par : chombier 12 Jul 2019, 21:20

Qu'il s'agisse de déchiffrer des clés ou des messages ne change rien à la faille. Une clé publique est, par définition, publique...
S'en servir pour déchiffrer est totalement inutile. Voire stupide.

Moi, perso, j'achète pas ton bidule.

Écrit par : iAPX 12 Jul 2019, 21:23

Qui peux chiffrer avec sa clé privée quelque-chose alors déchiffrable avec sa propre clé publique, connu de tous?

Uniquement le possesseur de la clé privé.
Ça authentifie non-équivoquement le processus.

Écrit par : chombier 12 Jul 2019, 21:30

On ne "chiffre" pas un message avec une clé privée, mais avec la clé publique du destinataire...
On "signe" un message avec sa propre clé privée, et le destinataire vérifie son authenticité avec la clé publique de l'émetteur.

signé: chombier, pas expert du tout...

Écrit par : iAPX 12 Jul 2019, 21:35

Ah je comprends mieux!

Ce que tu appelles "signer" est en fait un chiffrement comme un autre, qui est effectivement fait avec la clé privée de l'émetteur pour l'authentifier et vérifiable grâce à sa clé publique (sa spécificité).
Pour ça que j'appelle ça "chiffrer" car techniquement c'est un chiffrement, et que tu appelles ça "signer" puisque ce chiffrement permet de signer.

La raison pour laquelle je n'appelle pas cela "signer" est qu'il y a différentes techniques permettant de signer des échanges (ou de s'authentifier), toutes étant dans la cryptographie mais pas nécessairement des chiffrements, un exemple étant l'usage de courbes elliptiques.

Écrit par : chombier 12 Jul 2019, 21:41

Nan. chiffrer, c'est chiffrer, et signer, c'est signer.

Ce que j'appelle "chiffrer", bah c'est chiffrer. En anglais, dans de nombreuses RFC, c'est le "cipher".
Ce que j'appelle "signer", bah c'est s'authentifier. En anglais, dans de nombreuses RFC, c'est le "MAC".

Et là, tu t'es clairement mélangé les pinceaux.

Écrit par : iAPX 12 Jul 2019, 21:47

Un MAC est une autre façon de s'authentifier, ou de signer, comme les courbes elliptiques, etc.

Le MAC n'est pas utilisable pour signer dans le cadre d'une messagerie de gré à gré où le destinataire n'a jamais et n'aura jamais accès au secret (la clé secrète de l'émetteur): le MAC nécessite de connaître le secret à un moment.
Dans ce cas il y a plusieurs façon de faire, notamment par chiffrement d'un message aléatoire fourni par le destinataire avec la clé privée de l'émetteur, le destinataire vérifiant avec la clé publique si l'émetteur connait la clé privée, utilisé en SSL par exemple, mais c'est inutilisable pour une messagerie où les appareils peuvent ne pas être connectés en même temps.

C'est pour cela qu'en ajoutant un chiffrement supplémentaire (un chiffrement de clé!), via un cipher (si si!), vérifiable ultérieurement et sans échange direct entre les appareils (hors connaissance mutuelle de leurs clés publiques), cela permet d'authentifier l'émetteur.

PS: la problématique technique est qu'il n'y a pas de secret commun (un mot-de-passe comme pour du MAC), tout ne peut donc se faire qu'avec des chiffrements asymétriques avec des paires de clés publiques/privées.

Écrit par : chombier 12 Jul 2019, 21:54

Euh...
En fait j'étais intervenu parce que tu m'avais bien fait marrer avec ton déchiffrement à base de clé publique, et tu en remets une couche. J'achète toujours pas.
Et je vais arrêter le hors sujet.

Écrit par : iAPX 12 Jul 2019, 21:58

C'est comme cela que https://www.ssh.com/ssh/public-key-authentication fonctionne en général (sauf quand on utilise un mot-de-passe, mais c'est non-sécuritaire), par exemple, c'est de l'authentification par clé publique.
Rien de nouveau depuis RSA et les années 80, c'est connu, utilisé couramment, etc.

Le point essentiel est que seul le possesseur de la clé privé peut avoir chiffré quelque-chose de déchiffrable avec sa clé publique, et que ça n'est en rien une sécurité pour le message (car le sens de chiffrement a changé dans le grand-public!) mais une preuve d'identité (authentification, signature, etc.).

PS: il y aura peut-être un cryptographe qui lira mon explication du process plus haut, et qui en comprendra le point-faible (évident), ça devrait être un test de première année, faut pas parler sérieusement de cryptographie en grignotant avant de réattaquer le travail

Écrit par : chombier 12 Jul 2019, 23:24

C'est de la provocation ?

Il se trouve que j'ai codé un freeware qui s'appelait MacSSH pour MacOS9...

Écrit par : iAPX 12 Jul 2019, 23:54

Et d'un coup en agrégeant d'autres projets open-source, par l'opération du saint-esprit, tu as reçu par osmose la compréhension profonde de ce qu'ils font?

Plus sérieusement il y a une erreur dans ce que j'ai décris, manifeste et évidente, je grignotais avant de me remettre au travail, ça n'est pas une excuse mais l'explication.
Trouve là (elle est évidente), cryptographie 101 première année!
L'erreur est simple à trouver, mais quel type d'attaque permet-elle?

Écrit par : chombier 13 Jul 2019, 00:01

Je n'aurais pas osé en dire autant, mais en plus des milliers de remerciements des utilisateurs, je prends !
(même si évidemment que non pour ta question).


Déjà, corrige ton déchiffrement avec clé publique.

Écrit par : iAPX 13 Jul 2019, 00:21

Je vais en rajouter une couche sur les signatures: le message ne peut pas être signé par lui-même, ça doit être la clé qui doit authentifier l'émetteur.

Si on signe le message, par empreinte (sha2 en général) puis chiffrement de celle-ci par la clé privée de l'émetteur, on ne peut plus alors streamer une vidéo car il faut avoir téléchargé tout le message (ou la vidéo) pour vérifier sa validité et l'authentification par l'émetteur.
À noter que dans le cas d'une signature rajoutée à la fin du message, il faut aussi déchiffrer l'empreinte avec la clé publique de l'émetteur (on ne s'en sort pas ) pour valider.

C'est pour ça que pour les échanges de messages asynchrones, toutes les opérations cryptographiques sont effectuées sur les clés, hors le déchiffrement final du message (sa seule opération) qui suivant ce qui a été choisi pour le chiffrer peut être partiel (genre on a reçu 3 vidéos dedans et on en décode une seule).

Allez qui trouvera mon erreur et le type d'attaque que cela permet?
C'est honnête de reconnaître son erreur et de l'assumer. Mais même bien visible ça ne saute pas aux yeux de tous pourtant si cryptographes

Écrit par : chombier 13 Jul 2019, 00:39

Mais DAMNERDE !
TU NE CHIFFRES PAS UN MESSAGE AVEC UNE CLE PRIVEE !!!

Tu utilises la clé PUBLIQUE du correspondant avec lequel tu veux échanger un message chiffré.
Et lui se sert de sa clé PRIVEE pour déchiffrer le message.

Bon. Au lit.

Écrit par : iAPX 13 Jul 2019, 00:48

Je n'ai jamais écrit qu'on chiffrait un message avec sa propre clé privée, relis bien

Tu confonds l'obfuscation et l'authentification, deux opérations faisables via le chiffrement par un cipher asymétrique, la beauté du système de clé publique/clé privé réellement inventé par les 3 RSA!
C'est pour ça qu'il y a plusieurs étapes de chiffrements, pour authentifier puis chiffrer à destination d'un seul récipiendaire.

L'authentification étant souvent effectuée par chiffrement par l'authentifié avec sa clé privée d'informations créées aléatoirement par l'authentificateur, celui-ci déchiffrant alors avec la clé publique de l'authentifié et vérifiant le message décodé. Mais il faut alors une communication directe, donc des échanges synchrones.
Il y a là une variation puisque la donnée validant l'authentification elle-même est une clé de chiffrement/déchiffrement (symétrique donc), la preuve de l'authentification étant la capacité de la clé à décoder le message (ou pas!), évitant ainsi tout échange puisque destiné à être asynchrone.

Je vais vulgariser, car on ne surchiffre pas des messages mais une clé, ce que j'ai écrit plus haut (sans l'erreur):
Si je chiffre un message avec ma clé privée, tout le monde pourra le lire (via ma clé publique), et seul moi pourra l'avoir écrit.
Si je chiffre alors ce message déjà chiffré avec la clé publique du destinataire, seul celui-ci pourra déchiffrer le précédent avec sa clé privée puis utiliser ma clé publique en re-déchiffrant pour s'assurer que c'est bien moi qui l'ai envoyé.

Écrit par : chombier 13 Jul 2019, 00:57

Qu'elle soit propre ou sale, on ne chiffre pas avec une clé privée. Point. (comme dirait raoulito )

Relis bien.

Écrit par : iAPX 13 Jul 2019, 00:59

Évidemment que si, c'est aussi la base des empreintes de vérifications des certificats https, l'empreinte est signée avec la clé privée du CA au-dessus et vérifiée avec sa clé publique (par déchiffrement puis comparaison).

Écrit par : zero 13 Jul 2019, 04:45

Et il aurait bien raison. La méthode du "si je cache tout ça n'est jamais arrivé", il n'y a que les gouvernements chinois, russe et nord coréen pour y croire. Ça s'appelle "faire l'autruche".

Écrit par : flan 13 Jul 2019, 06:37

Mais tchap.fr est un site qui ne connaît pas le sujet et n'a rien d'officiel (« www.tchap.fr n’a aucun lien avec la DINSIC et ne revendique aucune autorité sur le sujet. »)


as-tu une source sur le sujet ?

Écrit par : chombier 15 Jul 2019, 21:26

iAPU d'iAPX sur le sujet sécurité.
Trop parano avec ses propres algos.