Effectivement c’est un bon cru.
Tim n’est pas prêt de lâcher!
1 « J'aime »
Eclairage sur la possible source du FBI :
1 « J'aime »
Le FBI s’est débrouillé tout seul pour récupérer les données sur l’iPhone, et a annulé une audience entre Apple et le département de la justice : http://www.cnet.com/news/feds-unlock-iphone-5c-used-by-san-bernardino-terrorist-dont-need-apple/
Ici un article du nytimes intitulé "U.S. Says It Has Unlocked iPhone Without Apple"
Je n’ai pas encore eu le temps de le lire, verrai ça demain.
Je viens de tomber sur un très bon résumé de l’affaire:
FBI: Aller faites le, c’est juste pour UN téléphone, promis
Apple: Non, il y en aura d’autres …
FBI: Laissez tomber, on est arrivé à rentrer
Apple: Vous devriez nous dire comment, vu que c’était juste pour ce téléphone
FBI: Non, il y en aura d’autres …
4 « J'aime »
Apparement c’est une société israélienne qui a aidé le FBI…
Et ils se sont fait Tor aussi dans la foulée:
tranquil…
La meilleure sécurité c’est le combo machine à écrire + la cheminée
les deux sont a baffer, ok Apple donne pas la méthode mais après avoir refusé et cassé les burnes du FBI, venir réclamer comment ils ont fait et penser que les autres la bouche en coeur allaient leur donner …
Ils ont rien “réclamé” stop relayer les infos de merde aussi…
C’est comme tous les guignols qui s’affolaient sur l’injustice de Nintendo d’avoir viré une meuf hier… “because harcèlement et gnagnanga”. Y’en a pas un qui creusé pour piger qu’à la base qu’elle était viré pour avoir fait des tofs à moitié à poil avec des produits NINTENDO, et qu’elle faisait du NSFW régulièrement en taf secondaire. Quelle bonne idée…
Bref. Si Apple demande un truc (c’est déjà pas réclamer), c’est aussi pour bien montrer que le FBI se fout de la gueule du monde depuis le début.
2 « J'aime »
Surtout que normalement les « white hat » sont sensés communiquer les failles qu’ils trouvent pour améliorer la sécurité par la suite.
Si tu communiques pas les failles, ça indique donc de quel côté tu te trouves 
Enfin c’est vrai qu’il ne faut pas être naif. Si d’aventure un jour ils communiquent comment c’est passé, ça voudra dire qu’ils ont trouvé un autre moyen.
1 « J'aime »
D’après certaines news de l’époque, c’est exactement ce qu’envisageait les allemands après le scandale d’espionnage par la NSA sur ses alliés (da bum tss.mp3). 
Scandale qui n’aura eu aucune suite et aura fait bien moins de bruit qu’un smartphone. 
Petit déterrage à la suite des annonces d’Apple qui veut scanner les téléphones à la recherche de contenu pédoporn.
Sans que j’y comprenne grand chose, je suis tombé sur une analyse du papier technique qu’ils ont publié - et c’est pas un communique de presse.
L’auteur garde quelques réserves (quid des pays totalitaires ou du contrôle externe), mais techniquement Apple ne va pas venir mater toutes vos photos de vacances par-dessus votre épaule.
3 « J'aime »
Très bon thread en effet, merci @JeeP
Je me permets de partager ce lien qui rend le truc plus simple à lire:
J’ai repensé à la pseudo analyse du mec de Hacker Factor que je commentais dans un autre thread. Il écrivait:
Apple’s technical whitepaper is overly technical – and yet doesn’t give enough information for someone to confirm the implementation […] if it looks really technical, then it must be really good. Similarly, one of Apple’s reviewers wrote an entire paper full of mathematical symbols and complex variables.
J’en avais conclu qu’il faisait pas mal d’erreur, ce thread le confirme 
Si je devais réagir au thread ça serait sur sa conclusion où il mentionne 2 failles possibles:
https://fxtwitter.com/MathisHammel/status/1425524749460021251
Sur le principe c’est vrai mais au-dessus il écrit que le protocole masque les hashs dans une table (remplie de faux hashs masqués aussi) et ce n’est que les index qui intéressent Apple.
Ca me parait difficile du coup de générer des images qui match un hash étant donné que les hashs ne sont pas connus.
2eme point:
https://fxtwitter.com/MathisHammel/status/1425524750961586181
La 1ere partie est fausse étant donné que les images sont fournies par le National Center for Missing and Exploited Children (NCMEC).
Par contre la 2eme partie est vraie mais je vois plus une faille du côté du NCMEC que d’Apple. Est-ce que cette organisation est à l’abri d’une modification de la base à son insu?
Je suppose que le check manuel du côté d’Apple avant tout « dénonciation » au NCMEC (et pas aux autorités directement) devrait rendre cette faille inefficace.
3 « J'aime »
Apple utilise Slack :
Si Schneier dit que c’est pas un bonne idée, j’aurais tendance à le croire. Faudra voir comment Apple va répondre quand on verra débarquer les images innofensives qui déclencheront les alertes.
1 « J'aime »
Edward Snowden est bien remonté contre Apple :
Je c/c rapidement ces 2 articles là que je n’ai pas lu (encore) à défaut de link tous les tweets qu’il a fait sur le sujet (que j’ai lu là pour le coup mais trop chiant à c/c, sorry).
Deja prévu. En gros, le système upload le hash et un « visual derivative », c’est en gros une copie de l’image transformée (j’ai lu « blurred thumbnail » quelque part). Si jamais cette image produit le même hash, le serveur regarde si le « visual derivative » de ton image est identique au « visual derivative » du CSAM.
Donc aucune image qu’on voit passer en ce moment ne va trigger ce second contrôle
Autre point qui semble oublié, la fameuse table de hashs que les gens pensent avoir trouvé dans la dernière version d’iOS n’est pas la bonne. Elle est elle-même cryptée et remplie de faux.
Dans le texte que tu cites ils appellent ça un « second independant perceptual hash ». Donc un hash grossièrement basé sur le visuel de l’image si j’ai bien compris. Ça pourrait être une image en petit et flouté, mais bon, au final ça reste un deuxième hash, c’est juste qu’il ne pourra pas y avoid de collisions si les images ne sont pas très similaires.
Du coup il me semble que c’est un système mis en place surtout pour gérer les cas où deux image très différentes se retrouvent avec le même neuralhash (ce qui est d’autant plus possible vu que le match de 2 neuralhashs est basé sur un seuil limite et pas un match parfait) - mais ce n’est pas adapté pour se défendre contre des attaques malveillantes où les images sont générées dans le but de créer des collisions.
Tu peux déjà voir dans le lien sur les collisions cité par l’article que j’ai partagé (Working Collision? · Issue #1 · AsuharietYgvar/AppleNeuralHash2ONNX · GitHub) que des gens arrivent à créer des collisions avec des images qui ressemblent « en gros » à d’autres images - du coup il y a fort à parier que d’ici pas longtemps, on pourra creer des images dont les deux neuralhashs ainsi que les « visual derivatives » sont des match, mais où l’image ne ressemblera que vaguement à l’image ciblée (juste assez pour passer le deuxième hash). Du coup on peut s’attendre à des reviewers humains chez Apple débordés par une grande quantité de faux-positifs générés juste pour faire chier. Quand en face tu as des petits malins, je ne pense pas que si un seul hash ne marche pas, la solution soit de mettre 2 hashs…
Un autre point intéressant qu’on peut voir dans le lien donné ci-dessus est que si tu rajoutes une bordure de 1000 pixels random autour de ton image originale (sans rien changer d’autre), son neuralhash change complètement. Du coup, si quelqu’un veut pouvoir stocker des photos CSAM sur ses device Apple sous forme regardable facilement sans se faire chopper, il sait comment faire…
Donc au final je vais continuer de me fier à la conclusion de Schneier: « This was a bad idea from the start, and Apple never seemed to consider the adversarial context of the system as a whole ».
Je ne parierais pas dessus car cette fois les hashs sont côté serveur, que personne ne les connaît, que l’iphone ne sait pas ce qui match et qu’en plus il upload régulièrement des dummys pour ne pas qu’on puisse tester quelles images trigger le seuil.
C’est un tout autre problème et c’est en effet assez décevant, tout comme le fait de pouvoir à priori cropper l’image.