Apple Private Cloud Compute: Eine neue Grenze für Datenschutz bei Cloud-KI

 (security.apple.com)
1 Punkte von GN⁺ 2024-06-11 | 1 Kommentare | Auf WhatsApp teilen
  • Apple hat Private Cloud Compute (PCC) eingeführt, damit Apple Intelligence Anfragen, die sich nur schwer auf dem Gerät verarbeiten lassen, an größere Foundation Models auslagern kann, und stellt dabei ein Design in den Vordergrund, das den Zugriff auf persönliche Daten auch in der Cloud minimiert
  • PCC kombiniert maßgeschneiderte Apple-Silicon-Server, Secure Enclave, Secure Boot, Code Signing und Sandboxing, um ein Sicherheitsmodell auf Geräteniveau ins Rechenzentrum zu bringen
  • Nutzeranfragen werden direkt mit dem öffentlichen Schlüssel eines verifizierten PCC-Knotens verschlüsselt; Load Balancer oder Privacy Gateways besitzen keinen Schlüssel zum Entschlüsseln der Anfrage
  • Für den Betrieb übliche Remote-Shells, interaktives Debugging und allgemeines Logging werden ausgeschlossen; stattdessen ist das System so gestaltet, dass nur geprüfte Logs und begrenzte Metriken den Knoten verlassen
  • Apple plant, über Produktions-Software-Images, Transparency Logs, Forschungsumgebungen und das Apple Security Bounty eine extern überprüfbare Cloud-KI zu schaffen

Datenschutzprobleme, wenn Apple Intelligence in die Cloud wechselt

  • Apple Intelligence ist ein System, das iPhone, iPad und Mac persönliche Intelligenzfunktionen auf Basis generativer Modelle bereitstellt
  • Fortgeschrittene Funktionen, die über komplexere Daten Schlussfolgerungen ziehen müssen, benötigen größere Foundation Models; dafür hat Apple Private Cloud Compute (PCC) entwickelt
  • PCC ist ein für persönliche KI-Verarbeitung konzipiertes Cloud-Intelligence-System und zielt darauf ab, dass persönliche Nutzerdaten niemandem offengelegt werden, auch Apple nicht
  • On-Device-Verarbeitung ist vorteilhaft für Sicherheit und Datenschutz von Nutzerdaten
    • Daten, die nur auf dem Gerät des Nutzers liegen, befinden sich nicht an einem zentralen Angriffspunkt
    • Für die sensibelsten Cloud-Daten ist Ende-zu-Ende-Verschlüsselung eine starke Schutzmaßnahme
    • Bei Cloud-Diensten, für die Ende-zu-Ende-Verschlüsselung nicht geeignet ist, können temporäre Verarbeitung oder unabhängige zufällige Kennungen eingesetzt werden, die die Identität des Nutzers verschleiern

Grenzen bestehender Sicherheitsmodelle für Cloud-KI

  • Cloud-KI kann leistungsfähige Rechenzentrums-Hardware und große Machine-Learning-Modelle nutzen, benötigt aber unverschlüsselten Zugriff auf die Anfrage und zugehörige persönliche Daten
  • Daher lässt sie sich nicht allein mit vollständiger Ende-zu-Ende-Verschlüsselung verarbeiten; bestehende Cloud-KI-Dienste stützten sich bislang auf traditionelle Cloud-Sicherheitsansätze
  • Der traditionelle Ansatz hat drei Schwächen
    • Sicherheits- und Datenschutzgarantien sind schwer zu überprüfen
      • Selbst wenn ein Dienst angibt, bestimmte Nutzerdaten nicht zu protokollieren, ist dies für Forschende schwer zu verifizieren
      • Eine neue Version könnte versehentlich sensible Daten in Logs schreiben, oder ein Load Balancer, der TLS terminiert, könnte während der Fehlerbehebung massenhaft Nutzeranfragen protokollieren
    • Runtime-Transparenz ist schwer bereitzustellen
      • Cloud-KI-Dienste legen den tatsächlich ausgeführten Software-Stack normalerweise nicht offen
      • Selbst wenn ausschließlich Open-Source-Software verwendet wird, gibt es keine breit ausgerollte Methode, mit der Nutzergeräte oder Browser prüfen könnten, ob die Software des Dienstes unverändert ist
    • Starke Beschränkung privilegierter Zugriffe ist schwierig
      • SREs und Administratoren können bei Ausfällen oder schweren Vorfällen hoch privilegierte Zugriffe wie SSH nutzen
      • Ein Administrator könnte beim Sichern von Live-Serverdaten sensible Nutzerdaten kopieren, oder Kriminelle könnten Admin-Zugangsdaten stehlen und Nutzerdaten abgreifen

Die fünf Designanforderungen von PCC

  • Zustandslose Berechnung für persönliche Nutzerdaten

    • PCC darf empfangene persönliche Daten nur zum Zweck der Verarbeitung der Nutzeranfrage verwenden
    • Die Daten dürfen niemandem außer dem Nutzer bereitgestellt werden, auch keinen Apple-Mitarbeitern
    • Nach Rückgabe der Antwort dürfen sie in keiner Form aufbewahrt werden, auch nicht für Logging oder Debugging

  • Technisch erzwingbare Garantien

    • Sicherheits- und Datenschutzgarantien sind am stärksten, wenn wichtige Komponenten des Gesamtsystems eingeschränkt und analysiert werden können
    • Die Kernzusagen von PCC dürfen nicht von externen Komponenten wie TLS-terminierenden Load Balancern abhängen
    • Auch betriebliche Anforderungen wie das Sammeln von Servermetriken und Fehlerlogs müssen so unterstützt werden, dass der Datenschutz nicht geschwächt wird

  • Kein privilegierter Runtime-Zugriff

    • PCC darf keine privilegierten Schnittstellen enthalten, über die Apple-SREs auch bei der Störungsbehebung Datenschutzgarantien umgehen könnten
    • Auch das Nachladen zusätzlicher Software zur Erweiterung des privilegierten Zugriffsbereichs zur Laufzeit darf nicht unterstützt werden

  • Nicht-Targeting

    • Will ein Angreifer die persönlichen Daten eines bestimmten PCC-Nutzers ins Visier nehmen, muss er versuchen, das gesamte PCC-System breit zu kompromittieren
    • Selbst Angreifer, die in der Lieferkette physische Angriffe auf PCC-Knoten durchführen oder Zugang zum Rechenzentrum erhalten, dürfen eine bestimmte Nutzeranfrage nicht gezielt auf einen kompromittierten Knoten lenken können

  • Überprüfbare Transparenz

    • Sicherheitsforschende müssen mit hoher Zuverlässigkeit prüfen können, ob die Sicherheits- und Datenschutzgarantien von PCC den öffentlichen Zusagen von Apple entsprechen
    • Außerdem muss überprüfbar sein, ob die von Forschenden untersuchte Software mit der Software identisch ist, die in der PCC-Produktionsumgebung läuft

PCC-Knoten und Sicherheitsbasis

  • Die Vertrauenswurzel von PCC ist speziell entwickelte Serverhardware, der PCC-Compute-Knoten
  • PCC-Knoten bringen Hardware-Sicherheitstechnologien des iPhone ins Rechenzentrum
  • Das Betriebssystem ist eine gehärtete Teilmenge auf Basis von iOS und macOS, zugeschnitten auf LLM-Inferenz-Workloads
    • Es ist darauf ausgelegt, die Angriffsfläche klein zu halten
    • Es nutzt iOS-Sicherheitstechnologien wie Code Signing und Sandboxing
  • Apple schließt Komponenten, die üblicherweise für das Rechenzentrumsmanagement wichtig sind, aus PCC-Knoten aus
    • Remote-Shells
    • Werkzeuge zur systeminternen Beobachtung und allgemeine Observability-Tools
  • Stattdessen kommen zweckgebundene Komponenten zum Einsatz, die SRE-Mitarbeitern deterministisch nur kleine und begrenzte Betriebsmetriken bereitstellen
  • Mit Swift on Server wurde ein neuer Machine-Learning-Stack zum Hosten cloudbasierter Foundation Models entwickelt

Verarbeitung von Nutzeranfragen und Vermeidung von Datenspeicherung

  • PCC muss Daten aus Nutzeranfragen für die Modellinferenz verwenden und kann daher nicht allein mit vollständiger Ende-zu-Ende-Verschlüsselung gestaltet werden
  • Stattdessen erzwingt der PCC-Compute-Knoten während der Verarbeitung technisch den Datenschutz für Nutzerdaten und verhindert, dass Daten nach Abschluss eines Arbeitszyklus aufbewahrt werden können
  • PCC gibt drei Garantien für die Verarbeitung von Nutzerdaten
    • Das Nutzergerät sendet Daten ausschließlich zum Zweck der Verarbeitung einer Inferenzanfrage an PCC
    • Nutzerdaten verbleiben nur bis zur Rückgabe der Antwort auf dem PCC-Knoten, der die Anfrage verarbeitet
    • Nutzerdaten werden auch Apple-Mitarbeitern mit administrativem Zugriff auf Produktionsdienste oder Hardware nicht bereitgestellt
  • Wenn Apple Intelligence PCC verwendet, erstellt das Gerät eine Anfrage aus Prompt, gewünschtem Modell und Inferenzparametern
  • Der PCC-Client des Geräts verschlüsselt die Anfrage zunächst direkt mit dem öffentlichen Schlüssel eines verifizierten und kryptografisch authentifizierten PCC-Knotens
    • Dadurch entsteht Ende-zu-Ende-Verschlüsselung vom Nutzergerät bis zum verifizierten PCC-Knoten
    • Unterstützende Rechenzentrumsdienste wie Load Balancer und Privacy Gateways liegen außerhalb der Vertrauensgrenze und besitzen keinen Schlüssel zum Entschlüsseln der Anfrage
  • PCC-Knoten können nur Code ausführen, der durch Secure Boot und Code Signing zugelassen und kryptografisch gemessen wurde
    • Jeder ausführbare Code muss von Apple signiert und in einem für den jeweiligen PCC-Knoten genehmigten Trust Cache enthalten sein
    • Der Trust Cache wird von der Secure Enclave geladen und kann zur Laufzeit nicht verändert oder ergänzt werden
    • JIT-Mappings können nicht erstellt werden, wodurch Runtime-Codekompilierung oder -Injection verhindert wird
  • Code und Modell-Assets nutzen Integritätsschutz wie beim Signed System Volume
  • Die Secure Enclave erzwingt, dass Schlüssel zum Entschlüsseln von Anfragen weder dupliziert noch extrahiert werden können
  • Um Datenspeicherung zu verhindern, randomisiert die Secure Enclave bei jedem Neustart den Verschlüsselungsschlüssel des Datenvolumes und speichert diesen Schlüssel nicht dauerhaft
    • Bei jedem Neustart des Secure Enclave Processor eines PCC-Knotens wird das Datenvolume kryptografisch gelöscht
    • Der Inferenzprozess löscht zugehörige Daten nach Abschluss der Anfrage
    • Adressräume, die Nutzerdaten verarbeitet haben, werden regelmäßig recycelt, um die Auswirkungen unerwartet im Speicher verbleibender Daten zu verringern
  • Pointer Authentication Codes und Sandboxing erschweren Exploits, die Garantien umgehen sollen, und begrenzen laterale Bewegungen innerhalb eines PCC-Knotens
  • Die Schicht für Inferenzsteuerung und Dispatch ist in Swift geschrieben, um Speichersicherheit zu gewährleisten, und trennt die frühe Anfrageverarbeitung in einen separaten Adressraum

Entfernung privilegierter Runtime-Zugriffe

  • PCC-Knoten enthalten keine Remote-Shell und keinen Mechanismus für interaktives Debugging
  • Code Signing verhindert zwar das Nachladen von Code, doch Apple betrachtet bereits solche offenen Zugriffswege selbst als breite Angriffsfläche zur Umgehung von Systemsicherheit und Datenschutz
  • Auf PCC-Knoten kann der Developer Mode nicht aktiviert werden, und sie enthalten auch keine Werkzeuge, die für Debugging-Workflows erforderlich wären
  • Observability- und Management-Werkzeuge enthalten Datenschutzvorkehrungen, die eine Offenlegung von Nutzerdaten verhindern
    • Es gibt keinen allgemeinen Logging-Mechanismus
    • Nur vorab festgelegte, strukturierte und geprüfte Logs und Metriken dürfen den Knoten verlassen
    • Mehrere unabhängige Prüfebenen werden eingesetzt, um eine versehentliche Offenlegung von Nutzerdaten über diese Mechanismen zu verhindern
  • Dieses Design bietet erzwingbare Garantien, dass nur festgelegter Code auf Nutzerdaten zugreift und dass Nutzerdaten während der Systemadministration nicht aus dem PCC-Knoten herauslecken

Nicht-Targeting und Umgang mit Hardwareangriffen

  • Das Bedrohungsmodell von PCC umfasst hochentwickelte Angreifer, die physischen Zugriff auf Compute-Knoten haben und einige Hardware-Sicherheitseigenschaften des Systems umgehen können, um Daten während der Verarbeitung zu extrahieren
  • Apple schützt auf zwei Arten dagegen
    • Durch eine gehärtete Lieferkette für PCC-Hardware werden groß angelegte Hardwareangriffe sehr teuer und entdeckbar gemacht
    • Kleine Angriffe sollen nicht dazu genutzt werden können, gezielt bestimmte Nutzerdaten ins Visier zu nehmen
  • Die Hardware-Sicherheit von PCC beginnt in der Fertigung
    • Bevor Server versiegelt und Manipulationsschalter aktiviert werden, werden PCC-Knotenkomponenten inventarisiert und hochauflösend abgebildet
    • Nach Ankunft im Rechenzentrum und vor der PCC-Provisionierung erfolgt eine umfassende erneute Verifikation
    • Mehrere Apple-Teams gleichen Daten aus unabhängigen Quellen gegeneinander ab; zusätzlich überwachen von Apple unabhängige Drittbeobachter das Verfahren
    • Jeder PCC-Knoten erhält ein Schlüsselzertifikat, das in der Secure Enclave UID verwurzelt ist
    • Nutzergeräte senden keine Daten an PCC-Knoten, deren Zertifikat sie nicht verifizieren können
  • Um kleinere und raffiniertere Angriffe abzuwehren, nutzt PCC einen Ansatz der Zielstreuung (target diffusion)
  • Anfrage-Metadaten enthalten keine persönlich identifizierbaren Informationen über das Ursprungsgerät oder den Nutzer
    • Sie enthalten nur den begrenzten Anfragekontext, der für das Routing zum passenden Modell nötig ist
    • Nur diese Metadaten werden Load Balancern und Rechenzentrumskomponenten außerhalb der PCC-Vertrauensgrenze bereitgestellt
  • Die Metadaten enthalten einmalige Zugangsdaten auf Basis von RSA Blind Signatures, um gültige Anfragen zu autorisieren, ohne sie mit einem bestimmten Nutzer zu verknüpfen
  • PCC-Anfragen laufen über ein von Dritten betriebenes OHTTP relay
    • Es verbirgt die Ursprungs-IP-Adresse des Geräts, bevor die Anfrage die PCC-Infrastruktur erreicht
    • Es verhindert, dass Angreifer Anfragen anhand der IP-Adresse identifizieren oder mit Personen verknüpfen
    • Um Traffic anhand der Ursprungs-IP zu lenken, müssten sowohl das Drittanbieter-Relay als auch Apples Load Balancer kompromittiert werden
  • Nutzergeräte verschlüsseln Anfragen nur für eine Teilmenge von PCC-Knoten, nicht für den gesamten PCC-Dienst
    • Der Load Balancer gibt eine Teilmenge von Knoten zurück, die wahrscheinlich bereit sind, die Anfrage zu verarbeiten
    • Da der Load Balancer keine Nutzer- oder Gerätekennungen besitzt, kann er die Menge nicht zugunsten eines bestimmten Nutzers verzerren
    • Selbst wenn ein einzelner Knoten kompromittiert ist, kann er nur einen kleinen Teil der eingehenden Anfragen entschlüsseln
    • Die vom Load Balancer ausgewählte Menge von PCC-Knoten ist statistisch auditierbar

Überprüfbare Transparenz und Zugang für Forschende

  • Apple ist der Ansicht, dass Sicherheitsforschende die Ende-zu-Ende-Sicherheits- und Datenschutzgarantien verifizieren können müssen, damit öffentliches Vertrauen in PCC entsteht
  • Zum Start von PCC plant Apple, Software-Images aller Produktions-Builds für Sicherheitsforschung zu veröffentlichen
  • Nutzergeräte sind so gestaltet, dass sie Daten nur an PCC-Knoten senden, die kryptografisch nachweisen können, dass sie öffentlich gelistete Software ausführen
  • Apples Plan für überprüfbare Transparenz umfasst Folgendes
    • Veröffentlichung der Messwerte des gesamten auf PCC ausgeführten Codes in einem append-only, kryptografisch manipulationssicheren Transparency Log
    • Öffentliche Bereitstellung des Logs und der zugehörigen binären Software-Images, damit Datenschutz- und Sicherheitsexperten sie untersuchen und verifizieren können
    • Veröffentlichung und Pflege eines offiziellen Toolsets zur Analyse von PCC-Knotensoftware
    • Belohnung wichtiger Forschungsergebnisse über das Apple Security Bounty
  • Alle Produktions-Software-Images von PCC werden für unabhängige Binäranalysen veröffentlicht
    • Sie enthalten OS, Anwendungen und zugehörige ausführbare Dateien
    • Forschende können sie mit den Messwerten im Transparency Log abgleichen und verifizieren
    • Die Software wird innerhalb von 90 Tagen nach Aufnahme ins Log oder nach Bereitstellung des zugehörigen Softwareupdates veröffentlicht, je nachdem, was früher eintritt
    • Sobald ein Release signiert ins Log aufgenommen wurde, kann es nicht unbemerkt entfernt werden
  • Nutzergeräte verpacken den Schlüssel für die Anfrage-Payload nur dann mit dem öffentlichen Schlüssel des PCC-Knotens, wenn dessen attestierte Messwerte mit einem Software-Release im öffentlichen Transparency Log übereinstimmen
  • Code Signing verhindert das Laden nicht autorisierter Software und stellt sicher, dass der gesamte Code eines PCC-Knotens in die Attestation einbezogen wird

PCC-Forschungsumgebung und Prämien

  • Apple plant drei zusätzliche Maßnahmen, damit Forschende die Datenschutzversprechen von PCC schnell verifizieren und Probleme finden können
    • Veröffentlichung der PCC Virtual Research Environment
      • Ein Set aus Tools und Images, das PCC-Knoten auf Macs mit Apple silicon simuliert
      • Es kann eine minimal veränderte Version der PCC-Software booten, damit Virtualisierung gelingt
    • Zusätzlich zu den Binär-Images aller Produktions-PCC-Builds werden regelmäßig sicherheitskritische Teile des PCC-Quellcodes veröffentlicht
    • Erstmals auf einer Apple-Plattform enthalten PCC-Images sepOS-Firmware und den iBoot-Bootloader im Klartext
  • Das Apple Security Bounty belohnt Forschungsergebnisse zum gesamten PCC-Software-Stack
  • Für Probleme, die die Datenschutzversprechen von PCC schwächen, sollen besonders hohe Prämien gezahlt werden

Was später veröffentlicht werden soll

  • PCC ist darauf ausgelegt, die Anforderungen an zustandslose Berechnung, erzwingbare Garantien, keinen privilegierten Zugriff, Nicht-Targeting und überprüfbare Transparenz zu erfüllen
  • Nach der Bereitstellung von PCC als Beta sollen tiefergehende technische Erläuterungen folgen
  • Künftig sollen weitere technische Details zur Implementierung und Funktionsweise der einzelnen Kernanforderungen geteilt werden
  • Apple wird Sicherheitsforschenden bald erstmals die PCC-Software und die PCC Virtual Research Environment bereitstellen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-06-11
Meinungen auf Hacker News

  • Bei allem, was mit der Cloud oder dem Internet verbunden ist, muss man letztlich irgendjemandem vertrauen, sofern es nicht Open Source ist und die Server nicht dezentral sind.
    Apple kann sein Bestes tun, damit niemand außer Apple selbst auf die Daten zugreifen kann, aber Apple kontrolliert alle Endpunkte, iPhone-Updates und Server.
    Das erinnert an den Artikel „Web-based crypto is always snake oil“: https://www.devever.net/~hl/webcrypto
    Auch auf lokal gespeicherte Daten hätte Apple, wenn es wollte, die Macht zuzugreifen, und bei einer behördlichen Anordnung könnte es das auch tun. Deshalb bedeutet „privat“ aus meiner Sicht eher: Nur Apple kann es wissen, nicht etwa weniger Akteure.
    Das ist insofern besser, als Alternativen Daten an mehr Stellen durchsickern lassen können, hat aber wenig mit der beworbenen, unknackbaren Verschlüsselung zu tun.

    • Ich halte diese Einschätzung nicht für ganz fair, weil sie Apple in denselben Topf wie Google oder OpenAI wirft.
      Google verfolgt Nutzer offensichtlich für Werbung, Empfehlungen, AI usw., macht daraus kein Geheimnis, und es ist Kern des Geschäftsmodells.
      Apple dagegen hat sich bei diesem AI-System ziemlich ernsthaft bemüht, zu verhindern, dass Mitarbeiter auf Nutzerdaten zugreifen können, beschränkt Logging und Observability stark und entwickelt sogar eigene Chips und Betriebssysteme.
      Dass Clients nicht mit nicht auditierten Systemen kommunizieren, ist ebenfalls ein großer Unterschied.
      Man kann Apple nicht einfach beim Wort nehmen, aber Audits durch Dritte sind meiner Ansicht nach der Schlüssel, um der Privatsphäre dieses Systems zu vertrauen und sie zu verifizieren.
      Die Aussage „Apple weiß, was du machst“ klingt so, als könne jemand innerhalb von Apple auf Daten zugreifen, die vom Gerät in die Private Cloud gegangen sind; das scheint aber nicht der Fall zu sein.
      Dass Privatsphäre eine wichtige Säule von Apples Geschäftsmodell ist, ist ebenfalls ein Vertrauensfaktor. Apple war finanziell erfolgreich, indem es Produkte gebaut hat, die auf andere Weise Geld verdienen; in den Datenverkauf einzusteigen ist weder nötig noch eine gute Geschäftsidee.
      Skepsis bis zur Verifikation durch Dritte ist berechtigt, aber zu sagen, Apples Ansatz sei für Daten und Privatsphäre nicht besser als OpenAI oder Google, ist unfair.
    • Bei „es muss Open Source sein und die Server müssen dezentral sein“ wäre genauer: Es muss Open Source und selbst hostbar sein.
      Wenn Leute keinen eigenen Server betreiben können, lässt sich nicht wissen, ob der Code im öffentlichen Repository derselbe ist wie der Code, der tatsächlich auf den Cloud-Servern läuft; Open Source allein reicht also nicht.
    • Solange man nicht Hardwaredesign, Fertigungsprozess und sämtliche Software selbst überprüft, vertraut man letztlich auch bei lokaler Ausführung sehr vielen Menschen.
    • Das stimmt so nicht. Wenn man der Mathematik vertraut, kann man beweisen, dass die Software genau das tut, was sie behauptet.
      Natürlich ist dafür Verifikationsarbeit nötig, aber es ist trotzdem ein großer Fortschritt.
    • Wenn man Technik nutzen will, muss man irgendjemandem vertrauen. Apple konzentriert sich seit seiner Gründung auf Computer für einzelne Nutzer, die Botschaft war konsistent, und die Bilanz ist ordentlich.
      Aus meiner Sicht sind die Alternativen zerstreut und weniger fokussiert, daher würde ich Apple vertrauen.

  • Einen guten Kommentar des Kryptografen Matt Green gibt es hier: https://x.com/matthew_d_green/status/1800291897245835616?t=C...
    Ich weiß nicht, ob Matt klar ist, dass man seine Tweets ohne X-Account nicht lesen kann. BlueSky oder Mastodon wären gut.
    Zusammengeführter Thread: https://threadreaderapp.com/thread/1800291897245835616.html?...

    • Wenn er wirklich gewollt hätte, dass niemand seine Tweets liest, hätte er BluSky oder Mastodon genutzt.
    • Besonders zwei Tweets stechen hervor:
      „Im Blogbeitrag gibt es vermutlich noch etwa ein halbes Dutzend weiterer technischer Details. Das ist ein sehr sorgfältiges Design. Wenn man einem hervorragenden Team viel Geld gibt und sagt: Baut die beste ‚private‘ Cloud der Welt, dann sähe sie wahrscheinlich so aus.“
      „Natürlich muss man im Kopf behalten, dass Superspione nicht der wichtigste Gegner sind. Für viele Menschen ist der wichtigste Gegner das Unternehmen, das ihnen Gerät und Software verkauft hat. Dieses PCC-System steht für ein echtes Versprechen von Apple, nicht in Nutzerdaten ‚hineinzuschauen‘. Das ist bedeutsam.“
      Ich bevorzuge zwar, dass Daten auf dem Gerät bleiben, aber zumindest ist das ein großes Versprechen in die richtige Richtung – oder vielleicht die falsche Richtung, aber deutlich besser umgesetzt als bei der Konkurrenz.
    • Der Teil „Apple scheint nicht vorzuhaben, mit Private Compute explizit mitzuteilen, wenn Daten das Gerät verlassen. Nutzer stimmen dem nicht zu und werden nicht unbedingt benachrichtigt. Es passiert einfach wie durch Magie“ stört mich.
      Ich vermute, es wird eine Option geben, die AI-Funktionen insgesamt abzuschalten, also sowohl on-device als auch off-device.
      Warum sollte ein Gerätehersteller keine Option nur für On-Device-AI anbieten? Die AI-Funktionen von iOS 17 lassen sich auch heute ohne iCloud nutzen.
      Es wäre gut, wenn Apple eine eigene Domain wie *.pcc.apple.com verwenden würde, damit man auf Netzwerkebene filtern kann.
    • Ohne X-Account kann man es auch hier lesen: https://nitter.poast.org/matthew_d_green/status/180029189724...
    • Matt nutzt tatsächlich aktiv ein Mastodon-Konto, aber diese Geschichte scheint dort noch nicht aufgetaucht zu sein: https://ioc.exchange/@matthew_d_green

  • Selbst wenn man alles liest, läuft es am Ende auf „Vertraut uns“ hinaus. Apple kann jederzeit ein Update signieren und freigeben, das eine Backdoor enthält, und eine Regierung kann Apple mit einer einzigen Signatur dazu zwingen; das alles kann im Stillen passieren.
    Ich verstehe, dass das, was Apple tut, Vorteile hat. Aber wenn man Vertrauen verkauft, muss man zu 100 % ehrlich sein; wenn man nicht transparent macht, dass diese Art von Datenzugriff weiterhin möglich ist, wird die gesamte Botschaft kontaminiert.

    • Apple hat bereits Root-Rechte, und die Software ist Closed Source. Es gibt im Moment keinerlei Möglichkeit, zu verhindern, dass alle Daten hochgeladen werden.
      Wenn man den Leuten, die das Betriebssystem bauen, nicht vertrauen kann, hat man ein viel tieferes Problem, als sich über Off-Device-AI-Verarbeitung Sorgen zu machen.
    • Diese Logik unterscheidet sich nicht von dem, was Apple mit dem iPhone tun kann. Dass die Verarbeitung auf einem Server stattfindet, ändert gar nichts.
      Apple kann per Knopfdruck dafür sorgen, dass ein iPhone beliebige Daten auf Server hochlädt. Nach dieser Logik dürfte man gar nichts vertrauen, einschließlich lokal ausgeführter KI. Das ist vermutlich richtig, aber nicht praktikabel.
      Der letzte Teil von Matthew Greens Thread fasst es gut zusammen: „Manchmal steht Perfektion dem sehr Guten im Weg. In der Praxis ist die Alternative zu On-Device, sensible Daten an OpenAI oder noch dubiosere Orte zu schicken. Für viele Menschen ist der größte Gegner das Unternehmen, das ihnen das Gerät und die Software verkauft hat. PCC ist ein echtes Versprechen von Apple, nicht in die Daten ‚hineinzuschauen‘, und das ist eine große Sache. Da wir uns nun auf eine Welt zubewegen, in der ein Teil des Telefons in einem 2.000 Meilen entfernten Rechenzentrum lebt, müssen sich auch Sicherheitsleute daran gewöhnen und jeden Teil davon so sicher wie möglich machen.“

  • Sehr interessant. Apples Private Cloud Compute wirkt konzeptionell wie dasselbe wie System Transparency, ein Open-Source-Projekt, das ich mit Kollegen vor sechs Jahren gestartet habe.
    Ich freue mich auf mehr technische Details. Falls jemand von Apple das sieht, kann er sich gern unter stromberg@mullvad.net melden. Wir können unser Design und Apples Design diskutieren oder Feedback geben.
    Relevante Links: https://mullvad.net/en/blog/system-transparency-future
    http://system-transparency.org
    http://sigsum.org

    • https://en.m.wikipedia.org/wiki/Confidential_computing
      Was Apple macht, ist Confidential Computing. Wenn man sich Implementierungen ansieht, kann man mehr technische Details verstehen.
    • Beim Anschauen der Ankündigung hatte ich sofort denselben Gedanken und musste an System Transparency denken. Ich bin gespannt, wie die Bewertung ausfällt, nachdem die Details veröffentlicht und vollständig verstanden wurden.
    • Die meisten dieser Systeme verwenden dieselben grundlegenden Bausteine, wie Intel SGX, AMD SEV und NVIDIAs neue Technik; Apples Unterscheidungsmerkmal sehe ich aber in der Qualität der gesamten Implementierung und des Systems.
      Apple ist kein Mitglied des Confidential Computing Consortium, ARM aber schon.
      Auch bei Trusted Computing bin ich ziemlich optimistisch, und es scheint an Schwung zu gewinnen.
      Es wäre schön, wenn es offener wäre, sodass man den gesamten Stack kontrollieren und eigene Root-Zertifikate oder Schlüssel auf der Hardwareplattform installieren könnte, aber dennoch kann es viele Vorteile bringen.
      Ich erwarte, dass die Verbreitung weiter zunimmt, wenn Apple das in den Mainstream drückt.

  • Der Teil „Zum ersten Mal auf Apple-Plattformen enthalten PCC-Images die sepOS-Firmware und den iBoot-Bootloader im Klartext, sodass Forscher diese Kernkomponenten leichter untersuchen können als je zuvor“ ist sehr gut.
    Allerdings lässt die Aussage „Software wird innerhalb von 90 Tagen, nachdem sie ins Log aufgenommen wurde, oder nach Bereitstellung des entsprechenden Softwareupdates veröffentlicht – je nachdem, was früher eintritt“ theoretisch eine Lücke von bis zu 90 Tagen zwischen der Veröffentlichung verwundbarer Software und ihrer Auffindbarkeit.
    Ich hoffe, dass die tatsächliche Bereitstellung der Images viel näher an sofort als am Maximalwert liegt.

    • Wenn lästige Auditoren zu viele Fragen zu NSA-Backdoors oder CCP-Backdoors stellen, lässt sich das mit einem Zeitplan aus alle 89 Tage updaten und zurückrollen lösen.

  • In den USA ist vollständige Privatsphäre unmöglich. Denn die Regierung kann Apple nicht nur zwingen, die Interna offenzulegen, sondern Apple auch verbieten, darüber zu sprechen.
    Apple hat praktisch keine Möglichkeit, diese „Einschränkung“ zu umgehen. Wenn sich die Gelegenheit ergibt, kann man seinem „Abgeordneten“ dafür danken, dass er für die Verlängerung des PATRIOT Act gestimmt hat.

    • Private-Cloud-Compute-Server haben keinen persistenten Speicher, daher gäbe es beim Öffnen der Interna wohl nichts zu sehen.
      Um Daten aus eingehenden Anfragen zu sammeln, bräuchte die Regierung wohl so etwas wie eine angeordnete Echtzeitüberwachung; das könnte eine andere Situation sein.
      Natürlich bin ich nur irgendeine Person im Internet und habe mir lediglich ein Gegenargument zu dieser Sorge überlegt; ich weiß also nicht, ob das die richtige Richtung ist.
    • Die Formulierung „open up the kimono“ klingt für mich als asiatische Person unangenehm und unheimlich. Ich glaube nicht, dass nur ich das so empfinde.
    • Garantierte Privatsphäre und nachweisbare Privatsphäre sind nicht dasselbe.
      Die Regierung kann Daten anfordern. Aber Apples System würde einen solchen Eingriff der Öffentlichkeit offenlegen, selbst wenn Apple selbst nicht darüber sprechen dürfte.
    • Was Apple tun kann und offenbar tatsächlich über seine Produkte hinweg tut, ist, die angefragten Daten von vornherein nicht zu besitzen oder sie nicht im Klartext zu besitzen.
      Auch mit einem National Security Letter kann man keine Daten anfordern, die nicht mehr existieren.
    • Apples Beitrag liest sich so, als wäre das möglich. Ich frage mich, ob es eine bestimmte Stelle gab, die dir aufgefallen ist.

  • Es gibt eine große Frage: Für wen ist das eigentlich?
    Nicht falsch verstehen: Das ist ein hervorragender Aufwand und Nerd-Arbeit der A+-Klasse. Genau die Art von Ding, die meine Sprache spricht.
    Aber ich würde vermutlich einfach nach einer Möglichkeit suchen, die Nach-Hause-telefonieren-Funktion abzuschalten. Weil ich so ein Verhalten von vornherein nicht will.
    Soll mich das dazu bringen, anderen zu sagen: „Apple ist die sicherste Option“? Linux möchte ich nicht empfehlen, weil ich keinen Tech-Support leisten will.
    Ich habe inzwischen das Gefühl, zu dem alten Mann geworden zu sein, der „Finger weg von meinen Daten“ ruft.

    • Apple braucht Differenzierung, und als Weg dafür hat das Unternehmen Privatsphäre gewählt; dem stimme ich zu.
      Die Schlagzeilen zu Microsofts KI-Bemühungen waren größtenteils nahezu albtraumhaft, mit viel schlechter Presse.
      Wenn die Berichterstattung über Apple AI davon geprägt ist, dass Apple Sicherheit und Privatsphäre fast übertrieben ernst nimmt, werden die Leute sie vermutlich etwas beruhigter nutzen.
      Ich nutze OpenAI-Produkte nicht viel, aber wenn, dann lieber über Apples Anonymisierungsschicht als direkt bei OpenAI.
    • Was wäre, wenn man es nicht abschalten kann und genau diese extreme Sicherheit als Begründung dafür angeführt wird?
    • Das ist für die Aktionäre. Durch den KI-Investitionshype sind Microsoft und Nvidia bei der Marktkapitalisierung inzwischen größer als Apple.
      Apple muss zeigen, dass es ebenfalls ein KI-zentriertes Unternehmen sein kann. Allerdings hat Apple eine Unternehmenskultur, die Privatsphäre bewahren will.
    • Es ist für Leute wie mich.
      Es ist mir egal, ob die Regierung auf Daten zugreift. Ich möchte nur nicht, dass böswillige Akteure wie Betrüger, ausländische Regierungen, Ad-Tech-Firmen oder Versicherer auf meine persönlichen Daten zugreifen.
      Gleichzeitig möchte ich auch die Fähigkeiten von LLMs nutzen. Ist das wirklich eine so unrealistische Forderung?
      Realistisch betrachtet gehe ich davon aus, dass die US-Regierung bereits alle meine Daten hat. Mir gefällt der Status quo nicht, aber die Realität ist nun einmal die Realität.
    • Es ist auch für die Konkurrenten, die das Narrativ vorangetrieben haben, Apple sei „zurückgefallen“.
      Tatsächlich waren ein LLM und Cloud-Infrastruktur in iPhone-Größenordnung vorbereitet, und das ist nicht einfach eine Arbeit von zwei Jahren.
      Apple betont Privatsphäre so, wie man es von Apple erwartet.
      Auch Gemini könnte Privatsphäre für sich beanspruchen, aber wenn das stimmt, würden die Leute wohl eher denken, dass darunter die Leistung leidet.

  • Ich bin neugierig, wie sich das mit den von Apple kurz erwähnten AWS Nitro Enclaves vergleicht.
    Der Hauptunterschied scheint darin zu liegen, dass es bis hinunter auf Firmware-Ebene verifizierbar ist.
    Nitro Enclaves liefern keine Messwerte für Firmware[0] oder Hypervisor, und AWS erklärt, dass der Hypervisor-Code jederzeit transparent aktualisiert werden kann[1].
    Apple will sepOS, das Betriebssystem des Secure Enclave Processor, sowie Bootloader-Images bereitstellen.
    Der Blogpost ist nicht ganz eindeutig, aber es klingt so, als würde Apple auch den Quellcode dieser Komponenten bereitstellen.
    [0]: https://docs.aws.amazon.com/enclaves/latest/user/set-up-atte...
    [1]: https://docs.aws.amazon.com/pdfs/whitepapers/latest/security...

    • Nitro misst die Firmware. Wenn eine Firmware vorhanden ist, die nicht den Erwartungen entspricht, wird der Server faktisch vom EC2-basierten Netzwerk getrennt oder automatisch neu initialisiert.
      Automatisch wird ein Call ausgelöst, und wahrscheinlich schaltet sich auch das Security-Team ein.
      In EC2 ist der Hypervisor keine Firmware, daher gibt es keinen Grund, Hypervisor-Firmware zu messen.
      Die BIOS-/UEFI-Firmware des Mainboards wird überschrieben, wenn sie manipuliert wurde.
      Hypervisor-Code ist wie jeder Code immer signiert und wird von der Nitro-Karte über ein verifizierbares Sicherheitssystem, das Measured Boot oder Secure Boot nutzt, auf den Server gestreamt.
      Ich weiß nicht, was der kundenorientierte Begriff „Nitro enclaves“ genau bedeuten soll, aber EC2-Ingenieure bewegen sich bei einem Call wie eine Armee, sobald auch nur ein kleines Sicherheitsrisiko vermutet wird.
      Solche Grundlagen sind abgedeckt, und es geht sogar so weit sicherzustellen, dass echte Kundendaten nicht einmal in verschlüsselter Form in Core Dumps landen.
    • AWS musste das wegen seines eigenen Siliziums so machen. Intel, ARM und AMD bieten Attestation auf Firmware- und Hypervisor-Ebene.

  • Ich würde dieses Betriebssystem wirklich gern sehen und bin vorsichtig optimistisch, dass es der erste Fall sein könnte, in dem ein großer Tech-Konzern tatsächlich auditierbare Sicherheitsgarantien bietet.
    Je nachdem, wie sich das entwickelt, könnte Apple sich das Vertrauen, das die Nutzer bereits haben, bis zu einem gewissen Grad tatsächlich verdienen – und das wäre ziemlich cool.
    Noch besser wäre es, eine vollständige Auditierung der gesamten Verwaltungskette bereitzustellen; dafür müssten vermutlich auch andere Teile des Stacks teilweise offengelegt werden.
    Besonders wenn das Cloud-Betriebssystem wie versprochen Open Source wird, hätte das enormen Wert.
    Meine derzeitige Hauptsorge ist: Falls in der tatsächlichen Bereitstellung Virtualisierung verwendet wird, könnte es eine Backdoor geben, bei der die Secure Enclave des weiterhin proprietären Teils des Betriebssystems auf dem Nutzergerät die Schlüssel weitergibt und ein von uns nicht auditierter Hypervisor auf Container zugreift.
    Menschen mit mehr Security-Expertise werden bessere Fragen stellen.
    Wenn Apple auf Feedback von Forschern reagiert, könnten größere Teile dieser Toolchain auditierbar werden.
    Selbst wenn sich die Sicherheit der von Apple freigegebenen Use Cases nicht verifizieren lässt, könnte dieses Cloud-Betriebssystem ein großer Fortschritt für Security Reasoning und sichere Clouds sein, und Menschen könnten es unabhängig hosten oder Derivate erstellen.
    Der schlimmste Fall wäre, dass Apple es tatsächlich nicht umsetzt; aber zumindest scheint es recht wahrscheinlich, dass dieses Versprechen eingehalten wird. Dann wäre selbst der schlimmste Fall: „Es gibt eine sehr nützliche Open-Source-Codebasis für sicheres Computing in großem Maßstab“ – und das wäre gut, egal was mit den anderen Teilen passiert.

    • AWS Nitro Enclaves[0] ist ebenfalls ein nahes Beispiel, aber bei Apple ist entscheidend, dass das Unternehmen Private Compute für mehr als eine Milliarde macOS- und iOS-Kunden als Produkt anbietet.
      [0] https://docs.aws.amazon.com/enclaves/latest/user/nitro-encla...
    • Die Tech-Branche kopiert Apple gern.
      Bei Asahi Linux gibt es eine gute Übersicht zur Sicherheit der On-Device-Boot-Chain: https://github.com/AsahiLinux/docs/wiki/Apple-Platform-Secur...
      Die Formulierung „Wir werden die PCC Virtual Research Environment veröffentlichen: eine Sammlung von Tools und Images, mit der sich PCC-Knoten auf Apple-silicon-Macs simulieren und eine minimal angepasste Version der PCC-Software booten lässt, damit die Virtualisierung funktioniert“ klingt so, als seien PCC-Knoten Bare Metal.
      Könnte man PCC-Knoten auch auf einem iPad Pro mit M4 Apple Silicon simulieren?

  • Interessant ist der Teil: „Schließlich haben wir mit Swift on Server einen neuen Machine-Learning-Stack für das Hosting cloudbasierter Foundation Models entwickelt.“
    Auffällig ist, dass hier Swift on Server auftaucht: https://www.swift.org/documentation/server/