Google Research a annoncé un système d'apprentissage fédéré de nouvelle génération construit sur des environnements d'exécution de confiance, et l'équipe fait une affirmation qui aurait été rejetée comme inaccessible il y a quelques années : des garanties de confidentialité différentielles centrales vérifiables en externe pour l'apprentissage fédéré, pour la première fois. Le système, qui est appliqué à Gboard, remplace un accord de longue date « faites-nous confiance » par une attestation cryptographique et des journaux publics que des auditeurs externes peuvent réellement inspecter. Pour une couverture continue de l'apprentissage automatique préservant la confidentialité, suivez nos derniers développements en matière d'IA.

Le manque de confiance dans l'apprentissage fédéré

L'apprentissage fédéré, introduit par Google en 2017, était censé résoudre un problème spécifique : comment former des modèles utiles sur les données des utilisateurs sans collecter ces données de manière centralisée. Au lieu de télécharger le comportement de saisie brut sur un serveur, les appareils calculent les mises à jour du modèle localement et contribuent uniquement à ces mises à jour. Cette approche alimente silencieusement une quantité remarquable de ce que les utilisateurs touchent chaque jour : prédiction du mot suivant et Smart Compose dans Gboard, suggestions de réponse dans Google Messages et sélection de texte intelligente dans Android.

Mais l’architecture originale présentait en son centre un manque de confiance. Les appareils téléchargeaient leurs données pour une agrégation immédiate, et les tiers n'avaient aucun moyen de vérifier que les données n'étaient jamais enregistrées, conservées ou inspectées en cours de route. Les utilisateurs ont dû croire Google sur parole pour ce qui s'est passé côté serveur. Plus tard, Secure Aggregation a ajouté une protection cryptographique afin que les contributions individuelles ne puissent pas être lues de manière isolée – mais cette technique n’était pas compatible avec les algorithmes de pointe de confidentialité différentielle centrale tels que la factorisation matricielle DP-FTRL, et elle laissait toujours une hypothèse intacte : il fallait faire confiance à Google pour ajouter correctement le bruit de confidentialité différentielle. Un paramètre de bruit mal configuré serait invisible pour tout le monde, sauf pour l’entreprise qui commet l’erreur.

Comment fonctionne le nouveau système

La nouvelle conception s’attaque directement à l’hypothèse de confiance. Il déplace le calcul du gradient client vers le serveur – dans un environnement d'exécution approuvé – et rend ensuite la logique du serveur attestable, de sorte qu'il n'est plus du tout nécessaire de faire confiance à l'opérateur. Un TEE est une enclave de processeur isolée du matériel dont le code d'exécution peut être vérifié cryptographiquement par des tiers ; si l'enclave fait autre chose que ce qu'elle prétend, l'attestation est rompue.

Selon l'annonce de Google, le système coordonne quatre composants principaux. Tout d'abord, le téléchargement des données : les appareils chiffrent les exemples de formation localement et pré-autorisent une politique d'accès qui répertorie exactement les calculs TEE qui peuvent traiter les données - et ces politiques doivent apparaître dans un journal de transparence public. Deuxièmement, un système de gestion de clés construit à partir de TEE exécutant le protocole de consensus RAFT ne publie les clés de déchiffrement qu'aux charges de travail qui correspondent à la politique publiée. Troisièmement, l'exécution de la charge de travail : un TEE racine exécute une boucle de formation Python et délègue des sous-tâches aux TEE de travail, avec une orchestration gérée par un système appelé Federated Language, dérivé du framework TensorFlow Federated de Google. Seuls les poids de modèle différentiellement privés sont libérés de l'enclave. Quatrièmement, récupération tolérante aux pannes : chaque cycle de formation enregistre un état de récupération crypté par KMS afin que les pannes de racine ou de travailleur ne détruisent pas la formation en cours.

Pourquoi les garanties peuvent effectivement être vérifiées

L’allégation de vérifiabilité repose sur une chaîne de preuves publiques plutôt que sur une attestation d’entreprise. Les politiques d'accès sont publiées dans Rekor, le journal public de transparence de Sigstore, afin que les auditeurs externes puissent suivre chaque charge de travail du serveur que les données d'un appareil pourraient éventuellement alimenter. Le KMS et les binaires de traitement des données sont reproductibles à partir de code open source, ce qui signifie que n'importe qui peut compiler la source publiée et confirmer qu'elle correspond aux binaires exécutés en production.

Les politiques elles-mêmes décrivent directement le programme de formation Python, qui comble la faille la plus courante dans les architectures de confidentialité : un écart entre ce que dit une politique de confidentialité et ce que fait réellement le code. Pour protéger les architectures de modèles propriétaires, les TEE prennent en charge le chargement latéral de la logique sérialisée au moment de l'exécution, mais avec une contrainte stricte selon laquelle toute logique relative à la confidentialité doit rester codée en dur dans le programme attesté. Les opérateurs de charges de travail, y compris le personnel d'infrastructure de Google, ne voient que les métriques et les pondérations différentielles des modèles privés. Les données cryptées ne peuvent être déchiffrées que pendant une durée limitée après le téléchargement, ce qui limite la fenêtre dans laquelle quoi que ce soit puisse être inspecté.

Des promesses aux preuves

L’importance de la conception réside moins dans un composant individuel que dans le changement de charge qu’il produit. Les garanties de confidentialité dans le machine learning ont toujours été formulées comme des promesses étayées par des documents politiques, des audits internes et la réputation de l'opérateur. Ce système convertit ces promesses en artefacts (rapports d'attestation, entrées de journal de transparence, versions reproductibles) qu'un sceptique peut vérifier sans accéder aux composants internes de Google.

Cela marque également une convergence notable de deux communautés de recherche qui ont pour la plupart travaillé en parallèle. Les environnements d'exécution fiables et la confidentialité différentielle résolvent différents problèmes : les TEE limitent qui peut calculer sur les données, tandis que DP restreint ce que tout calcul peut divulguer. Les combiner dans un seul programme attestable, avec la génération de bruit DP elle-même à l'intérieur de l'enclave vérifiée, répond à la faiblesse résiduelle de chaque approche isolément.

Pour l'instant, le système fonctionne dans la propre pile de Google, alimentant des charges de travail de formation du type de celles effectuées par Gboard. La question de savoir si la confidentialité vérifiable deviendra une attente concurrentielle dans l’ensemble du secteur – comme l’a fait HTTPS après la normalisation de la journalisation de transparence pour les certificats – dépendra de la question de savoir si les utilisateurs et les régulateurs commenceront à poser à d’autres fournisseurs d’IA la question à laquelle ce système est conçu pour répondre : le prouver.

---

Gardez une longueur d'avance sur l'IA

Recevez les dernières actualités, analyses et avancées en matière d'IA, le tout en un seul endroit.

Lire plus d'actualités sur l'IA →