Apple Watch : Apple désactive l'application Walkie-Talkie à cause d'un problème de sécurité, Réactions à la publication du 11/07/2019

[Lionel]

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.

Lien vers le billet original

[arnobacle]

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...

[iAPX]

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...

Ç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 )

Ce message a été modifié par iAPX - 11 Jul 2019, 22:46.

[chombier]

[...] Au passage il se trouve que je connais un peu la cryptographie (voir plus haut pour l'explication du fonctionnement du système [...]

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

[iAPX]

[...] Au passage il se trouve que je connais un peu la cryptographie (voir plus haut pour l'explication du fonctionnement du système [...]

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

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.

Ce message a été modifié par iAPX - 12 Jul 2019, 21:09.

[chombier]

[...] Au passage il se trouve que je connais un peu la cryptographie (voir plus haut pour l'explication du fonctionnement du système [...]

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

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.

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 ?

Ce message a été modifié par chombier - 12 Jul 2019, 21:07.

[iAPX]

[...] Au passage il se trouve que je connais un peu la cryptographie (voir plus haut pour l'explication du fonctionnement du système [...]

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

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.

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 ?

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.

Ce message a été modifié par iAPX - 12 Jul 2019, 21:12.

[chombier]

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.

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.

[iAPX]

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.

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.

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.

Ce message a été modifié par iAPX - 12 Jul 2019, 21:24.

[chombier]

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.

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...

[iAPX]

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.

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...

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.

Ce message a été modifié par iAPX - 12 Jul 2019, 21:42.

[chombier]

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.

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...

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.

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.