Hardware-Attestierung als exklusiver Helfer
(grapheneos.social)- Apple und Google weiten den Einsatz von hardwarebasierter Attestierung aus, fördern deren Nutzung in immer mehr Diensten und stärken langfristig eine Struktur, die nicht genehmigte Hardware und konkurrierende Betriebssysteme ausschließt
- Googles Play Integrity API und Apples App Attest API arbeiten auf ähnliche Weise; Play Integrity verlangt bei
strong integrityHardware-Attestierung und entwickelt sich in die Richtung, diese schrittweise auch fürdevice integrityzu verlangen - Apples Privacy Pass, Googles eingestelltes Web Environment Integrity und
reCAPTCHA Mobile Verificationbringen Attestierungsanforderungen ins Web, sodass der Zugang zu Webdiensten ohne iOS oder ein zertifiziertes Android-Gerät blockiert werden kann - Die Play Integrity API sperrt GrapheneOS aus, obwohl es sicherer ist als die zugelassenen Ziele, und erlaubt zugleich Geräte ohne Sicherheits-Patches seit 10 Jahren, wodurch statt eines Sicherheitsmotivs eher die Lizenzierung von Google Mobile Services und der Ausschluss von Konkurrenz im Vordergrund stehen
- Da Behörden- und Bankdienste zunehmend App Attest und Play Integrity verlangen, werden Apple-Geräte oder von Google zertifizierte Android-Geräte faktisch erzwungen; das kann sich auch auf den Webzugang aus Umgebungen wie Windows, Desktop-Linux oder FreeBSD auswirken
Attestierungsanforderungen breiten sich ins Web aus
- Apples Privacy Pass bringt Hardware-Attestierung ins Web, um auf eigener Hardware beim Bestehen von CAPTCHAs zu helfen
- Damals hielten viele das für harmlos, weil es wohl nicht viele Websites geben würde, die Nutzer ohne Apple-Hardware blockieren
- Sowohl Apple als auch Google werden sehr wahrscheinlich umfassendere Hardware-Attestierung ins Web bringen
- Banken und Behörden verlangen zunehmend die Nutzung mobiler Apps und können innerhalb der Apps Attestierung einsetzen, um von Apple oder Google genehmigte Geräte und Betriebssysteme zu erzwingen
- Apples Privacy Pass, Googles eingestelltes Web Environment Integrity und reCAPTCHA Mobile Verification bringen diese Entwicklung ins Web
- Die aktuelle Berichterstattung zu reCAPTCHA Mobile Verification behandelt ihre Auswirkungen und Bedeutung nicht angemessen
- In bestimmten Situationen verlangt dieses Verfahren zum Bestehen von reCAPTCHA das Scannen eines QR-Codes mit einem zertifizierten Smartphone und bringt damit Hardware-Attestierungsanforderungen auch auf Windows, Desktop-Linux, OpenBSD und andere Systeme
- Durch seine Kontrolle über reCAPTCHA ist Google in der Lage, für die Nutzung eines großen Teils des Webs faktisch iOS oder ein zertifiziertes Android-Gerät vorauszusetzen
- Google definiert die Anforderungen für die Android-Zertifizierung; dazu gehört unter anderem die erzwungene Bündelung von Google Chrome
- reCAPTCHA Mobile Verification funktioniert derzeit mit dem sandboxed Google Play von GrapheneOS, existiert aber als Mittel, dies auch auf Systemen ohne Hardware-Attestierung durchzusetzen
- Wenn diese Anforderung angewendet wird, können Menschen ohne iOS- oder Android-Gerät auch ohne weitere Bedingungen ausgesperrt werden
Play Integrity und der Ausschluss von GrapheneOS
- Googles Play Integrity API verbietet die Nutzung von GrapheneOS, obwohl GrapheneOS deutlich sicherer ist als jedes zugelassene Ziel
- Die Play Integrity API schließt auch andere Alternativen aus; das Problem betrifft nicht nur AOSP-basierte Betriebssysteme
- Selbst mit einem mobilen Betriebssystem auf FreeBSD-Basis lässt sich dieses Problem nicht vermeiden, man würde nur noch stärker ausgeschlossen
- Die Play Integrity API erlaubt sogar Geräte ohne Sicherheits-Patches seit 10 Jahren
- Die Stufe
device integritykann durch Spoofing umgangen werden, aber Google kann dies wahrscheinlich ziemlich gut erkennen und blockieren, sobald es in größerem Umfang genutzt wird - Für eine Umgehung der Stufe
strong integritysind aus TEE oder SE abgeflossene Schlüssel erforderlich - Die Play Integrity API ist nicht besonders sicher, und eine vorübergehende Umgehung ist nicht außergewöhnlich schwierig
- Es gibt Frameworks zum Spoofing von Software-Prüfungen, und auch abgeflossene Schlüssel zur Umgehung von Hardware-Attestierung können gekauft werden
- Allerdings werden Umgehungen zunehmend schwieriger, und ihre Gültigkeitsdauer wird immer kürzer
- Play Integrity bietet keine nützliche Sicherheitsfunktion, funktioniert aber sehr gut beim Ausschluss von Konkurrenz
- Dienste, die Apple App Attest oder Google Play Integrity verlangen, helfen vor allem dabei, dass Apple und Google ihr Duopol bei Mobilgeräten behalten
- Play Integrity ist besonders wichtig, weil AOSP Open Source ist
- GrapheneOS kann per Hardware-Attestierung verifiziert werden, und der Grund dafür, dass Google GrapheneOS in Play Integrity sperrt, ist, dass es keine Google Mobile Services lizenziert und keine wettbewerbswidrigen Regeln befolgt
- Diese Regeln wurden unter anderem in Südkorea bereits als rechtswidrig eingestuft
- Dienste sollten die Nutzung beliebiger Hardware und Betriebssysteme nicht verbieten
- Dass Google Geräte ohne Patches seit 10 Jahren zulässt, aber deutlich sicherere Betriebssysteme nicht, macht ein Sicherheitsargument kaum haltbar
- Es geht darum, über die GMS-Lizenzierung ein Monopol durchzusetzen
Behörden-, Bankdienste und die Rolle der Regulierung
- Regierungen schreiben die Nutzung von Apple App Attest und Google Play Integrity zunehmend nicht nur für eigene Dienste, sondern auch für kommerzielle Dienste vor
- Die EU treibt diesen Trend voran, indem sie solche Anforderungen auf digitale Zahlungen, Identitätsprüfung, Altersverifikation und Ähnliches ausweitet
- Viele EU-Regierungs-Apps haben solche Anforderungen bereits
- Statt die schwerwiegenden wettbewerbswidrigen Praktiken von Apple und Google zu stoppen, beteiligen sich Regierungen über ihre eigenen Dienste direkt am Ausschluss von Konkurrenz
- Von Menschen Apple-Geräte oder von Google zertifizierte Android-Geräte zu verlangen, ist keine Sicherheit, sondern eine Wettbewerbsbeschränkung
- Dass für den Zugang zu Bank- und Behördendiensten oder zum Bestehen bestimmter reCAPTCHAs ein unverändertes iOS- oder Google-Mobile-Services-Android-Gerät nötig wird, ist kein Problem nur von GrapheneOS
- Es hat dieselben Auswirkungen auch auf Windows, Desktop-Linux, FreeBSD und andere Systeme
- Es ist kein Problem, das speziell Pixel, Android-Geräte oder AOSP-basierte Betriebssysteme betrifft, sondern kann auch den Desktop-Webzugang beeinträchtigen
Android-Attestierungs-APIs und Unified Attestation
- Android bietet mit der Zulassung verifizierter Boot-Key-Fingerprints ein standardisiertes Hardware-Attestierungssystem, das alternative Betriebssysteme unterstützt
- Die Hardware-Attestierung von Android nutzt hauptsächlich Googles Root of Trust und den Dienst für Remote Key Provisioning, aber die API selbst unterstützt auch alternative Roots of Trust
- Android-Hardware-Attestierung sollte nicht dazu verwendet werden, Nutzer auszuschließen, die bestimmte Hardware oder Betriebssysteme nicht verwenden
- Dass beliebige Roots of Trust und Betriebssysteme zugelassen werden können, lässt Diensten jedoch mehr Spielraum, mehr Ziele zu akzeptieren
- Wenn es Google um Sicherheit ginge, könnte es dasselbe System verwenden, um GrapheneOS in Play Integrity zuzulassen
- Unified Attestation ist ein weiteres wettbewerbswidriges System, das von mehreren europäischen Unternehmen vorangetrieben wird und Nutzer beliebiger Hardware und Software in ähnlicher Weise ausschließt
- Unified Attestation ist keine Lösung und deutlich schlechter als die viel offenere Hardware-Attestierungs-API von Android
- Vollas Unified Attestation ist vollständig auf der Hardware-Attestierungs-API von Android aufgebaut
- Vollas Unified Attestation existiert, um die Kontrolle darüber, was erlaubt ist, bei einer zentralen Instanz und den Diensten zu konzentrieren
2 Kommentare
Ich mag Google so sehr, ich wünschte, es gäbe ungefähr fünf davon 🥰
Hacker-News-Kommentare
Die EU Digital Identity Wallet (EUDI) verlangt Hardware-Attestierung von Google oder Apple und bindet damit faktisch alle digitalen Identitäten der EU an die beiden US-Giganten
Man redet von digitaler Souveränität und trifft dann so eine Entscheidung
Es wirkt, als werde der Schutz von Kindern über die Souveränität gestellt
https://gitlab.opencode.de/bmi/eudi-wallet/wallet-developmen...
Ich verstehe von Anfang an nicht, warum man diese Entscheidung getroffen hat
Es wirkte eindeutig wie eine Antwort für technisch unbedarfte Durchschnittsnutzer
Viele betonen, wie wichtig Souveränität und die Abkehr von der US-Abhängigkeit seien, aber ich verstehe nicht, warum es keinen größeren Widerstand gibt, und frage mich, ob man das einfach als Unwissenheit sehen muss
Das gilt besonders für datenschutzfreundliche Identifikatoren, deshalb wird Geräte-Attestierung wichtig
Wenn man nicht prüfen kann, ob die Hardware das Extrahieren der Schlüssel verhindert, kann man nicht garantieren, dass ein Identitätsschlüssel wirklich im Gerät eingeschlossen ist
Das Schlimmste ist, dass motivierte Kriminelle am Ende Wege finden werden, diese Schlüssel zu extrahieren und für Betrug zu nutzen, und dass dadurch Open Source und offenes Computing zerstört werden
Wer überhaupt aufgefordert werden sollte, einen Ausweis vorzulegen, ist eine andere Frage, und in den meisten rein Online-Szenarien würde ich sagen: „nein“, aber die Finanzbranche nutzt seit Jahrzehnten bereits eine vertrauenswürdige Lösung
Dass zugelassene Chips und Software verlangt werden, ist hier nicht einmal das größte Problem
Sie verwenden keine Zero-Knowledge-Proofs oder Blind Signatures
Deshalb bleibt bei jeder Attestierung durch ein Gerät ein Beweis-Paket zurück, das genutzt werden kann, um diese Handlung mit dem Gerät zu verknüpfen
Sie tun so, als würden sie sich um Datenschutz kümmern, indem sie eine Umwegskonstruktion einbauen, bei der einmalige IDs über einen Zwischenserver aus einer statischen Geräte-ID bezogen werden, aber da man nicht weiß, was diese Zwischenserver tun, muss man davon ausgehen, dass alles protokolliert wird
So sieht nur der Pfad der Remote-Attestierung aus, der DRM-ID-Pfad ist noch schlimmer. Dort gibt es keinen sinnvollen Umweg, sodass alle Lizenzserver Zugriff auf die im Silizium eingebrannte statische Identität haben. Vom Google-Konto-Pfad ganz zu schweigen
Einen Vorschlag, bei Remote-Attestierung Blind Signatures zu verwenden, gab es tatsächlich, aber derzeit wird das an keiner sichtbaren Stelle genutzt: <https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation>
Dafür gibt es mehrere mögliche Gründe. Der offensichtliche ist, dass man Datenschutzverletzungen ermöglichen will, wenn man sie braucht, oder dazu verpflichtet wurde
Ein anderer Grund ist, dass ohne die Möglichkeit, Nachweise einem bestimmten Gerät zuzuordnen, als Missbrauchsbegrenzung praktisch nur Rate Limiting bleibt, und das aus deren Sicht womöglich nicht ausreicht. Ein Angreifer könnte Gerätefarmen aufbauen, bei denen jedes Gerät böswilligen Akteuren per Fernzugriff Attestierungen liefert und damit pro Stunde Geld verdient
Ich weiß nicht, wie ein Dienst Rate Limiting durchsetzen könnte und dabei anonym bliebe
Wenn ein Dienst zählen kann, ob zwei Anfragen vom selben Akteur kommen, dann könnten sich auch zwei Dienste als derselbe Dienst ausgeben, feststellen, dass zwei Anfragen vom selben Akteur stammen, und sie miteinander verknüpfen
Wenn man sagt: „Das Problem ist nicht Hardware-Attestierung, sondern dass keine Zero-Knowledge-Proofs verwendet werden“, dann normalisiert man neues Verhalten
Das sollte man nicht tun. Ob man nun Zero-Knowledge-Proofs nutzt oder Hardware-Attestierung mit modernster Sicherheitstechnik umsetzt, das Problem ist Hardware-Attestierung selbst
Dasselbe gilt für Altersverifikation. Das Problem ist nicht, dass Altersverifikation anfällig für Datenlecks ist, sondern Altersverifikation an sich
Seit der Ankündigung der App war ich ziemlich sicher, dass die Struktur in etwa so aussehen würde
Ich meine, mich an Diskussionen im Graphene-Forum zu erinnern, wonach die DRM ID nicht nur erhalten bleibt, sondern auch profilübergreifend gleich ist
Falls ja, was könnte dann die Einführung antreiben – Zuckerbrot oder Peitsche?
Das ist ein Thread, der gut zeigt, warum diese Technik zu einem Problem für alles „Offene“ wird
Die Behauptung „Wir bauen einfach unser eigenes separates Web“ funktioniert nur so lange, bis alle Dienste hinter einem Web verschwinden, das den Besitz eines von Google oder Apple genehmigten Mobilgeräts erzwingt
Google blockiert mich dort inzwischen komplett
Wenn ich Quadrate anklicke, um die geforderten Felder auszuwählen, wiederholt sich das endlos, und wenn ich die Audio-Version nutzen will, werde ich wegen verdächtiger Aktivität vollständig ausgesperrt
Deshalb fahre ich inzwischen allein und habe dieses Jahr auch meine Mitgliedschaft nicht verlängert
Eine ähnliche Erfahrung hatte ich zuletzt, als Facebook begann, der einzige Weg zur Teilnahme an bestimmten Veranstaltungen zu werden. Damals habe ich einfach akzeptiert, ausgeschlossen zu sein, und meine Zeit und mein Geld anderweitig eingesetzt
Schon jetzt sind viele Unternehmen oder soziale Gruppen nur über Dinge wie Facebook oder WhatsApp zugänglich
Das fühlt sich wirklich wie eine bizarre Cyberpunk-Dystopie an. So ähnlich, als könnte man Briefe und Pakete nur an Menschen schicken, die beim selben privaten Postdienst angemeldet sind, oder als dürfte man nur auf Straßen fahren, die eine Gegenseitigkeitslizenz mit der Marke des eigenen Autos haben
Selbst wenn es Sicherheitsfunktionen gäbe, bliebe der Kollateralschaden bestehen, Betriebssysteme, die nicht von Google oder Apple stammen, zu Bürgern zweiter Klasse zu machen, und genau das ist das Kernproblem
Für Banken oder die Interaktion mit Behörden wäre das wohl unrealistisch, aber für viele andere Dienste vielleicht machbar
Allerdings müsste man trotzdem noch etwas bauen, die Kosten würden auf weniger Menschen verteilt, und der Vorteil geringerer Komplexität, weil man keine Werbetechnik bauen muss, könnte das womöglich nicht ausgleichen
Vielleicht ist das aber eine Art Problem der guten Zutaten. Hardware wäre schwieriger
Das klingt nach einer dummen Frage, ist aber ernst gemeint
Als Intel 1999 beschloss, eine softwarelesbare Seriennummer in CPUs einzubauen, gab es enormen Widerstand, und die Entscheidung wurde am Ende zurückgenommen
Danach haben Autoritäre, die „Sicherheit“ und Trusted Computing vorantreiben wollten, TPM und verwandte Technologien weiter gepusht und damit auch zum Aufstieg mobiler Walled Gardens beigetragen
Die TPM-Anforderung von Windows 11 war ein weiterer Schritt in diese Richtung. Es war schockierend, wie viel Propaganda es hier und anderswo dafür gab, als sei das etwas Gutes
Wenn „Sicherheit“ als Begründung genannt wird, zeigt sich, dass man einem beträchtlichen Teil der Menschen fast alles leicht aufzwingen kann. Hoffentlich wird diese Zahl kleiner
Der Krieg gegen universelles Computing geht weiter, und wir müssen weiterkämpfen
Stallman hatte, wie so oft, recht. Es ist Zeit, sein „Right to Read“ noch einmal zu lesen. Wenn es das noch nicht gibt, wäre auch ein KI-erstellter Kurzfilm dazu vielleicht eine gute Idee
„Wer Freiheit für Sicherheit aufgibt, verdient am Ende weder das eine noch das andere“
KI ist ein vollständig zentralisiertes und monopolistisches Werkzeug
Wie man auch in diesem Thread sieht, gibt es bei solchen Problemen statt Antrieb, Wut und selbstorganisierter Gegenwehr nur Verzweiflung wie „Es interessiert niemanden“ oder „Wir können nichts tun“
Aufgeben ist der sicherste Weg zu verlieren
Die Kommentare hier lesen sich so, als sei Attestierung an sich schlecht, aber das eigentliche Argument scheint eher zu sein, dass es ausdrücklich einen Pfad geben sollte, der auch Anbieter einschließt, die nicht Apple oder Google sind
Der Titel klingt so, als seien Apple und Google böse, würden das zur Verfestigung ihres Monopols tun und als stelle sich der Konkurrent GrapheneOS den Menschen zuliebe dagegen
Aber wenn der letzte Einwand ist, dass sie selbst ebenfalls hätten einbezogen werden sollen, und sie sagen, Googles Play Integrity API habe sie aus unklaren Gründen abgelehnt und diese Gründe seien böswillig, dann erkennen auch sie offenbar einen sicherheitlichen Nutzen an
Für wichtige Identitätsdaten braucht man wirklich einen Nachweis der vollständigen Signaturkette. Das ist der einzige Weg, eine Situation zu vermeiden, in der man mit KI leicht betrügerische Identitäten erzeugen kann
Patente und Urheberrecht waren die ursprünglichen Formen des Monopols
Solange Software nicht Open Source ist, ist sie per Definition monopolistisch
Es überrascht mich, dass es nicht mehr reiche HN-Nutzer gibt, die GrapheneOS unterstützen
Das Venn-Diagramm aus wohlhabenden Menschen und Technikern, denen dieses Thema wichtig ist, dürfte sich ziemlich stark überschneiden, und Graphene leistet in diesem Bereich trotz vieler Schwächen viel Grundlagenarbeit
Unsere Zivilisation braucht dringend eine Möglichkeit, moderne Mikroelektronik nach der Herstellung zu verändern, zumindest in gut ausgestatteten Reparaturwerkstätten
Eigentlich hätten wir das schon gestern gebraucht
Die Alternative wäre, es zu verbieten, universell verkaufte Computergeräte mit irgendeiner Art von frühem Bootloader im Mask-ROM der CPU oder des SoC auszuliefern
Das heißt, der erste Befehl, den die CPU nach dem Reset ausführt, müsste aus einem Speicher kommen, der sich physisch außerhalb des CPU-Pakets befindet
Siehe: https://pluralistic.net/2026/01/01/39c3/
Selbst relativ einfache SoCs erledigen im undokumentierten Boot-ROM schon vor dem architekturdefinierten Reset-Vektor eine Menge Arbeit, um den Reset-Prozess zu unterstützen
Es hat auch großen Wert, niedrigstufige DFU-Routinen in ein Boot-ROM zu legen, das nicht versehentlich gelöscht werden kann
Das SoC-Silizium könnte so überarbeitet werden, dass es jeden ausgeführten Befehl vom Einschalten bis zum Befehl zur Übergabe an Secure Boot protokolliert
Mit zusätzlichen Befehlen zur Statusabfrage, Overflow-Prüfung oder Signaturerstellung würde das Betriebssystem seine eigene Attestierung erzeugen und dabei Manipulationen vor dem Boot implizit melden
Es würde reichen, es zu verbieten, fest einkodiertes Schlüsselmaterial in den Bootloader zu legen und mit diesen Schlüsseln den geladenen Code zu verifizieren
Erstaunlich ist, dass wir dem Google-Apple-Duopol erlauben, darüber zu entscheiden, wer auf völlig unabhängige Dienste zugreifen darf und wer nicht
Stell dir vor, du wirst wegen einer anti-Google Haltung aus Google-Diensten ausgesperrt und kannst dich dann auch nicht mehr bei deinem Bankkonto anmelden
Wir brauchen wirklich eine Zerschlagung von Alphabet
Bei einem so ernsten Thema wäre ein tatsächlicher, logisch aufgebauter Text auf einer Seite viel besser gewesen als ein schwer lesbarer Thread