Thread by @MathisHammel

Cette semaine, #Apple a annoncé une nouvelle feature dans iOS 15 qui scannera l'album photo des utilisateurs d'iCloud à la recherche de contenus pédo-pornographiques.

J'ai étudié le protocole cryptographique sous-jacent, et je vous propose un #Thread de vulgarisation.

Je me suis paluché la publication scientifique d'Apple, 32 pages de notation mathématique assez touffue que je vais me charger de simplifier. Première surprise, le papier est co-écrit par Dan Boneh, une pointure en cryptographie (membre émérite de l'IACR, prix Gödel, ...)

Comme je le rappelais en réaction à un titre d'article un peu trop clickbait, la détection se fait sur une liste de photos pré-établie pour limiter au maximum le risque de faux positifs.

Le protocole est bien construit, il s'appuie sur trois composants principaux qui assurent une protection de la vie privée, malgré cette intrusion assez directe dans les données perso. J'ai cependant identifié quelques problèmes sur lesquels je reviendrai en fin de thread.

N.B. : on ne se penchera pas sur le 2e mécanisme de protection de l'enfance annoncé par Apple, à savoir la détection de nudité dans les photos envoyées vers/depuis des appareils soumis au contrôle parental. Je n'ai pas la légitimité d'expert en vie privée pour cette analyse.

On va étudier dans trois mini-chapitres les composants du protocole d'Apple, qui ont chacun des propriétés très intéressantes.

I. NEURALHASH

NeuralHash est un algorithme de hachage d'images basé sur un réseau de neurones. Ici, pas question d'utiliser un hash cryptographique conventionnel comme SHA256, car il serait possible de contourner la détection en modifiant un seul bit de l'image.

Dans notre protocole, le réseau de neurones est entraîné pour "comprendre" la structure de l'information et donner le même hash à deux images visuellement identiques, tout en résistant aux transformations comme l'ajout de bruit, le recadrage, la compression, ...

Le réseau transforme une image en un vecteur de nombres. Le réseau est entraîné à partir d'images dérivées d'un ensemble d'images de base. Il produit des vecteurs proches si les deux images ont la même base, et éloigné sinon.

Très similaire à word2vec pour ceux qui connaissent :

Ce type de hachage existe déjà, avec notamment PhotoDNA de Microsoft (qui a d'ailleurs été créé en 2009 pour combattre l'exploitation des mineurs).

J'utilise aussi ce type de réseau de neurones dans un outil que je dévoilerai lors de ma prochaine conférence, à @_barbhack_ ! 😇

Les NeuralHashs sont la base du système de détection proposé. Mais ils ne sont pas transmis directement à Apple pour comparaison avec la base de données d'images illégales, ce serait une entorse au chiffrement end-to-end d'iCloud.

On en reparle au chapitre III 😉

II. THRESHOLD SECRET SHARING

Le système de détection d'images pédo-pornographiques envoie à Apple des métadonnées sur les images détectées. En cas de faux positif, Apple pourrait accéder aux métadonnées correspondantes sans raison valable, et c'est pour cette raison qu'un seuil a été mis en place.

En dessous de N correspondances avec la base de données, un mécanisme cryptographique (que les initiés voient venir d'après son nom) empêche de lire les métadonnées. Le nombre N de correspondances nécessaires n'a pas été rendu public (je pense qu'il est entre 3 et 5).

Le principe sous-jacent au Threshold Secret Sharing ne date pas d'hier : en 1979, Adi Shamir (éminent cryptologue, la lettre S du cryptosystème RSA c'est lui) publie son "Secret Sharing Scheme" (SSS), qui permet de partager une donnée secrète de manière très élégante.

Le SSS permet de découper un nombre secret en plusieurs parts, de telle sorte que l'on peut reconstituer le secret d'origine seulement si l'on dispose d'au moins K parts (K est un paramètre choisi lors de la création des parts). On va prendre un petit exemple :

Quand je meurs, je veux que ma famille ait accès à mon compte Twitter pour continuer à liker les tweets de @plhery. Mais pas question de donner à chacun mon mdp dès maintenant ! Je peux donc créer des parts de mon mdp avec un seuil K=3, et j'en donne une à chacun de mes proches.

À tout moment, il suffira que 3 de mes proches (peu importe lesquels) mettent leurs parts en commun et ils pourront reconstituer le mdp. SSS est beaucoup plus fort que de donner à chacun quelques caractères du secret, car ici n'importe quelle combinaison de 3 parts fonctionne !

Le système Threshold Secret Sharing fonctionne à peu près de la même manière : pour chaque correspondance avec la base de données d'images illégales, l'appareil fait remonter des métadonnées qui sont chiffrées à l'aide d'une clé générée par l'appareil de l'utilisateur.

Apple n'a initialement pas cette clé et ne peut donc déchiffrer aucune métadonnée. Par contre, avec chaque match remonté est aussi fourni un fragment SSS de la clé. Après N rapports remontés, Apple peut donc reconstituer la clé et déchiffrer les métadonnées associées à ceux-ci.

Un autre mécanisme permet aussi de cacher à Apple le nombre exact de matchs : des matchs "synthétiques" contenant des faux fragments de clés sont produits aléatoirement par tous les appareils, et Apple n'a aucun moyen de distinguer les vrais des faux avant d'en posséder N vrais.

III. PRIVATE SET INTERSECTION

Dans les deux précédents chapitres, on a étudié comment les images étaient comparées de manière fiable, et comment les matchs dans la base d'images étaient masqués avant d'avoir atteint un seuil. Mais le vrai coeur du protocole c'est PSI, ou Private Set Intersection.

Il y a plusieurs considérations à prendre en compte :
- Apple ne veut pas dévoiler la liste d'images recherchées (sûrement pour éviter les contournements)
- On ne doit pas divulguer à Apple la moindre info sur les images non-illégales d'un utilisateur, pas même leur NeuralHash

Ce problème semble impossible à résoudre : Apple et l'utilisateur ont chacun une liste de NeuralHashs et on cherche à savoir quels sont ceux qui sont en commun, sans que l'un divulgue à l'autre la moindre information sur ses propres NeuralHashs. Et pourtant, PSI le fait !

Apple commence par calculer les NeuralHashs des images qui l'intéressent, puis les place dans un tableau (spécifiquement une cuckoo table, pour éviter les collisions). L'index du NeuralHash dans le tableau est calculé à partir de sa valeur uniquement.

Ces NeuralHashs sont ensuite masqués (blinded) à l'aide d'une clé détenue par Apple, mais ils gardent leur index dans la table. Les autres index non utilisés sont remplis de hashs aléatoires masqués, pour ne pas révéler quels sont les index qui intéressent Apple.

Ce tableau est transmis aux appareils des utilisateurs. La première contrainte (ne pas dévoiler les images recherchées) est respectée, car l'utilisateur n'a aucun moyen de retrouver les NeuralHashs de la liste d'Apple sans posséder également la clé de masquage tenue secrète.

Pour établir les correspondances entre les photos de l'utilisateur et celles recherchées sans connaître la liste de ces dernières, l'utilisateur va en fait envoyer des informations sur TOUTES ses photos, mais Apple ne saura déchiffrer que celles qui correspondent à sa liste.

Chacune des photos va donc être traitée de la manière suivante : on calcule d'abord une clé de chiffrement basée à la fois sur le NeuralHash de l'image et sur le NeuralHash masqué à l'index associé (qui potentiellement ne correspondra pas, si l'image n'est pas dans la base).

Cette clé nous sert à chiffrer le duo de {métadonnées image + fragment de clé des métadonnées} dont on parlait au chapitre précédent sur le Threshold Secret Sharing. Ces infos chiffrées sont transmises au serveur d'Apple avec une sous-partie de la clé du tweet précédent.

Des propriétés super chouettes des courbes elliptiques permettent à Apple de reconstituer la clé à partir de la sous-partie qui lui est transmise, à condition que celle-ci ait bien été générée à partir d'un NeuralHash et de sa version masquée correspondante.

Ainsi, on s'assure de deux choses :
- Le message ne peut être déchiffré que si le NeuralHash fait aussi partie de la liste d'Apple
- Apple ne peut pas tricher en ajoutant un NeuralHash à sa liste a posteriori, car le hash masqué est pris dans la liste au moment du calcul de clé

Pour résumer, le protocole d'Apple est basé sur une sécurité à deux couches : un message ne peut être déchiffré que si l'image correspond à un hash recherché, et la clé permettant de déchiffrer les métadonnées de ces matchs n'est récupérée qu'après N correspondances avérées.

EPILOGUE

On peut cependant relever plusieurs risques opérationnels sur le protocole proposé par Apple.

La première attaque qui me vient à l'esprit est basée sur des attaques antagonistes contre NeuralHash. En effet, il est généralement simple de faire dire ce que l'on veut à un réseau de neurones avec un input malicieux bien calculé.

Il suffirait donc de forger des images d'apparence tout à fait inoffensive qui auraient le même NeuralHash que des images pédo-pornographiques recherchées par Apple, et de les envoyer à son ennemi juré pour déclencher une enquête à son encontre.

Second problème, bien plus important : seul Apple connaît les images qui composent sa base de données. Qui contrôle que ce sont effectivement des contenus pédo-pornographiques et non des images d'opposition politique ou de contenu LGBT (jugé illégal dans plusieurs pays) ?

Dans cette même veine, qui garantit que cette liste est la même pour tout le monde et qu'un gouvernement autoritaire ne peut pas forcer Apple à modifier sa liste sous peine de sanctions ?

À mon avis, il est vital d'avoir des observateurs tiers sur ce système, et il semblerait qu'Apple ne prévoit pas cette supervision externe. L'opacité de la liste de fichiers offre certes des avantages contre le contournement des filtres, mais c'est aussi un danger.

Pour conclure, la cryptographie du protocole PSI est effectivement un très bon système pour assurer la protection de l'enfance sans empiéter sur la vie privée (pour relativiser avec la censure de WeChat : citizenlab.ca/2020/05/we-cha…), mais il est imparfait et manque de garde-fous.