Private Cloud Compute d’Apple : une nouvelle frontière pour la confidentialité de l’IA dans le cloud

 (security.apple.com)
1 points par GN⁺ 2024-06-11 | 1 commentaires | Partager sur WhatsApp
  • Apple a introduit Private Cloud Compute (PCC) pour confier aux grands foundation models les requêtes qu’Apple Intelligence ne peut pas traiter directement sur l’appareil, avec une conception qui vise à minimiser l’accès aux données personnelles même dans le cloud
  • PCC combine des serveurs Apple silicon personnalisés, Secure Enclave, Secure Boot, Code Signing et le sandboxing afin d’apporter au datacenter un modèle de sécurité au niveau de l’appareil
  • Les requêtes des utilisateurs sont chiffrées directement avec la clé publique de nœuds PCC vérifiés, et ni les load balancers ni la passerelle de confidentialité ne disposent des clés permettant de les déchiffrer
  • Pour des raisons opérationnelles, PCC exclut les shells distants, le débogage interactif et la journalisation générique couramment utilisés, et ne laisse sortir des nœuds que des journaux audités et des métriques limitées
  • Apple prévoit de créer une IA cloud vérifiable de l’extérieur grâce aux images logicielles de production, aux journaux de transparence, à un environnement de recherche et à l’Apple Security Bounty

Les problèmes de confidentialité quand Apple Intelligence passe au cloud

  • Apple Intelligence est un système qui apporte des fonctions d’intelligence personnelle fondées sur des modèles génératifs à l’iPhone, l’iPad et au Mac
  • Les fonctions avancées qui doivent raisonner sur des données plus complexes nécessitent des foundation models plus grands ; c’est pour cela qu’Apple a créé Private Cloud Compute (PCC)
  • PCC est un système d’intelligence cloud conçu pour le traitement d’IA personnel, avec pour objectif de faire en sorte que les données personnelles des utilisateurs ne soient exposées à personne, pas même à Apple
  • Le traitement on-device est favorable à la sécurité et à la confidentialité des données utilisateur
    • Les données qui ne se trouvent que sur l’appareil de l’utilisateur ne sont pas exposées à un point d’attaque centralisé
    • Pour les données cloud les plus sensibles, le chiffrement de bout en bout constitue une défense très solide
    • Pour les services cloud où le chiffrement de bout en bout n’est pas adapté, on peut utiliser un traitement éphémère ou des identifiants aléatoires non corrélés qui brouillent l’identité de l’utilisateur

Les limites des modèles de sécurité de l’IA cloud existants

  • L’IA cloud peut exploiter du matériel de datacenter puissant et de grands modèles de machine learning, mais elle a besoin d’un accès non chiffré aux requêtes et aux données personnelles associées
  • Pour cette raison, elle ne peut pas être gérée uniquement avec un chiffrement de bout en bout complet, et les services d’IA cloud existants se sont appuyés jusqu’ici sur les méthodes de sécurité cloud traditionnelles
  • L’approche traditionnelle présente trois faiblesses
    • Il est difficile de vérifier les garanties de sécurité et de confidentialité
      • Même si un service affirme ne pas enregistrer certaines données utilisateur, il est difficile pour un chercheur de le confirmer
      • Une nouvelle version peut enregistrer par erreur des données sensibles dans les logs, ou un load balancer qui termine TLS peut consigner massivement des requêtes utilisateur pendant la résolution d’un incident
    • Il est difficile d’offrir de la transparence à l’exécution
      • Les services d’IA cloud ne publient généralement pas la pile logicielle réellement exécutée
      • Même en n’utilisant que des logiciels open source, il n’existe pas de méthode largement déployée permettant à l’appareil ou au navigateur de l’utilisateur de vérifier que le logiciel du service n’a pas été modifié
    • Il est difficile d’imposer de fortes restrictions sur les accès privilégiés
      • Les SRE et les administrateurs peuvent utiliser des accès très privilégiés comme SSH lors de pannes ou d’incidents graves
      • Un administrateur peut copier des données utilisateur sensibles en sauvegardant les données d’un serveur en production, ou un criminel peut voler les identifiants d’un administrateur et récupérer des données utilisateur

Les cinq exigences de conception de PCC

  • Calcul sans état sur les données personnelles des utilisateurs

    • PCC ne doit utiliser les données personnelles reçues que pour traiter la requête de l’utilisateur
    • Les données ne doivent être fournies à personne d’autre que l’utilisateur, y compris aux employés d’Apple
    • Une fois la réponse renvoyée, elles ne doivent être conservées sous aucune forme, y compris pour la journalisation ou le débogage

  • Garanties techniquement applicables

    • Les garanties de sécurité et de confidentialité sont les plus solides quand on peut limiter et analyser les composants critiques de l’ensemble du système
    • Les garanties fondamentales de PCC ne doivent pas dépendre de composants externes comme un load balancer qui termine TLS
    • Les besoins opérationnels, comme la collecte de métriques serveur et de journaux d’erreurs, doivent aussi être pris en charge d’une manière qui n’affaiblit pas la protection de la confidentialité

  • Aucun accès privilégié à l’exécution

    • PCC ne doit comporter aucune interface privilégiée permettant aux SRE d’Apple de contourner les garanties de confidentialité, même lors de la réponse à un incident
    • Il ne doit pas non plus prendre en charge le chargement de logiciels supplémentaires à l’exécution pour élargir la portée de l’accès privilégié

  • Non-ciblage

    • Pour viser les données personnelles d’un utilisateur PCC en particulier, un attaquant devrait devoir tenter une compromission à grande échelle de l’ensemble du système PCC
    • Même un attaquant capable de mener une attaque physique contre des nœuds PCC dans la chaîne logistique ou d’obtenir un accès au datacenter ne doit pas pouvoir diriger les requêtes d’un utilisateur spécifique vers un nœud compromis

  • Transparence vérifiable

    • Les chercheurs en sécurité doivent pouvoir vérifier avec un haut niveau de confiance que les garanties de sécurité et de confidentialité de PCC correspondent aux engagements publics d’Apple
    • Il doit aussi être possible de vérifier que le logiciel inspecté par les chercheurs est bien le même que celui exécuté dans l’environnement de production PCC

Les nœuds PCC et les fondations de sécurité

  • La racine de confiance de PCC repose sur un matériel serveur sur mesure : les nœuds de calcul PCC
  • Les nœuds PCC transposent au datacenter les technologies de sécurité matérielle utilisées sur l’iPhone
  • Le système d’exploitation est un sous-ensemble durci d’iOS et de macOS, adapté aux charges d’inférence LLM
    • Il est conçu pour maintenir une surface d’attaque réduite
    • Il exploite des technologies de sécurité iOS comme le Code Signing et le sandboxing
  • Apple exclut des nœuds PCC des composants généralement jugés importants pour l’administration d’un datacenter
    • shell distant
    • observation interne du système et outils d’observabilité génériques
  • À la place, Apple utilise des composants conçus pour un usage précis afin de fournir aux équipes SRE des métriques opérationnelles réduites et limitées, de manière déterministe
  • Apple a créé, avec Swift on Server, une nouvelle pile de machine learning destinée à héberger des foundation models cloud

Traitement des requêtes utilisateur et prévention de la rétention des données

  • Comme PCC doit utiliser les données des requêtes utilisateur pour l’inférence du modèle, il ne peut pas être conçu uniquement autour d’un chiffrement de bout en bout complet
  • À la place, PCC impose techniquement la confidentialité des données utilisateur pendant le traitement par les nœuds de calcul PCC, et rend impossible leur conservation une fois le cycle de travail terminé
  • PCC offre trois garanties concernant le traitement des données utilisateur
    • L’appareil utilisateur envoie les données à PCC dans l’unique but de traiter une requête d’inférence
    • Les données utilisateur ne restent sur le nœud PCC qui traite la requête que jusqu’au renvoi de la réponse
    • Les données utilisateur ne sont pas accessibles aux employés d’Apple, même à ceux qui disposent d’autorisations d’administration sur le service de production ou le matériel
  • Lorsqu’Apple Intelligence utilise PCC, l’appareil construit une requête avec le prompt, le modèle souhaité et les paramètres d’inférence
  • Le client PCC de l’appareil chiffre d’abord directement la requête avec la clé publique d’un nœud PCC vérifié et authentifié cryptographiquement
    • Cela fournit un chiffrement de bout en bout entre l’appareil utilisateur et le nœud PCC vérifié
    • Les services auxiliaires du datacenter comme les load balancers et la passerelle de confidentialité sont hors du périmètre de confiance et n’ont pas les clés pour déchiffrer la requête
  • Les nœuds PCC ne peuvent exécuter que du code approuvé et mesuré cryptographiquement via Secure Boot et Code Signing
    • Tout code exécutable doit être signé par Apple et inclus dans le trust cache approuvé pour un nœud PCC donné
    • Le trust cache est chargé par Secure Enclave et ne peut être ni modifié ni étendu à l’exécution
    • Il est impossible de créer des mappings JIT, ce qui empêche la compilation ou l’injection de code à l’exécution
  • Le code et les ressources des modèles utilisent les mêmes protections d’intégrité que celles du Signed System Volume
  • Secure Enclave impose que les clés de déchiffrement des requêtes ne puissent pas être copiées ni extraites
  • Pour empêcher la rétention de données, Secure Enclave randomise la clé de chiffrement du volume de données à chaque redémarrage et ne la stocke pas de façon persistante
    • À chaque redémarrage du Secure Enclave Processor d’un nœud PCC, le volume de données est supprimé cryptographiquement
    • Le processus d’inférence supprime les données associées à la fin de la requête
    • Les espaces d’adressage ayant traité des données utilisateur sont recyclés périodiquement afin de réduire l’impact de données qui pourraient subsister en mémoire de manière inattendue
  • Les Pointer Authentication Codes et le sandboxing compliquent les exploits visant à contourner ces garanties et limitent les déplacements latéraux à l’intérieur des nœuds PCC
  • La couche de contrôle et de dispatch de l’inférence est écrite en Swift pour bénéficier de la sécurité mémoire, et le traitement initial des requêtes est isolé dans un espace d’adressage distinct

Suppression des accès privilégiés à l’exécution

  • Les nœuds PCC n’incluent ni shell distant ni mécanisme de débogage interactif
  • Code Signing empêche le chargement de code supplémentaire, mais Apple considère aussi ce type d’accès ouvert comme une large surface d’attaque susceptible de contourner la sécurité et la confidentialité du système
  • Les nœuds PCC ne peuvent pas activer le Developer Mode et n’incluent pas les outils nécessaires aux workflows de débogage
  • Les outils d’observabilité et d’administration intègrent des garde-fous de confidentialité pour empêcher l’exposition de données utilisateur
    • Il n’existe pas de mécanisme de journalisation générique
    • Seuls des journaux et métriques prédéfinis, structurés et audités peuvent sortir du nœud
    • Plusieurs couches de revue indépendantes sont utilisées pour éviter toute exposition accidentelle de données utilisateur via ces mécanismes
  • Cette conception fournit des garanties applicables selon lesquelles seul le code désigné peut accéder aux données utilisateur, et qu’aucune donnée utilisateur ne fuit hors d’un nœud PCC lors de l’administration du système

Non-ciblage et réponse aux attaques matérielles

  • Le modèle de menace de PCC inclut des attaquants sophistiqués capables d’obtenir un accès physique aux nœuds de calcul et de contourner certaines propriétés de sécurité matérielle du système pour extraire des données en cours de traitement
  • Apple se défend de deux façons
    • En appliquant à l’infrastructure PCC une chaîne logistique renforcée afin de rendre les attaques matérielles à grande échelle très coûteuses et détectables
    • En empêchant qu’une attaque de petite taille puisse être utilisée pour viser les données d’un utilisateur en particulier
  • La sécurité matérielle de PCC commence dès la fabrication
    • Les composants des nœuds PCC sont inventoriés et soumis à une imagerie haute résolution avant le scellement des serveurs et l’activation des interrupteurs anti-effraction
    • Une revalidation approfondie est réalisée à l’arrivée au datacenter, avant le provisionnement PCC
    • Plusieurs équipes Apple recoupent de façon indépendante des données issues de sources distinctes, et des observateurs tiers sans lien avec Apple surveillent aussi la procédure
    • Chaque nœud PCC reçoit un certificat de clé ancré dans le Secure Enclave UID
    • Les appareils utilisateur n’envoient pas de données à un nœud PCC dont ils ne peuvent pas valider le certificat
  • Pour bloquer des attaques plus petites et plus sophistiquées, PCC adopte une approche de diffusion de cible (target diffusion)
  • Les métadonnées de requête ne contiennent aucune information personnellement identifiable sur l’appareil ou l’utilisateur d’origine
    • Elles n’incluent qu’un contexte de requête limité, nécessaire à l’acheminement vers le modèle approprié
    • Seules ces métadonnées sont fournies aux load balancers et aux composants du datacenter situés hors du périmètre de confiance PCC
  • Les métadonnées incluent des identifiants à usage unique fondés sur RSA Blind Signatures, permettant d’autoriser une requête valide sans la lier à un utilisateur précis
  • Les requêtes PCC passent par un relais OHTTP opéré par un tiers
    • Cela masque l’adresse IP source de l’appareil avant que la requête n’atteigne l’infrastructure PCC
    • Cela empêche un attaquant d’identifier une requête par son adresse IP ou de la relier à une personne
    • Pour orienter le trafic sur la base de l’adresse IP source, un attaquant devrait compromettre à la fois le relais tiers et les load balancers d’Apple
  • Les appareils utilisateur ne chiffrent leurs requêtes que pour un sous-ensemble des nœuds PCC, et non pour l’ensemble du service PCC
    • Le load balancer renvoie un sous-ensemble de nœuds qui ont le plus de chances d’être prêts à traiter la requête
    • Le load balancer ne dispose d’aucune information d’identification sur l’utilisateur ou l’appareil, et ne peut donc pas biaiser cet ensemble pour un utilisateur donné
    • Même si un seul nœud est compromis, il ne peut déchiffrer qu’une petite fraction des requêtes entrantes
    • L’ensemble des nœuds PCC sélectionnés par le load balancer peut être audité statistiquement

Transparence vérifiable et accès des chercheurs

  • Apple estime que, pour établir la confiance publique autour de PCC, les chercheurs en sécurité doivent pouvoir vérifier les garanties de sécurité et de confidentialité de bout en bout
  • Au lancement de PCC, Apple prévoit de publier les images logicielles de tous les builds de production à des fins de recherche en sécurité
  • Les appareils utilisateur sont conçus pour n’envoyer des données qu’à des nœuds PCC capables de prouver cryptographiquement qu’ils exécutent un logiciel publié publiquement
  • Le plan d’Apple pour une transparence vérifiable comprend les éléments suivants
    • Publier les mesures de tout le code exécuté dans PCC dans un journal de transparence append-only, protégé cryptographiquement contre la falsification
    • Rendre publics le journal et les images binaires logicielles associées afin que les spécialistes de la confidentialité et de la sécurité puissent les inspecter et les vérifier
    • Publier et maintenir un ensemble officiel d’outils pour analyser les logiciels des nœuds PCC
    • Récompenser les découvertes importantes via l’Apple Security Bounty
  • Toutes les images logicielles PCC de production seront rendues publiques pour permettre une inspection binaire indépendante
    • Elles incluent l’OS, les applications et les exécutables associés
    • Les chercheurs pourront les vérifier en les comparant aux mesures du journal de transparence
    • Les logiciels seront publiés dans les 90 jours suivant leur inclusion dans le journal, ou plus tôt si une mise à jour logicielle liée est fournie
    • Une fois qu’une release est signée et inscrite dans le journal, elle ne peut plus être retirée sans être détectée
  • Les appareils utilisateur n’enveloppent la clé de charge utile d’une requête qu’avec la clé publique d’un nœud PCC lorsque les mesures attestées de ce nœud correspondent à une release logicielle du journal de transparence public
  • Code Signing empêche le chargement de logiciels non approuvés et garantit que tout le code d’un nœud PCC est inclus dans l’attestation

Environnement de recherche PCC et récompenses

  • Apple prévoit trois mesures supplémentaires pour aider les chercheurs à vérifier rapidement les engagements de confidentialité de PCC et à identifier d’éventuels problèmes
    • Publication de PCC Virtual Research Environment
      • Un ensemble d’outils et d’images permettant de simuler un nœud PCC sur un Mac équipé d’Apple silicon
      • Il sera possible d’y démarrer une version du logiciel PCC légèrement modifiée pour fonctionner en virtualisation
    • En plus des images binaires de tous les builds PCC de production, publication périodique d’une partie du code source PCC critique du point de vue de la sécurité
    • Pour la première fois sur une plateforme Apple, inclusion en clair dans les images PCC du firmware sepOS et du bootloader iBoot
  • L’Apple Security Bounty récompensera les résultats de recherche portant sur l’ensemble de la pile logicielle PCC
  • Les problèmes qui affaiblissent les engagements de confidentialité de PCC feront l’objet de récompenses particulièrement élevées

Prochaines publications

  • PCC est conçu pour satisfaire les exigences de calcul sans état, de garanties applicables, d’absence d’accès privilégié, de non-ciblage et de transparence vérifiable
  • Une explication technique plus approfondie sera publiée après la mise à disposition de PCC en bêta
  • Apple prévoit de partager ensuite davantage de détails techniques sur la mise en œuvre et le fonctionnement de chacune de ces exigences fondamentales
  • Apple prévoit aussi de fournir prochainement un premier accès au logiciel PCC et au PCC Virtual Research Environment pour les chercheurs en sécurité

À lire aussi

1 commentaires

 
GN⁺ 2024-06-11
Avis sur Hacker News

  • Tout ce qui est connecté au cloud ou à Internet finit par exiger qu’on fasse confiance à quelqu’un, sauf si c’est open source et que les serveurs ne sont pas décentralisés
    Apple peut faire de son mieux pour empêcher quiconque en dehors d’elle d’accéder aux données, mais Apple contrôle tous les terminaux, les mises à jour d’iPhone et les serveurs
    Cela rappelle le texte « le chiffrement sur le web est toujours une arnaque » : https://www.devever.net/~hl/webcrypto
    Même les données stockées localement restent potentiellement accessibles par Apple si elle le veut, et cela pourrait arriver sur injonction d’un gouvernement. Donc, quand on dit que c’est « privé », cela signifie plutôt que seule Apple peut savoir, et non qu’un plus grand nombre d’acteurs ne le peut pas
    En ce sens, les alternatives sont meilleures si elles laissent fuiter les données vers davantage d’endroits, mais on est loin d’un chiffrement incassable comme le marketing le suggère

    • Je ne pense pas que cette évaluation soit totalement juste. Elle met Apple dans le même sac que Google ou OpenAI
      Google suit clairement les utilisateurs pour la publicité, les recommandations, l’IA, etc. ; l’entreprise ne le cache pas, et c’est au cœur de son modèle économique
      Apple, en revanche, semble avoir fait de gros efforts pour empêcher ses employés d’accéder aux données utilisateur dans ce système d’IA, en limitant fortement la journalisation et l’observabilité, et en concevant jusqu’à ses propres puces et son propre système d’exploitation
      Le fait que le client refuse de communiquer avec un système non audité est aussi une grande différence
      On ne peut pas croire Apple sur parole, mais la vérification par des tiers me semble être l’élément clé pour faire confiance à la confidentialité de ce système et la valider
      Dire « Apple sait ce que tu fais » suggère qu’une personne chez Apple pourrait accéder aux données envoyées de l’appareil vers le cloud privé, ce qui ne semble pas être le cas
      Le fait que la confidentialité soit un pilier important du modèle d’Apple est aussi un facteur de confiance. Apple a réussi financièrement en fabriquant des produits qui gagnent de l’argent autrement, et se mettre à vendre des données n’est ni nécessaire ni une bonne idée commerciale
      Il est légitime d’être sceptique avant une vérification par des tiers, mais dire que l’approche d’Apple n’est pas meilleure que celle d’OpenAI ou de Google sur les données et la confidentialité est injuste
    • Quand on dit « open source et serveurs décentralisés », ce qu’il faut dire plus précisément, c’est open source et auto-hébergeable
      Si les gens ne peuvent pas faire tourner leur propre serveur, le seul fait que le code soit publié ne suffit pas, car on ne peut pas savoir si le code du dépôt public est bien celui qui tourne réellement sur les serveurs cloud
    • À moins de vérifier soi-même la conception du matériel, le processus de fabrication et l’ensemble des logiciels, même une exécution en local revient au final à faire confiance à énormément de monde
    • Ce n’est pas exact. Si l’on fait confiance aux mathématiques, on peut prouver que le logiciel est bien ce qu’il prétend être
      Bien sûr, cela demande un travail de vérification, mais cela reste une avancée majeure
    • Dès qu’on utilise une technologie, il faut faire confiance à quelqu’un. Apple s’est concentrée sur l’informatique personnelle depuis sa création, son message est resté cohérent et ses résultats sont plutôt bons
      À mes yeux, les alternatives sont plus dispersées et moins focalisées, donc je ferais confiance à Apple

  • Bon commentaire du cryptographe Matt Green ici : https://x.com/matthew_d_green/status/1800291897245835616?t=C...
    Je ne sais pas si Matt est conscient qu’on ne peut pas lire les tweets sans compte X. Ce serait bien qu’il utilise BlueSky ou Mastodon
    Version compilée du fil : https://threadreaderapp.com/thread/1800291897245835616.html?...

    • S’il voulait vraiment que personne ne lise ses tweets, il aurait utilisé BluSky ou Mastodon
    • Deux tweets ressortent particulièrement
      « Le billet de blog contient probablement encore six détails techniques de plus. C’est une conception très soigneuse. Si vous donniez beaucoup d’argent à une excellente équipe pour construire le meilleur cloud “privé” du monde, cela ressemblerait probablement à ça »
      « Bien sûr, il faut se rappeler que le super-espion n’est pas forcément le principal adversaire. Pour beaucoup de gens, le principal adversaire est l’entreprise qui a vendu l’appareil et le logiciel. Ce système PCC représente un véritable engagement d’Apple à ne pas “regarder” les données des utilisateurs. C’est important »
      Je préfère que les données restent sur l’appareil, mais au moins c’est un engagement fort dans la bonne direction — ou peut-être dans la mauvaise, mais malgré tout bien mieux exécuté que chez les concurrents
    • Le passage « Apple ne semble pas prévoir d’indiquer explicitement quand les données sortent de l’appareil via Private Compute. L’utilisateur ne donne pas son consentement et n’en est pas forcément informé. Cela se produit simplement comme par magie » me gêne
      J’imagine qu’il y aura une option pour désactiver l’ensemble des fonctionnalités d’IA, à la fois on-device et hors appareil
      Pourquoi un fabricant d’appareils n’offrirait-il pas une option IA uniquement on-device ? Les fonctionnalités d’IA d’iOS 17 fonctionnent déjà sans iCloud
      Ce serait bien qu’Apple utilise un domaine dédié comme *.pcc.apple.com, afin de permettre un filtrage au niveau réseau
    • On peut aussi le lire ici sans compte X : https://nitter.poast.org/matthew_d_green/status/180029189724...
    • Matt utilise en réalité activement un compte Mastodon, mais il semble qu’il n’y ait pas encore posté cette discussion : https://ioc.exchange/@matthew_d_green

  • Même en lisant tout, au final on en revient à « faites-nous confiance ». Apple peut à tout moment signer et approuver une mise à jour contenant une porte dérobée, un gouvernement peut l’y contraindre avec une simple signature, et tout cela peut se faire en silence
    Je comprends qu’il y a des avantages dans ce que fait Apple. Mais si l’on vend de la confiance, il faut être honnête à 100 %, et si l’on n’indique pas de manière transparente qu’une telle possibilité d’accès aux données existe toujours, alors tout le message est biaisé

    • Apple a déjà les privilèges root et le logiciel est en source fermée. À l’heure actuelle, il n’existe absolument aucun moyen d’empêcher l’envoi de toutes les données
      Si l’on ne peut pas faire confiance à ceux qui fabriquent le système d’exploitation, alors le problème est bien plus profond que le traitement de l’IA hors appareil
    • Cette logique n’est pas différente de ce qu’Apple peut faire sur l’iPhone. Le fait que le traitement se fasse sur serveur ne change rien
      Apple peut, d’un simple clic, faire en sorte que l’iPhone envoie au serveur toutes les données qu’il veut. En suivant cette logique, on ne devrait faire confiance à rien, y compris à l’IA exécutée en local. C’est probablement vrai, mais peu pratique
      La fin du thread de Matthew Green le résume bien : « Il arrive que la perfection empêche quelque chose de très bien. En pratique, l’alternative à l’on-device consiste à envoyer des données sensibles à OpenAI ou à quelque chose d’encore plus louche. Pour beaucoup de gens, le principal ennemi est l’entreprise qui leur a vendu l’appareil et le logiciel. PCC est un véritable engagement d’Apple à “ne pas regarder” les données, et c’est important. Nous entrons maintenant dans un monde où une partie du téléphone vit dans un datacenter situé à 2 000 miles, donc les gens de la sécurité vont devoir s’habituer à cette réalité et rendre chaque élément aussi sûr que possible »

  • C’est extrêmement intéressant. Le Private Cloud Compute d’Apple semble être, sur le plan conceptuel, la même chose que System Transparency, un projet open source que des collègues et moi avons lancé il y a 6 ans
    J’attends avec impatience plus de détails techniques. Si quelqu’un d’Apple voit ceci, il peut me contacter à stromberg@mullvad.net. Je peux discuter de notre conception et de celle d’Apple, ou donner un retour
    Liens associés : https://mullvad.net/en/blog/system-transparency-future
    http://system-transparency.org
    http://sigsum.org

    • https://en.m.wikipedia.org/wiki/Confidential_computing
      Ce que fait Apple, c’est du confidential computing. Cherchez des exemples de mise en œuvre et vous comprendrez davantage de détails techniques
    • En regardant l’annonce, j’ai immédiatement pensé la même chose, et System Transparency m’est revenu à l’esprit. Je suis curieux de voir quelles évaluations en sortiront une fois les détails publiés et pleinement compris
    • La plupart de ces systèmes, comme Intel SGX, AMD SEV ou les nouvelles technologies de NVIDIA, utilisent les mêmes briques de base, mais la différence d’Apple réside selon moi dans la qualité de l’implémentation globale et du système
      Apple n’est pas membre du Confidential Computing Consortium, mais ARM en fait partie
      Je suis aussi assez optimiste sur le trusted computing, et cela semble prendre de l’ampleur
      Ce serait mieux si c’était plus ouvert, afin de pouvoir contrôler toute la stack et installer ses propres certificats racine ou clés sur la plateforme matérielle, mais cela peut malgré tout offrir beaucoup d’avantages
      Si Apple pousse cela dans le grand public, je m’attends à une adoption plus large

  • Le passage disant que « pour la première fois sur une plateforme Apple, les images PCC incluent le firmware sepOS et le chargeur d’amorçage iBoot en clair, permettant aux chercheurs d’étudier ces composants critiques plus facilement que jamais » est très positif
    En revanche, le passage disant que « le logiciel est publié dans un délai de 90 jours après son inclusion dans le journal, ou après la mise à disposition d’une mise à jour logicielle associée, selon la première éventualité » laisse en théorie jusqu’à 90 jours de vide entre la présence d’un logiciel vulnérable et la possibilité de le découvrir
    J’espère que la mise à disposition réelle des images sera, dans les faits, bien plus proche de l’immédiat que de cette limite maximale

    • Si des auditeurs pénibles posent trop de questions sur une backdoor NSA ou CCP, il suffira d’un calendrier de mise à jour puis retour en arrière tous les 89 jours

  • Aux États-Unis, une confidentialité totale est impossible. Non seulement le gouvernement peut contraindre Apple à ouvrir ses entrailles, mais il peut aussi lui interdire d’en parler
    Apple n’a pratiquement aucun moyen de contourner cette « contrainte ». À l’occasion, vous pouvez remercier les « représentants » qui ont voté pour la prolongation du PATRIOT Act

    • Les serveurs Private Cloud Compute n’ont pas de stockage persistant, donc même en les ouvrant, il n’y aurait rien à voir
      Pour collecter les données des requêtes entrantes, il faudrait quelque chose comme une interception en temps réel demandée par le gouvernement, et ce serait alors une autre situation
      Bien sûr, je ne suis qu’un inconnu sur Internet, et je n’ai fait qu’imaginer un contre-argument à cette inquiétude, donc je ne sais même pas si c’est la bonne direction
    • L’expression « open up the kimono » me paraît inconfortable et glaçante en tant qu’Asiatique. Je doute d’être le seul à le ressentir ainsi
    • La confidentialité garantie et la confidentialité prouvable sont deux choses différentes
      Le gouvernement peut demander les données. Mais le système d’Apple est censé rendre cette intrusion visible au public, même si Apple elle-même ne peut pas en parler
    • Ce qu’Apple peut faire — et semble effectivement faire dans l’ensemble de ses produits —, c’est ne pas avoir les données demandées au départ, ou ne pas les avoir en clair
      Même avec une lettre de sécurité nationale, on ne peut pas demander des données qui n’existent plus
    • En lisant le texte d’Apple, cela semble possible. Je me demande s’il y avait un passage précis qui vous a fait tiquer

  • Grande question : à qui cela s’adresse-t-il ?
    Il ne faut pas se méprendre : c’est un excellent effort et un travail de nerd de niveau A+. C’est exactement le genre de chose qui me parle
    Mais je vais probablement simplement chercher comment désactiver la fonction qui appelle la maison, parce que je ne veux pas de ce comportement au départ
    Est-ce que c’est censé me faire dire à d’autres que « Apple est l’option la plus sûre » ? Je n’ai pas envie de recommander Linux. Je n’ai pas envie de faire le support technique
    J’ai maintenant l’impression d’être devenu ce vieux qui crie « bas les pattes sur mes données »

    • Apple a besoin de se différencier et a choisi la vie privée pour le faire, et je suis pour
      Les gros titres sur les efforts de Microsoft en IA ont été, dans l’ensemble, proches du cauchemar, avec beaucoup de mauvaise presse
      Si la couverture autour de l’IA d’Apple se remplit d’articles expliquant qu’ils ont pris la sécurité et la vie privée au sérieux, peut-être même à l’excès, il y a de fortes chances que les gens se sentent un peu plus en confiance pour l’utiliser
      Je n’utilise pas beaucoup les produits OpenAI, mais si je devais le faire, je préférerais passer par la couche d’anonymisation d’Apple plutôt que d’aller directement chez OpenAI
    • Que se passe-t-il si on ne peut pas le désactiver, et que c’est pour cette raison qu’on nous présente un niveau de sécurité aussi extrême ?
    • C’est pour les actionnaires. Grâce à la frénésie d’investissement dans l’IA, Microsoft et Nvidia ont désormais une capitalisation boursière supérieure à celle d’Apple
      Apple doit aussi montrer qu’elle peut être une entreprise centrée sur l’IA. Mais Apple a une culture d’entreprise qui cherche à préserver la vie privée
    • C’est pour des gens comme moi
      Je ne me soucie pas vraiment du fait que le gouvernement accède aux données. En revanche, je ne veux pas que des acteurs malveillants comme des escrocs, des gouvernements étrangers, des sociétés d’ad tech ou des assureurs accèdent à mes données personnelles
      En même temps, je veux aussi profiter des capacités des LLM. Est-ce vraiment une demande si irréaliste ?
      En pratique, je pars du principe que le gouvernement américain a déjà toutes mes données. Ça ne me plaît pas, mais la réalité est la réalité
    • C’est aussi pour les concurrents qui ont poussé le récit selon lequel Apple était « en retard »
      En réalité, l’infrastructure LLM et cloud à l’échelle de l’iPhone était prête, et ce n’est clairement pas le fruit de seulement deux ans de travail
      Apple met l’accent sur la vie privée, comme on l’attend d’elle
      Gemini pourrait lui aussi revendiquer la vie privée, mais si c’était vrai, les gens penseraient sans doute plutôt que ses performances en souffriraient

  • Je me demande comment cela se compare à AWS Nitro Enclaves, brièvement mentionné par Apple
    La principale différence semble être la possibilité de vérification jusqu’au niveau du firmware
    Nitro Enclaves ne fournit pas de mesures du firmware[0] ni de l’hyperviseur, et précise que le code de l’hyperviseur peut être mis à jour de manière transparente à tout moment[1]
    Apple prévoit de fournir sepOS, le système d’exploitation du Secure Enclave Processor, ainsi que les images du bootloader
    Le billet de blog n’est pas très clair, mais il donne l’impression que le code source de ces composants sera lui aussi fourni
    [0]: https://docs.aws.amazon.com/enclaves/latest/user/set-up-atte...
    [1]: https://docs.aws.amazon.com/pdfs/whitepapers/latest/security...

    • Nitro mesure bien le firmware. S’il y a un firmware différent de celui attendu, le serveur est en pratique isolé du réseau basé sur EC2 ou réinitialisé automatiquement
      Un appel est déclenché automatiquement, et il est très probable que l’équipe sécurité intervienne aussi
      Sur EC2, l’hyperviseur n’est pas un firmware, donc il n’y a aucune raison de mesurer un hypothétique firmware d’hyperviseur
      Le firmware BIOS/UEFI de la carte mère, s’il est altéré, est réécrit
      Le code de l’hyperviseur, comme tout code, est toujours signé et diffusé vers le serveur par la carte Nitro via un système de sécurité vérifiable qui exploite le measured boot ou le secure boot
      Je ne sais pas exactement ce que recouvre le terme orienté client « Nitro enclaves », mais les ingénieurs EC2 se mobilisent comme une armée au moindre risque de sécurité, même mineur
      Ces fondamentaux sont couverts, jusqu’à garantir que les core dumps ne contiennent pas de vraies données client, même sous forme chiffrée
    • AWS a dû faire cela à cause de son propre silicium. Intel, ARM et AMD fournissent une attestation au niveau du firmware et de l’hyperviseur

  • J’ai vraiment envie de voir cet OS, et je suis prudemment optimiste à l’idée que cela puisse devenir le premier cas où une grande entreprise technologique offre de vraies garanties de sécurité auditables
    Selon la manière dont cela évolue, Apple pourrait effectivement mériter une partie de la confiance que les utilisateurs lui accordent déjà, et ce serait plutôt remarquable
    Ce qui serait encore mieux, ce serait de fournir un audit de l’ensemble de la chaîne d’administration, et pour cela il faudra probablement aussi ouvrir certaines autres parties de la stack
    En particulier, si comme promis le système d’exploitation cloud devient open source, la valeur serait énorme
    La principale inquiétude à ce stade est que si la virtualisation est utilisée en production, la Secure Enclave de la partie du système d’exploitation, encore propriétaire, qui tourne sur l’appareil de l’utilisateur transmette les clés, et qu’il puisse y avoir dans l’hyperviseur, que nous n’avons pas audité, une porte dérobée permettant d’accéder aux conteneurs
    Des personnes ayant une expertise plus poussée en sécurité poseront de meilleures questions
    Si Apple réagit aux retours des chercheurs, une plus grande partie de cette chaîne d’outils pourrait devenir auditable
    Même si Apple ne parvient pas à vérifier la sûreté des cas d’usage qu’elle approuve, ce système d’exploitation cloud pourrait représenter une avancée majeure pour l’inférence sécurisée et le cloud sécurisé, et des gens pourraient l’héberger indépendamment ou en créer des dérivés
    Le pire scénario serait qu’Apple ne le fasse pas réellement, mais au moins cette promesse semble avoir de bonnes chances d’être tenue. Même dans le pire des cas, on aurait alors « une base de code open source très instructive pour le calcul sécurisé à grande échelle », ce qui serait positif quoi qu’il arrive

    • AWS Nitro Enclaves[0] est aussi un cas proche, mais ce qui compte chez Apple, c’est qu’elle a transformé le calcul privé en produit pour plus d’un milliard de clients macOS et iOS
      [0] https://docs.aws.amazon.com/enclaves/latest/user/nitro-encla...
    • Le secteur technologique aime copier Apple
      Asahi Linux propose un bon aperçu de la sécurité de la chaîne de démarrage on-device ici : https://github.com/AsahiLinux/docs/wiki/Apple-Platform-Secur...
      La phrase « nous publierons le PCC Virtual Research Environment, un ensemble d’outils et d’images qui permet de simuler un nœud PCC sur un Mac Apple silicon et de démarrer une version du logiciel PCC modifiée au minimum pour réussir la virtualisation » semble indiquer que les nœuds PCC sont en bare metal
      Sera-t-il aussi possible de simuler un nœud PCC sur l’iPad Pro équipé de la puce M4 Apple Silicon ?

  • Le passage « Enfin, nous avons utilisé Swift on Server pour créer une nouvelle stack de machine learning destinée à l’hébergement dans le cloud de modèles de fondation » est intéressant
    Le fait de voir apparaître Swift on Server ici retient l’attention : https://www.swift.org/documentation/server/