Firefox-Hack zur Umgehung fehlender WebUSB-Unterstützung
(github.com/ArcaneNibble)- Dieses Proof-of-Concept zeigt, dass eine Webseite auch ohne WebUSB mit einem bestimmten USB-Gerät kommunizieren kann, indem ein Raspberry Pi Pico so arbeitet wie ein U2F-Sicherheitsschlüssel und damit die bestehende Unterstützung des Browsers für Sicherheitsschlüssel nutzt
- Der Pico übernimmt keine echte Sicherheitsfunktion, sondern versteckt beliebige Daten im Key Handle der
U2F_AUTHENTICATE-Nachricht und im ECDSA-Signaturbereich, um die LED-Steuerung und das Auslesen des Zustands vonGP22zu implementieren - Das U2F-Key-Handle ist als undurchsichtiger Datenblob konzipiert, den der Sicherheits-Dongle besitzt; diese Funktion, mit der günstige Dongles trotz begrenzten Speichers Registrierungen für viele Websites verarbeiten können, wird hier zur Datenverbergung missbraucht
- Diese Methode ist keine Schwachstelle für den Zugriff auf beliebige USB-Geräte und funktioniert nur mit Geräten, die absichtlich gegen die Regeln verstoßen; das Problem des USB-Sicherheitsmodells, bei dem sich bösartige USB-Geräte als Tastatur oder Maus ausgeben können, bleibt jedoch bestehen
- Der eigentliche Punkt geht über die Frage hinaus, ob Firefox WebUSB unterstützen sollte: Wie schafft man eine gesunde Computing-Plattform und ein entsprechendes Ökosystem, die Entwickler und Nutzer gleichermaßen verstehen und kontrollieren können?
Demo für den Zugriff auf USB-Geräte ohne WebUSB
- Dieses Proof-of-Concept zeigt einen Weg, wie eine Webseite mit einem USB-Gerät kommunizieren kann, ohne die politischen Debatten rund um WebUSB oder Anforderungen an die Nutzereinwilligung
- Die schnelle Demo läuft, indem man
u2f-hax.uf2auf die RP2040-Version des Raspberry Pi Pico lädt undindex.htmlauf localhost oder in einem anderen secure context öffnet - Die Buttons
On!undOff!auf der Seite schalten die LED des Pico um - Der Zustand des Pins
GP22wird regelmäßig auf der Seite aktualisiert und kann getestet werden, indem man ihn mit Draht oder Metall mit dem benachbarten GND-Pad kurzschließt
Funktionsweise: Als U2F-Sicherheitsschlüssel ausgeben
- Der Pico wird als U2F-Dongle emuliert, also als physischer Sicherheitsschlüssel für Zwei-Faktor-Authentifizierung
- Statt echte Sicherheitsfunktionen auszuführen, versteckt er beliebige Daten in einer
U2F_AUTHENTICATE-Nachricht- Die Daten befinden sich im Key Handle und im Signaturbereich
- Wenn das Key Handle mit
0xfeedfacebeginnt, behandelt der Pico die Benutzerpräsenz sofort als bestätigt und gibt die Daten zurück
- Aus Sicht des Browsers wird damit eine vorhandene Funktion zur Interaktion mit Sicherheitsschlüsseln genutzt
Warum sich das U2F-Key-Handle missbrauchen lässt
- Das Key Handle von U2F ist konzeptionell ein undurchsichtiger Datenblob, der dem Sicherheits-Dongle gehört
- Der typische Ablauf ist folgender
- Der Dongle gibt als Ergebnis der Registrierung ein Key Handle zurück
- Die relying party speichert diesen Wert unverändert
- Bei der Authentifizierung übergibt sie denselben Wert wieder an den Sicherheits-Dongle
- Diese Funktion hängt mit einem Design zusammen, das es günstigen Dongles mit knappem Speicher erlaubt, Registrierungen für viele Websites zu verarbeiten
- Der Dongle speichert intern einen eindeutigen Master-Verschlüsselungsschlüssel
- Bei einer neuen Registrierung erzeugt er ein Public-/Private-Key-Paar und gibt den Public Key zurück
- Den mit dem Master-Schlüssel verschlüsselten Private Key gibt er als Key Handle zurück
- Bei der Authentifizierung entschlüsselt er das übergebene Key Handle mit dem Master-Schlüssel und nutzt den Private Key
- Damit der interne Algorithmus nicht festgelegt wird, wird das Key Handle als undurchsichtig behandelt; genau diese Eigenschaft wird hier zum Verstecken beliebiger Daten genutzt
Rückgabedaten als ECDSA-Signatur verpackt
- Um Daten zurückzusenden, werden beliebige Daten als ECDSA-Signatur versteckt
- Eine ECDSA-Signatur ist ein Tupel aus zwei Zahlen
(r, s), wobei jede Zahl in Bezug auf die Ordnungndes Base Points der elliptischen Kurve berechnet wird - Zahlen innerhalb des Wertebereichs der Ordnung des secp256r1-Base-Points werden in ASN.1 verpackt
- In manchen Fällen lässt sich erkennen, ob es sich um eine korrekt berechnete ECDSA-Signatur handelt, aber für Komponenten, die nicht die relying party sind, gibt es keinen starken Grund, über eine grundlegende Gültigkeitsprüfung hinauszugehen
- Das Verhalten unterscheidet sich je nach Browser
- Chrome prüft offenbar, ob die Signaturzahlen im Bereich von
0bisnliegen - Firefox führt nicht einmal diese Bereichsprüfung durch
- Chrome prüft offenbar, ob die Signaturzahlen im Bereich von
- Um die grundlegende Prüfung von Chrome zuverlässig zu bestehen, wird das erste Byte jeder Zahl mit
0x7f„verschwendet“- Dadurch ist die Zahl immer positiv und kleiner als
n - Der Software-Stack bis hin zu Browser-JavaScript reicht diese „hinreichend gültigen“ Zahlen unverändert weiter
- Dadurch ist die Zahl immer positiv und kleiner als
Frage der Sicherheitslücke und des USB-Sicherheitsmodells
- Diese Technik ist keine Schwachstelle für den Zugriff auf beliebige USB-Geräte
- Sie funktioniert nur mit Geräten, die absichtlich gegen die Regeln verstoßen, und ist im Kern ein absichtlich verwundbar gemachtes Gerät
- Dennoch ist das Sicherheitsmodell rund um USB-Geräte auf den meisten Plattformen generell fragwürdig
- Wenn ein bösartiges USB-Gerät angeschlossen wird, kann es über Geräte wie Tastatur oder Maus Dinge tun, die auch ein Benutzer tun könnte
- Unbekannte Geräte sollten grundsätzlich nicht an Computer, Smartphones oder andere Systeme angeschlossen werden
Fragen an Plattform und Ökosystem
- Das Ziel dieses Proof-of-Concepts geht über ein persönliches „weil es möglich ist“ hinaus und soll den aktuellen Zustand von Computing-Plattformen sichtbar machen
- Aus Sicht eines Widget-Herstellers möchte man, dass Endnutzer ein neues Gerät mit möglichst wenig Aufwand verwenden können
- Im heutigen Computer- und Widget-Ökosystem gibt es eine Diskrepanz zwischen dem, was Nutzer intuitiv für möglich halten, und dem, was tatsächlich möglich ist
- Ein „Sicherheitsschlüssel“ sollte wie ein sauber verpacktes Single-Purpose-Produkt wirken, tatsächlich kann er aber beliebigen Code ausführen, auf beliebige Weise erscheinen und beliebige Aktionen durchführen
- Auch USB Rubber Ducky und O.MG Cable berühren dieses Problem
- Im „Universal“-Charakter von USB liegen Vor- und Nachteile zugleich
- Weder Menschen noch Computer haben eine gute Möglichkeit, leicht und zuverlässig zu unterscheiden, ob ein USB-Gerät gegen die Interessen des Nutzers arbeitet, ihm hilft oder das Ergebnis größerer Macht und emergenten Verhaltens ist
- Das Web ist der einfachste Weg, Software auszuliefern, die auf dem Computer einer anderen Person läuft
- Entwickler müssen zwar weniger Details aller Zielplattformen lernen, lernen damit aber zugleich auch weniger über die Konventionen und Erwartungen der einzelnen Plattformen
- Die Diskussion sollte über Fragen wie „Warum implementiert Firefox WebUSB nicht?“ oder „Verliert es dadurch weiter gegen Chrome?“ hinausgehen und sich darauf verlagern, gesunde Plattformen für das gesamte Computing bewusst zu pflegen, einschließlich Desktop, Laptop, Tablet, Smartphone, IoT und Smart Home
1 Kommentare
Meinungen auf Hacker News
Firefox unterstützt keine Funktion zur Kommunikation mit beliebigen USB-Geräten, Chrome hat dafür jedoch WebUSB.
Allerdings unterstützt auch Firefox die Kommunikation mit U2F-Sicherheitsschlüsseln über USB.
Dieses Projekt ist der Versuch, einen Mikrocontroller so zu tun lassen, als wäre er ein U2F-Sicherheitsschlüssel, um in Firefox per USB mit dem Mikrocontroller zu kommunizieren.
Mit der JavaScript Credentials API (https://developer.mozilla.org/en-US/docs/Web/API/Credential_...) und ein paar Tricks werden Daten gesendet und Antworten empfangen.
Es lässt sich aber nutzen, um ein Custom-Gerät zu bauen, das eine Webseite ohne Zustimmungs-Prompt verwenden kann.
Tastaturen mit QMK/Via-Firmware über WebUSB zu customizen, ist nahezu ein Albtraum.
Damit der Browser mit der Firmware kommunizieren kann, muss man praktisch ein
/dev/hidraw-Gerät weltweit lesbar machen, was zu allerlei Keylogging-Spielereien einlädt.Die Art der Nutzung fühlt sich sehr unangenehm an, und die Offline-Customizing-Tools basieren ebenfalls alle auf Electron, sodass der Vorteil nicht groß ist.
Der noch halbwegs vernünftige Workaround ist, auf einer Website anhand eines Template-JSONs das gewünschte Tastaturlayout zu erstellen, das resultierende JSON herunterzuladen und die Firmware dann mit einem Flashing-Tool mit sudo-Rechten auf die Tastatur zu schreiben.
Trotzdem wäre es schön, wenn es eine weniger unangenehme Methode gäbe.
main()ändern.Bei Tastaturen ließe sich etwas Ähnliches wohl auch machen.
Das Dateisystem müsste nur bei fehlerhaftem JSON einen Fehler ausgeben, und man könnte dem emulierten Dateisystem Sicherheitseigenschaften geben, sodass nur Administratoren schreiben dürfen.
Dann wäre kein sudo nötig; man müsste nur einen Berechtigungs-Prompt bestätigen, wenn man die neue Konfiguration auf das virtuelle Flash-Laufwerk herunterlädt oder kopiert.
Zumindest Caps Lock scheint sich auch aus JavaScript heraus setzen zu lassen, womit man im Grunde einen 1-Bit-Kommunikationsbus hätte.
Mit normalen OS-Tools wären sogar bis zu 3 Bit möglich.
Der Kern des Berechtigungsmodells ist, dass die Browser-Familie den Hardwarezugriff vermittelt.
Natürlich muss man dem Browser dafür von Anfang an Hardwarezugriff geben.
Wenn man dem Browser als Verwalter der Hardware-Abstraktionsschicht nicht vertraut, kann man das ablehnen, aber genau dieses Modell erwartet Via.
Ich weiß nicht, warum das „unangenehmer“ sein soll, als dem Browser Zugriff auf Kamera, Mikrofon oder das Lesen von Speicher zu geben.
Selbst auf einem gesperrten, von der Firma verwalteten Chromebook kann ich https://usevia.app aufrufen und eine QMK-Tastatur problemlos bearbeiten, und auf diesem Gerät kann ich natürlich keinerlei
/dev-Nodes anfassen.Bei QMK läuft alles über manuelles Flashen.
Trotzdem war ich überrascht, wie einfach es ist, Layout, Layer und Beleuchtung per Code zu customizen; das liegt stark am Community-Support.
Sie ist nicht so bequem wie Via, bietet aber immerhin einen grafischen Keymap-Editor, kompiliert die Firmware und ist deutlich weniger aufgebläht.
Mit Keeb.io-Boards habe ich damit gute Erfahrungen gemacht.
Dieser Kommentar-Thread ist interessant, weil sich hier Leute, die WebUSB nutzen, und erzählen, wie gut es ist, mit Leuten mischen, die es nicht nutzen und nicht verstehen, wozu man es braucht.
Persönlich fand ich es sehr gut.
Die meisten WebUSB-Utilities, die ich nutze, gibt es auch als installierbare Apps, aber ich verwende sie so selten, dass die Web-Version viel einfacher ist als der Prozess, eine App zu installieren, zu aktualisieren und dann auszuführen.
Ein weiterer Vorteil ist, dass man eine zu installierende App weniger hat.
Ich hätte gedacht, dass das bei Leuten beliebt ist, die es leid sind, für jedes einzelne Gerät eine App installieren zu müssen.
Deshalb ist es ein zweischneidiges Schwert.
Komfort und Sicherheit passen nicht gut zusammen.
Es ist nützlich und einfach, aber es eignet sich auch viel zu gut dafür, Schwachstellen entstehen zu lassen.
Die Aufblähung des Webs muss aufhören.
Der Browser sollte nicht zum universellen Spülbecken werden, in das jeder in der Tech-Branche alles hineinwirft, was er gerade will.
Eine native Anwendung zu installieren ist auch nicht so schwierig.
Streng genommen ist das nicht USB, sondern HID, aber die Idee ist ähnlich.
Das geht zwar ein wenig am Thema vorbei, aber der Großteil dieses Threads wirkt eher wie eine allgemeine Diskussion über WebUSB als über den ursprünglichen Artikel.
Der Hack im Originalbeitrag selbst ist natürlich ziemlich cool.
Einerseits brauchen wir WebUSB wirklich, andererseits möchte ich ganz und gar nicht, dass normale Nutzer WebUSB bekommen.
In der Praxis funktionieren Zustimmungs-Pop-ups nicht, und Leute bestätigen alles, ohne es zu merken.
Sie sagen dann, sie hätten „nichts angeklickt“, während man 50 Spam-Push-Benachrichtigungen wegwischen und die Push-Berechtigungen von einem Dutzend „News“-Sites entfernen muss.
Ehrlich gesagt gefällt mir das Berechtigungsmodell im Stil des Internet Explorer bis zu einem gewissen Grad.
Um bestimmte Funktionen zu aktivieren, musste man eine Site als „vertrauenswürdig“ markieren.
Es ist schwer zu finden, dauert etwas, ist ein wenig verwirrend, und in einem Modal-Pop-up im Systemstil erscheint ein ziemlich furchteinflößendes großes Warnsymbol.
Wenn man für gefährliche APIs wie WebUSB oder WebBluetooth erst eine Site als „vertrauenswürdig“ markieren müsste, würden sie viel seltener versehentlich aktiviert.
Die User Experience wäre immer noch besser als die Installation einer nativen App, und Sandboxing gäbe es obendrein; dieser Kompromiss scheint sich zu lohnen.
Durchschnittliche ältere Nutzer wissen überhaupt nicht, was Web-Benachrichtigungen sind.
Mit der Zeit aktivieren sie versehentlich Benachrichtigungen von dubiosen Websites und glauben Web-Spam-Benachrichtigungen auf ihrem Handy wie „HELLO YOUR PHONE HAS VIRUS DOWNLOAD "CLEANER APP" TO FIX BEFORE PHONE DIE“ tatsächlich.
Manche Leute scheinen eine Superkraft zu haben, Dinge kaputtzumachen.
Wenn man etwas nicht buchstäblich unmöglich macht, finden sie garantiert einen Weg, es versehentlich doch zu schaffen.
Sie folgen Anleitungen, die Einstellungen ändern, die sie nicht verstehen, führen Funktionen aus, die sie nicht verstehen, und gewähren Zugriffsrechte, die sie nicht verstehen.
Egal wie kompliziert man den Ablauf macht, wie viele Warnungen man anbringt und wie sehr man versucht, solche Dummheiten zu verhindern – es passiert trotzdem.
Das Problem ist, dass es auch Menschen gibt, die wissen, was sie tun, und solche Funktionen absichtlich nutzen.
Diese Menschen können mächtige Funktionen zu schätzen wissen, die man einem Dummkopf niemals geben sollte.
Aber wenn man diese Macht freilegt, lässt sich in der Praxis kaum vermeiden, dass es von Leuten wimmelt, die dumme Dinge damit anstellen – und das ist frustrierend.
Ein großes Problem ist, dass man nicht richtig versteht, wie viele Nutzer überhaupt nicht verstehen, was sie tun.
Google versteht nicht, wie man sichere Software für solche Menschen entwirft.
Umständliche Abläufe wirken sinnlos, haben aber oft einen klaren Zweck:
Sie sollen sicherstellen, dass die Absicht des Nutzers gefestigt ist.
Apple hat einige Web-APIs in letzter Zeit so implementiert, dass sie nur funktionieren, wenn die Website installiert wurde; das wirkt wie eine Strategie, die Design für Menschen versteht.
Sie ermöglicht den Zugriff auf nützliche PWA-Funktionen, lässt aber nicht jede beliebige Site sie nach Belieben verwenden.
Es gibt einen zusätzlichen Schritt, den normale Menschen verstehen können.
Eine installierte PWA bleibt auf dem Home-Bildschirm sichtbar, erinnert also sichtbar an die erteilte Berechtigung und ist ein klares Signal dafür, dass der Nutzer diesen Zugriff wollte.
Viele Menschen müssen mit Geräten interagieren, und derzeit sind Apps, die über geschlossene App Stores bereitgestellt werden, oft praktisch die einzige Option.
Wenn man mehr Menschen eine Möglichkeit zum Zugriff auf Geräte geben will, deren offizieller Support eingestellt wurde, ist WebUSB der mit Abstand einfachste Weg.
In einer anderen Welt, in der Chrome das nicht unterstützen würde, müssten normale Nutzer [python or other scripting language] installieren und ausführen können.
Wenn Entwickler wirklich engagiert wären, müssten sie vielleicht eine Desktop-App bereitstellen oder den langen und teuren Weg einer App-Store-Einreichung gehen.
Ich denke, dass sich für WebUSB eine sichere UI bauen lässt, und mir fällt auch nicht wirklich ein, welche Geräte eines durchschnittlichen Nutzers, die eingesteckt sind, darüber kompromittiert werden könnten.
Mit WebUSB wird man vermutlich keine Tastatur oder Maus (HID), keinen Speicher, kein WLAN, kein Audio, keine Smartcard und kein U2F-Gerät übernehmen können.
Aber für proprietäre Etikettendrucker, allerlei Spielzeug und Geräte sowie das Programmieren und Flashen von Mikrocontrollern ist es sehr nützlich.
Sie sind einfach und bequem zu nutzen, aber sie machen es auch leicht, einem nicht vertrauenswürdigen Dritten versehentlich sehr weitreichenden Zugriff zu gewähren.
Einer Seite Berechtigungen zu geben, sollte – wie gesagt – ein Ablauf sein, den der Nutzer explizit im Berechtigungsbereich startet.
Dasselbe gilt für sandboxed Desktop-Anwendungen.
Wenn eine App dauerhaft den Bildschirm aufzeichnen möchte, sollte sie diese Berechtigung explizit in der Berechtigungsverwaltung erhalten müssen.
Sie sollte keinen modalen Dialog anzeigen können, der Leute einfach dazu bringt, „yes“ zu klicken.
Denn in vielen Fällen verstehen Menschen technisch nicht, worum sie gebeten werden.
USB Serial ist wirklich großartig
Es macht endlich Schluss mit lästigen Electron-Apps, die nur für einen einzigen Zweck da sind
Inzwischen gibt es Tools zum Konfigurieren von Geräten direkt im Browser, und das ist sehr gut
Man denke nur an ESPHome und die Hunderte darauf basierenden Projekte, Betaflight, ELRS, Flipper
Dass WebKit, da es von Apple entwickelt wird, wenig Unterstützung bietet, verstehe ich; ebenso, dass man vorsichtig ist, wenn man Zugriff auf Peripheriegeräte erlaubt
Aber Firefox ist anders
Firefox hatte gravierende Defizite bei der Unterstützung von Hardware-„Verbindungen“ und war schon lange nicht mehr entwicklerfreundlich, weshalb ich ihn am Ende nicht mehr genutzt habe
Als Grund für die fehlende Unterstützung heißt es, die Zustimmung des Nutzers allein reiche für den Gerätezugriff nicht aus, aber das ergibt keinen Sinn
Man hätte es auch hinter einen Developer-Flag o. Ä. setzen können
Blink hat bewiesen, dass man es sicher machen kann
Es wirkt, als würde man ohne Grund stur bleiben und die Use Cases nicht sehen, die den Browser nützlich machen würden
https://developer.mozilla.org/en-US/docs/Web/API/Serial
https://mozilla.github.io/standards-positions/
U2F-Anmeldedaten sollten eigentlich nicht phishbar sein
Das liegt daran, dass die U2F-API des Browsers den Domainnamen in die Token-Anfrage einfügt
Mit WebUSB konnte eine Website jedoch ein Token für einen beliebigen Domainnamen anfordern
Weil U2F und WebUSB beide recht ähnlich aussehende Zustimmungsdialoge anzeigten, war es praktisch unmöglich zu verhindern, dass manche Nutzer sie verwechseln
Kaum zu glauben, aber Googles Lösung bestand darin, viele Geräte in WebUSB auf eine Blockliste zu setzen
Wer heute U2F-Geräte herstellt, muss Google bei jedem neuen Produkt bitten, es zur Blockliste hinzuzufügen
Alle finden es gut, dass der Browser eine sichere Sandbox ist, in der nicht vertrauenswürdiger Code ausgeführt werden kann; ich verstehe nur nicht, warum man so viele Löcher in diese Sandbox bohren will
[1] https://www.yubico.com/support/security-advisories/ysa-2018-...
[2] https://github.com/WICG/webusb/blob/main/blocklist.txt
Für ein paar Dutzend Endnutzer, die keine Electron-App herunterladen müssen, um mit physischer Hardware zu interagieren, lohnt es sich meiner Meinung nach nicht, Fingerprinting-Risiken in Kauf zu nehmen
Eine Funktion zu implementieren und sie dann hinter einem Developer-Toggle wegzusperren, ist Wahnsinn
Damit verschwendet man Hunderte Stunden Entwicklungszeit, die man für Sinnvolleres nutzen könnte, nur um eine Funktion freizulegen, die ohnehin niemand findet
Als Entwickler ist es mir egal, wenn solche Chrome-only-APIs Chrome vorbehalten bleiben
Man muss ohnehin einen Chromium-Browser bereithalten, falls eine Website in Firefox tatsächlich kaputt ist; für Web-USB-Arbeiten kann man dann eben den verwenden
Es ist eine coole Technikdemo, aber nichts, was ein Browser tun sollte
Dass niemand eine Firefox-Erweiterung gebaut hat, die WebUSB-Funktionalität hinzufügt, zeigt meiner Ansicht nach ebenfalls, dass selbst den Leuten, die diese Funktion nutzen, der Entwicklungsaufwand nicht wert ist
Es wurden Datenschutz- und Sicherheitsprobleme vorgebracht
Web Serial ist kein Webstandard, und es kann keiner werden, solange Mozilla oder Apple diese Probleme nicht als gelöst ansehen
Google kann allein keinen Webstandard daraus machen; Standards brauchen Konsens
Die Mozilla-Diskussion ist hier: https://github.com/mozilla/standards-positions/issues/336
Die WebKit-Diskussion ist hier: https://github.com/WebKit/standards-positions/issues/199
Ich kann mir kaum vorstellen, Firefox fürs Webbrowsing wegen webusb aufzugeben
Es sollte Software sein, die man herunterladen kann und die nicht von externen Servern abhängt
Wenn das Gerät allerdings von vornherein für den Betrieb auf die Server dieser Firma angewiesen ist, ist es gut, dass man keine Software herunterladen und ihr vertrauen muss
Dass browserbasierter Code keinen Zugriff auf USB-Ports haben kann, könnte sogar eine gute Sache sein
Denn ich muss keine Windows-VM mehr starten, um Firmware-Updates oder Utility-Tools von Herstellern von Audioequipment auszuführen, die das unterstützen, etwa Novation
WebUSB sollte dasselbe für mehr Gerätetypen ermöglichen, aber natürlich braucht es dafür einen geeigneten Berechtigungsmechanismus
Für Leute, die häufig Geräte flashen, ist der Vorteil klar
Aber normale Nutzer, also die übrigen rund 3 Milliarden Menschen, interessiert das überhaupt nicht
Für sie Löcher in die Sandbox zu bohren, ist bestenfalls nachlässig
Die Lösung könnte ein eigenes Tool für genau diesen Zweck sein, vielleicht sogar ein eigener Browser
So etwas wie ein Flash Browser
Er könnte zusätzliche Tools enthalten, die bei dieser Aufgabe helfen
Etwa vorkonfigurierte Allow- oder Blocklisten, Bookmarks zu gängigen Flashing-Tools und Referenzmaterial
Damit ließe sich eine bessere Erfahrung schaffen, als WebUSB roh in den Browser hineinzuzwingen
Ich verstehe die Kontroversen und die Kritik rund um diesen „Standard“, aber als ich damit GrapheneOS auf ein Pixel-Telefon geflasht habe, war es die angenehmste, einfachste und schnellste OS-Installation, die ich je auf irgendeinem Gerät gemacht habe
Buchstäblich einstecken, klicken und direkt loslegen
Überraschend ist der Teil, dass der private Schlüssel mit einem „Master“-Key verschlüsselt und der verschlüsselte private Schlüssel als Key Handle zurückgegeben wird
In der Praxis dürfte das zwar funktionieren
Aber einem Angreifer unbegrenzte Gelegenheiten zu geben, den privaten Schlüssel in seiner Hand zu entschlüsseln, klingt so, als könnte das irgendwann nach hinten losgehen – aber was weiß ich schon
Beispielsweise könnte man den privaten Schlüssel auch per deterministischer Schlüsselableitung aus dem Key Handle erzeugen
Ein Angreifer kann auch das per Brute Force angreifen, genauso wie den im Key Handle gespeicherten verschlüsselten standortspezifischen Schlüssel
Der Kernpunkt ist, dass ein zustandsloser Authenticator per Definition global deterministisch ist, also über Secrets und Sites hinweg
Wenn ein Eingabe-Ausgabe-Paar gegeben ist, lässt sich das interne Secret per Brute Force angreifen
Die Lösung besteht darin, diesen internen Zustand groß genug zu machen, damit das rechnerisch unmöglich wird
Ich frage mich, worin die politische Kontroverse rund um WebUSB besteht
Es ist eine von Google entwickelte, Blink-spezifische API, die Mozilla und Apple aus Datenschutz- und Sicherheitsgründen abgelehnt haben
Ohne zwei unabhängige Implementierungen kann es kein Webstandard werden, und Google konnte niemanden außerhalb von Google davon überzeugen, es zu implementieren
Trotzdem wird es auf vielen Websites so dargestellt, als würden Firefox und Safari es „nicht unterstützen“
„This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.“
— https://wicg.github.io/webusb/
„WebKit declined to implement several APIs, including WebUSB, due to concerns over fingerprinting“
„We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label.“
— https://github.com/WebKit/standards-positions/issues/68
„Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.“
— https://mozilla.github.io/standards-positions/#webusb
Der Browser kann bereits über normale OS-Schnittstellen auf die benötigten USB-Geräte zugreifen
Tastatur und Maus sind offensichtliche Beispiele
Ich sehe nicht, warum irgendeine Website einen separaten direkten Zugriff benötigen sollte
Als Use Cases sehe ich im Grunde nur, Web-Programmierern, die keine eigenständige Anwendung schreiben wollen, Zugriff zu geben, oder zusätzliche Möglichkeiten zur Nutzerverfolgung bereitzustellen
Beidem möchte ich nicht vertrauen
Ich vertraue nicht einmal Google und Mozilla genug, um ihnen solchen Zugriff zu geben, geschweige denn irgendwelchen Fremden, die eine Website gebaut haben
Nicht alles muss über das Web zugänglich sein
Ich weiß nicht, wo man die Grenze ziehen sollte, aber USB-Zugriff überschreitet sie für mich
Normalerweise gewinnen dabei diejenigen, die die Funktion sofort haben wollen
Denn Sicherheitslücken wirken wie hypothetische Probleme, bis sie tatsächlich in freier Wildbahn ausgenutzt werden
Je mehr das passiert, desto tiefer wird die Abhängigkeit von Chrome
Auch ich will das nicht