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

[downanotch]

Tu mélange iCloud, le canal de transmission sur lequel les clés transitent de manière chiffrée entre les devices, et iCloud.com, le serveur web à qui tu peux demander d'afficher la position d'un appareil.

Le premier cas peu tout à fait être implémenté avec un chiffrement bout à bout.

[iAPX]

Tu mélange iCloud, le canal de transmission sur lequel les clés transitent de manière chiffrée entre les devices, et iCloud.com, le serveur web à qui tu peux demander d'afficher la position d'un appareil.

Le premier cas peu tout à fait être implémenté avec un chiffrement bout à bout.

Il pourrait mais il ne l'est pas, relit attentivement ce que j'ai proposé à la place comme texte, très différent sur le fond.
"This private key pair and the secret are sent to Apple, encrypted by a key derived from you iCloud password, Apple has access to your password if you are using iCloud thus has full access to these keys since day 1" - iAPX

Apple a accès à ces clés, prétendre l'inverse est un mensonge.
Ou alors tu ne te souviens pas que tu as du donner ton mot-de-passe iCloud sur tes matériels? On a tous des limites

PS: pour les amateurs de chiffrement de bout-en-bout (end-to-end encryption) je recommande de regarder Signal, tout autant en terme de cryptographie que d'implémentation initiale (ils ont rajouté des backdoors dans l'implémentation depuis, sur le modèle de celles de iMessage), où jamais aucun mot-de-passe n'est évidemment demandé ni transmis.

Ce message a été modifié par iAPX - 26 Nov 2021, 21:01.

[downanotch]

Apple a accès à ces clés, prétendre l'inverse est un mensonge.
Ou alors tu ne te souviens pas que tu as du donner ton mot-de-passe iCloud sur tes matériels? On a tous des limites

Visiblement, tu n'a jamais entendu parlé des fonctions de hachage cryptographique… Ou alors tu trolles.

[iAPX]

Apple a accès à ces clés, prétendre l'inverse est un mensonge.
Ou alors tu ne te souviens pas que tu as du donner ton mot-de-passe iCloud sur tes matériels? On a tous des limites

Visiblement, tu n'a jamais entendu parlé des fonctions de hachage cryptographique… Ou alors tu trolles.

Visiblement tu ne comprends pas comment iCloud fonctionne, ni les fonctions de hachage cryptographique... ou alors tu trolles.

Allez pour rire, explique-nous comment avec du hashage cryptographique cela fonctionne quand tu mets ton mot-de-passe dans ton appareil pour qu'il soit reconnu par iCloud?
Attention, iCloud ne devrait stocker le mot-de-passe que hashé, avec un sel aléatoire et inconnu de l'extérieur (évitant les attaques précalculées) par exemple en PBKDF2/sha-2.
Et la réponse est...

Ce message a été modifié par iAPX - 27 Nov 2021, 16:16.

[Hebus]

Apple a accès à ces clés, prétendre l'inverse est un mensonge.
Ou alors tu ne te souviens pas que tu as du donner ton mot-de-passe iCloud sur tes matériels? On a tous des limites

Visiblement, tu n'a jamais entendu parlé des fonctions de hachage cryptographique… Ou alors tu trolles.

Visiblement tu ne comprends pas comment iCloud fonctionne, ni les fonctions de hachage cryptographique... ou alors tu trolles.

Allez pour rire, explique-nous comment avec du hashage cryptographique cela fonctionne quand tu mets ton mot-de-passe dans ton appareil pour qu'il soit reconnu par iCloud?
Attention, iCloud ne devrait stocker le mot-de-passe que hashé, avec un sel aléatoire et inconnu de l'extérieur (évitant les attaques précalculées) par exemple en PBKDF2/sha-2.
Et la réponse est...

Tu fais le malin en balançant des affirmations péremptoires, j’avoue que à part quelques trucs fais autour de OpenSSL et quelques études sur les bitcoins, ces histoire de crypto ne m’intéressent et ne m’ont jamais intéressé vraiment

Mais en cherchant sur PBKDF2/sha-2, on peut lire que Apple s’en sert depuis iOS 3 et à augmenté le nombre d’itération … pas clair si il y a un cryptographic salt ou pas

https://en.wikipedia.org/wiki/PBKDF2?wprov=sfti1

Franchement un truc plus détaillé avec une graphe pour le transit d’informations vaudrait le coup

Note: le deuxième papier pointé est au sujet de FindMy , cacher la localisation géographique, et pas l’accès à iCloud

Ce message a été modifié par Hebus - 28 Nov 2021, 00:39.

[iAPX]

...
Mais en cherchant sur PBKDF2/sha-2, on peut lire que Apple s’en sert depuis iOS 3 et à augmenté le nombre d’itération … pas clair si il y a un cryptographic salt ou pas
...

Eh bien tu en as un devant toi
Et aussi un chercheur en sécurité ayant trouvé un CVSS 9.0 sur MySQL. Mais revenons aux arguments...

En PBKDF2 il y a toujours un sel "salt". Évidemment.
C'est la base et en PBKDF2, le sel est réutilisé à chaque itération "round", permettant alors d'utiliser une méthode de hash médiocre (comme sha-1 voire md5) sans générer de collisions.

PBKDF2 avec sha-2 est un standard de fait, car à la fois sûr, accéléré matériellement (pas d'avantage pour les attaquants de niveau gouvernemental utilisant des ASIC), mais aussi inclut dans la norme Américaine NIST SP800-132, donc répondant parfaitement à de nombreuses contraintes, y-compris réglementaires.
Le nombre d'itérations "round" recommandé augmente régulièrement, pour limiter les risques d'attaque par force-brute, mais essentiellement c'est sûr.

En revanche, Apple ne communique absolument rien sur la façon dont les mots-de-passe de ses usagers vivent dans ces systèmes, qui y a accès, incluant par attaque MITM sur du https (par downgrade TLS/SSL ou pur MITM avec des clés forgées), et donc semble totalement ignorer ou plutôt prétendre ne pas avoir accès aux clés de ses usagers alors que tout indique que c'est le cas!
Idem pour la ou les clés dérivés partiellement de ce mot-de-passe, qui sont essentielles puisque permettant l'accès aux clés de chiffrement/déchiffrement, pas un mot...

Ce message a été modifié par iAPX - 28 Nov 2021, 14:34.