Apple lance une procédure contre le groupe NSO, Réactions à la publication du 24/11/2021

[Lionel]

Vous avez certainement tous entendu parler du groupe NSO. Cette société est celle qui développe le logiciel Pegasus. Ce logiciel utilise des failles de sécurité iOS afin de débloquer des iPhone ou même d'espionner des utilisateurs iOS à leur insu. Il a souvent fait la une de l'actualité quand des personnalités politiques en vue, dont des dirigeants d'État, ont été espionnées grâce à lui.
En théorie, la société NSO commercialise ce logiciel uniquement à des forces de l'ordre dûment agréées mais ce qui est légitime et acceptable dans un pays ne l'est pas forcément dans un autre où les victimes peuvent être situées.
Voici ce qu'en dit Apple:
"Les appareils Apple sont le matériel grand public le plus sécurisé du marché, mais les entreprises privées qui développent des logiciels espions parrainés par l'État sont devenues encore plus dangereuses. Bien que ces menaces de cybersécurité n'affectent qu'un très petit nombre de nos clients, nous prenons toute attaque contre nos utilisateurs très au sérieux, et nous travaillons constamment à renforcer la sécurité et la protection de la confidentialité dans iOS pour assurer la sécurité de tous nos utilisateurs."

Vu ainsi, la poursuite semble totalement légitime et conforte la rhétorique d'Apple sur la sécurité de ses utilisateurs.
Toutefois, Pegasus n'existe que parce qu'il y a des failles de sécurité et on sait combien le programme d'Apple de rachat de ces failles est faillible avec des non paiements, des non reconnaissances des développeurs...
Bref, Apple dans cette position ne fait que défendre le fantasme commercial qu'elle vend au niveau publicité. On devrait plutôt dire qu'elle vendait car étrangement, on a infiniment moins de publicités à ce sujet depuis quelques semaines.
Il faut être réellement candide pour croire que l'on peut avoir un appareil connecté en permanence au réseau sans risquer de le voir corrompu à un moment ou un autre.
Maintenant, ce ne sont plus des pirates à la petite semaine qui cherchent des failles mais des groupes, étatiques ou pas, et dans tous les cas des ingénieurs très doués et très bien rémunérés, qui inlassablement cherchent toute faille permettant de contourner les protections mises en place.

Avec le jailbreak, Steve Jobs avait parlé d'un jeu de chat et de souris. Il en va de même au niveau de la sécurité globale et les souris ont toujours un coup d'avance.

Le vrai danger n'est pas de savoir que le système est faillible, mais bien de croire qu'il est infaillible.

Donc, quoi qu'en dise Apple, non vos données ne sont pas en totale sécurité sur votre appareil iOS. Elles le sont seulement autant que possible sur un smartphone avec lequel vous êtes en permanence connecté à des dizaines de services et, depuis peu, connecté même s'il est éteint.

Lien vers le billet original

[Jack the best]

La cage de Faraday, y a rien de mieux !

[Patounet1]

La cage de Faraday, y a rien de mieux !

Dans ce cas, pourquoi avoir un téléphone mobile ? Dès que tu l'utilises, il te trahit ! Si tu le laisses dans sa cage, il ne sert pas à grand chose

[linus]

La cage de Faraday, y a rien de mieux !

Dans ce cas, pourquoi avoir un téléphone mobile ? Dès que tu l'utilises, il te trahit ! Si tu le laisses dans sa cage, il ne sert pas à grand chose

A avoir 1000€ dans la poche sous une forme matérielle relativement compacte, peut-être ?

Bon, j'arrive un peu tard dans la discussion mais j'ajoute mon grain de sel.

J'ai un pixel de Google , je peux t'assurer qu'éteint il ne reçoit aucune donnée ni n'en transmet.
Pourquoi ?
Car la mise à jour se charge en fond quand il est allumé et il me demande si je veux l'installer.
Ma compagne a un téléphone android , même chose.

Mais enfin, comment peut on écrire cela ? Si iOS ou Android pouvait faire des mises-à-jour quand le téléphone est éteint, la batterie ne durerait pas des mois comme actuellement. A l'évidence, un téléphone éteint n'échange que de temps en temps et des données minuscules. Ou alors je n'ai vraiment rien compris !

"Le réseau Localiser utilise le chiffrement de bout en bout afin qu’Apple ne puisse voir la position d’aucun appareil hors ligne ni d’aucun appareil transmettant la position."

Ça n'a strictement aucun sens comme de plus en plus souvent lorsqu'on utilise l'expression "chiffrement de bout en bout" (end-to-end encryption).
Preuve en est que le site web de Apple peut afficher la position des appareils.
À partir de là, la notion de "chiffrement de bout en bout" est totalement rebattue, et que donc tout acteur capable faire du MITM en https comme la NSA (au hasard) a alors la possibilité d'accéder à cette information à tout moment. Apple aussi.
Encore une expression qui a été abusée voire corrompue.
Il faut toujours se demander qui génère ou a accès aux clés et en quelles circonstances, et dans le cas d'Apple il y a un beau mensonge par omission...

Est ce qu'il ne faut pas comprendre l'affirmation d'Apple de façon différente. Apple n'est pas assez idiot pour ne pas savoir que ce qui s'affiche sur le web est public. iAPX, je suis donc assez étonné que tu mettes cet argument (tendancieux ?) en avant.
Moi ce que j'avais compris c'est que, hors le moment tu demandes à Apple la localisation de ton iPhone, tous les échanges iPhone-Apple sont cryptés et donc non exploitables pour du traçage malveillant ... excepté via une backdoor bien entendu.

Ce message a été modifié par linus - 25 Nov 2021, 23:09.

[iAPX]

...
Moi ce que j'avais compris c'est que, hors le moment tu demandes à Apple la localisation de ton iPhone, tous les échanges iPhone-Apple sont cryptés et donc non exploitables pour du traçage malveillant ... excepté via une backdoor bien entendu.

Les échanges sont chiffrés, les informations stockées chiffrées, mais Apple et les acteurs de niveau gouvernemental y ont accès.
"Il faut toujours se demander qui génèrent ou possède les clés, sous quelles formes, et qui y a accès et sous quelles conditions. C'est l'arnaque."

Dans ce cas précis, la condition est d'avoir eu accès au mot-de-passe du compte, ainsi qu'à la clé de chiffrement associée à "Find my..." (qui est elle-même chiffrée avec un dérivé du passe).
Apple prétend ne pas pouvoir y avoir accès, c'est d'évidence faux puisqu'on a accès à cette information au travers de son interface Web.
Dans ce cas le "end-to-end" est une arnaque, tout l'inverse de Signal par exemple qui implémente correctement du chiffrement de bout-en-bout, qui ne peut évidemment proposer d'interface Web.

L'historique montre que Apple collabore activement avec certaines agences Américaines et Chinoises, donc elles peuvent suivre tous ceux utilisant "Find my..." même appareil "éteint".

Ce message a été modifié par iAPX - 25 Nov 2021, 23:41.

[downanotch]

Apple prétend ne pas pouvoir y avoir accès, c'est d'évidence faux puisqu'on a accès à cette information au travers de son interface Web.
Dans ce cas le "end-to-end" est une arnaque, tout l'inverse de Signal par exemple qui implémente correctement du chiffrement de bout-en-bout, qui ne peut évidemment proposer d'interface Web.

C'est bien pour cela que tout ce qui est accessible par l'interface web (Photos, iCloud Driver) n'est pas considéré comme chiffré de bout en bout dans la doc d'Apple.

Pour Find My, comme je le comprend, iCloud sert de canal pour transmettre des clés qui sont chiffrées par les appareils (le perdu et le second). Les deux appareils peuvent donc communiquer secrètement. Par contre, si on perd un appareil, avec ce système il faut impérativement un deuxième appareil Apple pour pouvoir localiser le premier. C'est ce cas de figure que la doc Apple détaille. Comme c'est probablement une condition trop restrictive, la possibilité existe de passer par l'interface web, qui aura pour cela besoin de temporairement pouvoir accéder aux messages secrets des deux appareils.

Cet article analyse en profondeur la sécurité de "Find My" et conclut (extrait de l'abstract)

While we find that OF's design achieves its privacy goals, we discover two distinct design and implementation flaws that can lead to a location correlation attack and unauthorized access to the location history of the past seven days, which could deanonymize users. Apple has partially addressed the issues following our responsible disclosure

https://arxiv.org/abs/2103.02282

Ce message a été modifié par downanotch - 1 Dec 2021, 11:55.

[iAPX]

Apple prétend ne pas pouvoir y avoir accès, c'est d'évidence faux puisqu'on a accès à cette information au travers de son interface Web.
Dans ce cas le "end-to-end" est une arnaque, tout l'inverse de Signal par exemple qui implémente correctement du chiffrement de bout-en-bout, qui ne peut évidemment proposer d'interface Web.

C'est bien pour cela que tout ce qui est accessible par l'interface web (Photos, iCloud Driver) n'est pas considéré comme chiffré de bout en bout dans la doc d'Apple.

Pour Find My, comme je le comprend, iCloud sert de canal pour transmettre des clés qui sont chiffrées par les appareils (le perdu et le second). Les deux appareils peuvent donc communiquer secrètement. Par contre, si on perd un appareil, avec ce système il faut impérativement un deuxième appareil Apple pour pouvoir localiser le premier. C'est ce cas de figure que la doc Apple détaille. Comme c'est probablement une condition trop restrictive, la possibilité existe de passer par l'interface web, qui aura pour cela besoin de temporairement pouvoir accéder aux messages secrets des deux appareils.

Cet article analyse en profondeur la sécurité de "Find My" et conclut (extrait de l'abstract)

While we find that OF's design achieves its privacy goals, we discover two distinct design and implementation flaws that can lead to a location correlation attack and unauthorized access to the location history of the past seven days, which could deanonymize users. Apple has partially addressed the issues following our responsible disclosure

https://arxiv.org/abs/2103.02282

Cet article analyse techniquement le fonctionnement de "Find My", en s'arrêtant avant de considérer les moyens d'accéder à ces informations quand possédant le mot-de-passe du compte iCloud (ou un appareil appairé via ce même mot-de-passe qui est la véritable clé).

Ce que j'écris ne couvre QUE l'accès via le mot-de-passe, ou son équivalent la clé de déchiffrement qui en est partiellement dérivée.
Ce que j'écris couvre évidemment les appareils appairés, via encore le mot-de-passe et possédant la clé de déchiffrement récupérée après appairage.

C'est donc complémentaire: les données chiffrées sont maintenant relativement sûres, après leurs trouvailles et les changements afférents, tant qu'on a pas accès au mot-de-passe (ou la clé de déchiffrement qui en est partiellement dérivée).
Et Apple a eu accès à ce mot-de-passe lors de la création du compte et toute modification de celui-ci, a eu accès à (et même créé!!!) la clé de déchiffrement associée, ainsi que tout acteur malveillant capable de faire du MITM https.

Voilà pourquoi Apple a la capacité de tous nous suivre, même appareil "éteint", en omettant joyeusement de décrire la vie de nos mots-de-passe ainsi que celles des clés de déchiffrement dérivées, ou tout acteur de niveau gouvernemental comme par exemple la NSA (par MITM https tant pour le mot-de-passe que les données de géolocalisation).

PS: comme les sessions de icloud.com permettent l'accès, elles contiennent soit le mot-de-passe soit la clé dérivée permettant le même accès, et sont conservées sur la durée (le bouton adéquat au login), pourtant rien n'est indiqué à ce sujet. Là aussi un autre point d'achoppement en terme de sécurité, et d'accès par Apple. Aucune info. Nada!

Ce message a été modifié par iAPX - 2 Dec 2021, 17:07.

[downanotch]

Et Apple a eu accès à ce mot-de-passe lors de la création du compte et toute modification de celui-ci

A la création / modification, le mot de passe n'est pas communiqué tel quel, mais uniquement sous une forme dérivée, non réversible, non ? Ce afin de permettre ensuite de le vérifier pour donner un accès, par exemple à des données qui ne sont pas chiffrées end-to-end sur le serveur.

Les clés de chiffrages end-to-end, dérivées elles aussi du mot de passe mais différemment, requièrent quand à elles le mot de passe pour être utilisables pour déchiffrer les données, le dérivé mentionné précédemment ne suffisant pas.

C'est pas comme ça que c'est sensé fonctionner (en très très gros) pour ce qui est chiffré end-to-end ? Après, rien n'empêche de supposer que l'implémentation est fait de manière à volontairement permettre de contourner une telle sécurité, mais ça, ça reste alors une supposition.