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

[iAPX]

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

Et la cage de Faraday ne sert qu'à protéger de certains types de risques nécessitant une connectivité synchrone.

[downanotch]

Les données sont chiffrées de bout en bout, mais comme Apple est à un bout, elle a accès à ce qui lui est fourni dans la mesure où on lui fourni les clés.

En utilisant l'application Find My pour localiser un appareil, il n'est pas nécessaire de fournir les clés à Apple.

[iAPX]

Les données sont chiffrées de bout en bout, mais comme Apple est à un bout, elle a accès à ce qui lui est fourni dans la mesure où on lui fourni les clés.

En utilisant l'application Find My pour localiser un appareil, il n'est pas nécessaire de fournir les clés à Apple.

Si.

En fait tout usage de iCloud, nécessitant de fournir son mot-de-passe à Apple, via une App Apple et des requêtes d'API ou via le Web, permet à Apple d'avoir accès aux clés mais aussi à tout attaquant pouvant monter une attaque MITM de niveau gouvernemental.
La clé n'est pas stockée dans l'appareil, mais stockée chiffrée (encore lui!) du coté de Apple, expliquant qu'on ai accès à ces mêmes fonctionnalités depuis un autre appareil Apple en rentrant ses identifiants+mot-de-passe iCloud.

Donc on arrête les conneries, Apple a accès aux clés, peut les transmettre à toute agence en faisant la demande, ainsi que tout attaquant capable de monter un MITM https.
Comme l'a démontré l'affaire ProtonMail, personne n'est à l'abri, et surtout pas avec des systèmes et sociétés nous le promettant

Ce message a été modifié par iAPX - 25 Nov 2021, 18:57.

[Hebus]

Les données sont chiffrées de bout en bout, mais comme Apple est à un bout, elle a accès à ce qui lui est fourni dans la mesure où on lui fourni les clés.

En utilisant l'application Find My pour localiser un appareil, il n'est pas nécessaire de fournir les clés à Apple.

Si.

En fait tout usage de iCloud, nécessitant de fournir son mot-de-passe à Apple, via une App Apple et des requêtes d'API ou via le Web, permet à Apple d'avoir accès aux clés mais aussi à tout attaquant pouvant monter une attaque MITM de niveau gouvernemental.
La clé n'est pas stockée dans l'appareil, mais stockée chiffrée (encore lui!) du coté de Apple, expliquant qu'on ai accès à ces mêmes fonctionnalités depuis un autre appareil Apple en rentrant ses identifiants+mot-de-passe iCloud.

Donc on arrête les conneries, Apple a accès aux clés, peut les transmettre à toute agence en faisant la demande, ainsi que tout attaquant capable de monter un MITM https.
Comme l'a démontré l'affaire ProtonMail, personne n'est à l'abri, et surtout pas avec des systèmes et sociétés nous le promettant

Détaille un peu alors par rapport à ce qui est affirmé ici que avec le double-factor… ils ne peuvent pas acccéder à nos infos ? Ça me paraît intéressant pour tout le monde ici.

En fait si tu accèdes d’un autre appareil à iCloud tu dois faire intervenir aussi ton iPhone, puisque des data de l’iPhone servent aussi à décrypter le paquet de data qui transitent, à ce qui peut se comprendre de leur texte.

End-to-end encryption
End-to-end encryption provides the highest level of data security. On each of your devices, the data that you store in iCloud and that's associated with your Apple ID is protected with a key derived from information unique to that device, combined with your device passcode which only you know. No one else, not even Apple, can access end-to-end encrypted information.

End-to-end encryption requires that you use two-factor authentication for your Apple ID and set a passcode on your device. Some features also require recent software, generally iOS 13 or later. With two-factor authentication, your account can be accessed only on devices you trust, like your iPhone, iPad, or Mac. Keeping your software up to date, using two-factor authentication for your Apple ID, and protecting your device with a passcode—or password on Mac—Face ID, or Touch ID are the most important things that you can do to maintain the security of your devices and data.

iCloud security overview

Ce message a été modifié par Hebus - 25 Nov 2021, 19:17.

[Fars]

Comme l'a démontré l'affaire ProtonMail, personne n'est à l'abri, et surtout pas avec des systèmes et sociétés nous le promettant

Salut IAPX, c'etait quoi l'affaire Protomail?

[iAPX]

Détaille un peu alors par rapport à ce qui est affirmé ici que avec le double-factor… ils ne peuvent pas acccéder à nos infos ? Ça me paraît intéressant pour tout le monde ici.
...

Le 2FA ou MFA ne sert qu'à valider l'accès au compte.
Alors que le mot-de-passe est utilisé pour valider celui-ci mais aussi sert à deriver une clé de chiffrement qui protège nos données et nos autres clés dans iCloud.
(c'est d'ailleurs peu-ou-prou ce qu'est la Recovery Key).

Il est possible de demander accès à nos clés, incluant celles utilisées dans "Find my...", mais elles ne sont censé être stockées que chiffrées par Apple, donc inutilisable.
La connaissance du mot-de-passe employé (ou de la Recovery Key) permet à tout moment de déchiffrer ces clés.
C'est pour ça que sans avoir lu ce document, je peux parier qu'ils n'indiquent nulle part ce qui advient de nos mot-de-passe, hors stockage (probablement en PBKDF2/sha-2).

La clé de chiffrement est chez Apple, notre mot-de-passe sert à y accéder, le problème est qu'il se ballade partout, donc la clé de chiffrement n'est pas protégée.
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.

En résumé, "end-to-end encryption" ou "chiffrement de bout en bout" est généralement du blahblah de PR. Avec quelques exceptions notables.

Comme l'a démontré l'affaire ProtonMail, personne n'est à l'abri, et surtout pas avec des systèmes et sociétés nous le promettant

Salut IAPX, c'etait quoi l'affaire Protomail?

ProtonMail qui prétend n'avoir pas de logs, mais qui en a créé à la demande de la Justice Suisse où ils sont basés, au moins pour un compte.
Ils n'ont pas de logs, mais si une agence US le désire, ils en créeront...

Ce message a été modifié par iAPX - 25 Nov 2021, 19:44.

[Hebus]

Un doc explicatif intéressant qui permet d’y voir plus clair :

https://blog.elcomsoft.com/2021/01/apple-sc...icloud-backups/

[iAPX]

Un doc explicatif intéressant qui permet d’y voir plus clair :

https://blog.elcomsoft.com/2021/01/apple-sc...icloud-backups/

Il y a là aussi un gros mensonge, puisque pour ce qui concerne la Chine, la société gérant les serveurs a des clés maîtres de déchiffrement, et elle est contrôlée par le Parti Communiste Chinois.

Apple a indirectement mis entre les mains du pouvoir Chinois les informations de tout ses usagers du crû...

PS: tout l'aspect technique est totalement foireux, il ne comprends absolument rien mais sait mettre des buzzwords!
Imaginons que le chiffrement bout-en-bout soit protégé par le code PIN, comme il le suggère pour un iPhone, ça ne prendrait évidemment qu'une fraction de seconde en moyenne pour tout déchiffrer.
Et on ne pourrait pas plus accéder aux informations depuis un Mac dans lequel on ne rentre JAMAIS ce même code PIN. Du PR bien bien pourri.

Ce message a été modifié par iAPX - 25 Nov 2021, 21:18.

[Hebus]

Un doc explicatif intéressant qui permet d’y voir plus clair :

https://blog.elcomsoft.com/2021/01/apple-sc...icloud-backups/

Il y a là aussi un gros mensonge, puisque pour ce qui concerne la Chine, la société gérant les serveurs a des clés maîtres de déchiffrement, et elle est contrôlée par le Parti Communiste Chinois.

Apple a indirectement mis entre les mains du pouvoir Chinois les informations de tout ses usagers du crû...

PS: tout l'aspect technique est totalement foireux, il ne comprends absolument rien mais sait mettre des buzzwords!
Imaginons que le chiffrement bout-en-bout soit protégé par le code PIN, comme il le suggère pour un iPhone, ça ne prendrait évidemment qu'une fraction de seconde en moyenne pour tout déchiffrer.
Et on ne pourrait pas plus accéder aux informations depuis un Mac dans lequel on ne rentre JAMAIS ce même code PIN. Du PR bien bien pourri.

Ok, oui il le dit parfaitement également, mais je pense qu’il manque une pièce dans cette histoire sinon l’affirmation d’Apple serait trop facile à démonter et l’aurait été de manière évidente et sonore … hors je ne trouve pas de trace de ce genre de discours…

Vu que lorsque l’on doit faire la double authentification cela doit venir d’un appareil apple .. je suppose que cet appareil intervient dans le process pas seulement pour le code, qui plus est il faut un appareil avec un OS récent pour cette fonctionnalité

Ce message a été modifié par Hebus - 25 Nov 2021, 21:37.

[iAPX]

L'authentification sur un système distant n'a absolument rien à voir avec l'accès à des données chiffrées, excepté qu'ils utilisent le même mot-de-passe comme origine.
Pas besoin pour une agence gouvernementale de s'authentifier d'une quelconque façon pour déchiffrer les données d'un utilisateur de iCloud.

La première étape est de demander les données chiffrées à Apple, ce que la société remet sans aucun problème, ou de les capturer en MITM https (invisible).
La seconde étape consiste à utiliser le mot-de-passe de l'utilisateur, soit capturé par MITM soit en attaque par force-brute, pour en dériver la clé de chiffrement/déchiffrement de ces données.
La troisième étape, la plus simple, reste juste à déchiffrer.

Un attaquant de niveau gouvernemental a généralement accès aux données chiffrées, via les contraintes légales imposées à Apple.
Il n'est besoin en rien de s'authentifier, et -au pire- Apple pourrait l'autoriser aussi, le 2FA ou MFA n'étant qu'une validation d'accès, alors que le mot-de-passe ouvre la boîte de Pandore.

Un exemple, quand tu branches un stockage chiffré sur ton propre ordinateur, pas besoin de t'authentifier de nouveau, juste de connaître un des mots-de-passe protégeant ces données, les mécanismes étant très similaires.

Ce message a été modifié par iAPX - 25 Nov 2021, 21:46.

[linus]

"Sans vouloir t'offenser tu ne confonds pas la veille et le fait de l'éteindre ?" il confond probablement, bien peu de dispositifs sont encore connectés lorsqu'ils sont éteints. À l'exception de certains systèmes de sécurité c'est totalement marginal.

Pas du tout, c'est très général au contraire. Quand tu coupes le contact de ta voiture, il y a des tas de choses qui restent alimentées, par exemple le système d'ouverture des portes. Sur les voitures haut de gamme, il y a surement aussi le système de géolocalisation comme sur les smartphones.
Pour que qu'une voiture soit éteinte, il faut débrancher la batterie ... sauf dans les futures voitures Apple, bien entendu !

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

[DOMY]

Je suis l'actualité au jour le jour ..... et je vois tous les jours des gens d'extrême droite, d'extrême gauche, des politiques de tous bords, des terroristes se faire " crever " malgré leur usage de messageries soit disant " cryptées ".

En fait, ça ne vaut plus grand chose ce truc ?

Ce message a été modifié par DOMY - 25 Nov 2021, 23:56.

[iAPX]

Je suis l'actualité au jour le jour ..... et je vois tous les jours des gens d'extrême droite, d'extrême gauche, des politiques de tous bords, des terroristes se faire " crever " malgré leur usage de messageries soit disant " cryptées ".

En fait, ça ne vaut plus grand chose ce truc ?

Pour moi ça protège beaucoup moins que ce qu'on pourrais penser, et surtout bien moins que ce qui est prétendu.

Un secret n'est plus un secret si quelqu'un d'autre le connait, et maintenant ça vaut pour les systèmes d'information.

[DOMY]

Séquence nostalgie pour les anciens .....

https://fr.wikipedia.org/wiki/Pretty_Good_Privacy
https://fr.wikipedia.org/wiki/Philip_Zimmer...ilip_Zimmermann

Philip Zimmermann a été le premier à mettre à la disposition du public un logiciel de chiffrement facilement utilisable fondé sur la technique de la clé asymétrique (ou clé publique).
Cela lui valut une enquête criminelle de trois ans de la part des Douanes américaines, au prétexte d'avoir violé les restrictions sur l'exportation de logiciels de cryptographie en diffusant PGP dans le monde entier (PGP avait été publié en 1991 sur le web comme logiciel libre).

Ce message a été modifié par DOMY - 26 Nov 2021, 00:20.

[downanotch]

iCloud security overview

Et surtout : https://support.apple.com/guide/security/fi...bc80fd0/1/web/1

[iAPX]

iCloud security overview

Et surtout : https://support.apple.com/guide/security/fi...bc80fd0/1/web/1

Et voilà le premier mensonge de Apple:
"This private key pair and the secret are never sent to Apple and are synced only among the user’s other devices in an end-to-end encrypted manner using iCloud Keychain."

La synchronisation se fait bien au travers de Apple, qui reçoit bien la clé privée.
Sinon il serait impossible de synchroniser au travers de iCloud.

Il y a des mensonges évidents, clairs: vous ne pouvez en aucun cas faire confiance à Apple.

"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

PS: si on ne comprend pas, on demande, au lieu de jouer les idiots utiles pour Apple.
Et quand Apple utilise l'expression "end-to-end encryption" (chiffrement de bout en bout), c'est un mensonge PR. Ça n'est pas Signal.

Ce message a été modifié par iAPX - 26 Nov 2021, 17:25.

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

[chombier]

Le "hashage cryptographique"... Nous avons ici affaire à des experts.

Et sinon, les ordinateurs quantiques en seraient déjà à 127 qbits ?

[linus]

Je suis l'actualité au jour le jour ..... et je vois tous les jours des gens d'extrême droite, d'extrême gauche, des politiques de tous bords, des terroristes se faire "crever" malgré leur usage de messageries soit disant "cryptées".
En fait, ça ne vaut plus grand chose ce truc ?

Pour moi ça protège beaucoup moins que ce qu'on pourrais penser, et surtout bien moins que ce qui est prétendu.

Un secret n'est plus un secret si quelqu'un d'autre le connait, et maintenant ça vaut pour les systèmes d'information.

Je me permets de rappeler ce que j'avais dit ici il y a 2 ou 3 ans au sujet d'une conférence donnée par l'un des principaux experts français du développement d'algorithmes de cryptage. Quelqu'un dans la salle lui a demandé si son labo essayait de casser les cryptages des concurrents. Il a répondu à peu près, "A titre d'exercice on a monté une machine pour ça, les cryptages les plus robustes résistent entre 1/2h et quelques heures" Quand j'ai rapporté cela, je me suis fait insulter sur MacBidouille. iAPX était plus que dubitatif je crois. Je vois qu'il doute moi maintenant.

[iAPX]

Je suis l'actualité au jour le jour ..... et je vois tous les jours des gens d'extrême droite, d'extrême gauche, des politiques de tous bords, des terroristes se faire "crever" malgré leur usage de messageries soit disant "cryptées".
En fait, ça ne vaut plus grand chose ce truc ?

Pour moi ça protège beaucoup moins que ce qu'on pourrais penser, et surtout bien moins que ce qui est prétendu.

Un secret n'est plus un secret si quelqu'un d'autre le connait, et maintenant ça vaut pour les systèmes d'information.

Je me permets de rappeler ce que j'avais dit ici il y a 2 ou 3 ans au sujet d'une conférence donnée par l'un des principaux experts français du développement d'algorithmes de cryptage. Quelqu'un dans la salle lui a demandé si son labo essayait de casser les cryptages des concurrents. Il a répondu à peu près, "A titre d'exercice on a monté une machine pour ça, les cryptages les plus robustes résistent entre 1/2h et quelques heures" Quand j'ai rapporté cela, je me suis fait insulter sur MacBidouille. iAPX était plus que dubitatif je crois. Je vois qu'il doute moi maintenant.

Non, les chiffrages les plus robustes ne sont pas cassables autant qu'on sache (une affaire de limitation de taille de l'univers et de sa durée de vie): je ne parle pas de méthode de chiffrement, je parle d'implémentations, et dans ce que tu as cité du maillon le plus faible.

Ergo, voilà ma clé publique ( ~/.ssh/id_rsa.pub ):

Code

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDd2GOPn2pL2S4VWRhxriCx4mLMr33CXS6Y8AbtKd+TBntcWD61
m8h8agRZXFlVE3pEHpBZJzyFTCc/RCg7FaV2nv62SYja+9Ex2aMdYl5SYW2JIAhUmNHHvooYw11FwnxoZTZMkHYrs
di4PVJBtR3QbRUQ3cG/7XeeU+lkb4Rvza4f4ZXUF/Ym2M1IDMCvjDTB1hN2fih+z62PyfymbBrpmLDYD+WlVrbJu3V
1yPYML+g5WfeRnmUFHj2ta/Y/Rjs3P7FLUFKVmdRrYruSTPwokH3cgxfp96cYzQIvDld/A1Gt69mbLt9g8+75BWZOM
yDLcO3G20VHhg6X5WZgXdSx [email protected]

Revenez-moi avec ma clé privée
Comme c'est noël, j'offre une bouteille de Krug Clos du Mesnil de ma cave pour celui capable de me fournir ma clé privée (ou toute clé privée acceptée comme valable en regard à ma clé publique, donc déverrouillant l'accès à mes serveurs).

En résumé, on sait chiffrer fortement, sans avoir de risque connu (notez ce mot!) aujourd'hui (notez celui-ci aussi!).
En revanche, en général, les implémentations sont foireuses si pas truffées de backdoors, comme chez Microsoft, CISCO ou surtout Apple.
Microsoft ayant outre ses backdoors, fait d'immenses efforts pour affaiblir la sécurité des chiffrements proposés aux utilisateurs de Office, pour qu'ils soient cassables facilement.

Ce message a été modifié par iAPX - 28 Nov 2021, 00:43.

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

[coverband]

Ce message a été modifié par coverband - 28 Nov 2021, 01:34.

[vlady]

J'ai l'impression qu'Apple n'a jamais prétendu avoir un "vrai" chiffrement end-to-end. Tout le monde le sait, en tout cas, moi, je le sais. Pourquoi ? Toujours la même raison, la convenance. Apple est capable de "restaurer" l'accès aux données si madame Michu a pommé son mot de passe. Et ce n'est pas un défaut, c'est une feature.

[downanotch]

J'ai l'impression qu'Apple n'a jamais prétendu avoir un "vrai" chiffrement end-to-end. Tout le monde le sait, en tout cas, moi, je le sais. Pourquoi ? Toujours la même raison, la convenance. Apple est capable de "restaurer" l'accès aux données si madame Michu a pommé son mot de passe. Et ce n'est pas un défaut, c'est une feature.

Ben justement non, ce qui end-to-end n'est PAS récupérable :

Si vous oubliez votre mot de passe ou le code d’accès de votre appareil, le service de récupération de données iCloud peut vous aider à déchiffrer vos données afin que vous puissiez regagner l’accès à vos photos, notes, documents, sauvegardes d’appareils, etc. En revanche, ce service ne vous permet pas d’accéder aux types de données qui sont protégés par le chiffrement de bout en bout, comme les données de votre trousseau, de l’app Santé, de l’app Messages et de l’app Temps d’écran. Les codes d’accès de vos appareils, que vous seul connaissez, sont requis pour déchiffrer et accéder à ces données. Vous seul pouvez accéder à ces informations, et uniquement à partir des appareils sur lesquels vous êtes connecté à iCloud.

https://support.apple.com/fr-fr/HT202303

Ce message a été modifié par downanotch - 29 Nov 2021, 08:40.