Design: WASM-Modul Signatur/Verifizierung

Erstellt am 15. Feb. 2018  ·  6Kommentare  ·  Quelle: WebAssembly/design

Dem Wasm-Modul fehlt ein Konzept für Sicherheitssignaturen und Überprüfung des Wasm-Modul-Bytecodes.

Eine solche Signatur würde die Überprüfung der Authentizität und Integrität von WebAssembly-Moduldateien ermöglichen, die über das Netzwerk übertragen werden.

Die binäre Kodierung (Wasm-Modul-Dateien) sollte eine Signatur enthalten.
Es sollte möglich sein, eine Signatur zu erstellen und zu überprüfen, ohne den Wasm-Bytecode zu parsen.

Ein Proof of Concept wurde implementiert und ist verfügbar unter https://github.com/frehberg/wasm-sign

Hier ist die Wasm-Modul-Signatur eine CustomSection (0), die den Abschnittsnamen "signature" verwendet und am Ende des Wasm-Modul-Bytecodes angehängt wird. Die Gesamtgröße/der Overhead beträgt 118 Byte. Die mit ECDSA erstellte Signatur. Unterstützte Kurven sind secp256k1/SHA256. Zukünftig sollen folgende Kurven unterstützt werden Ed25519 und secp384r1.

Aus Gründen der Interoperabilität wäre es sinnvoll, das Signaturformat zu standardisieren.

Hilfreichster Kommentar

Ich würde gerne besser verstehen, wie die aktuellen Mechanismen des Webs für Signatur und Verifizierung versagen und wie erstklassige WebAssembly-Unterstützung dies beheben würde. Insbesondere verfügt das Web über HTTPS und Sub-Resource Integrity, die zwar definitiv nicht perfekt sind, aber bereits einiges für uns tun.

Könnten Sie im Detail erklären, was Sie beheben möchten und inwiefern Ihr Vorschlag nicht dieselben Fallstricke hat?

Alle 6 Kommentare

Ich glaube, wir brauchen auch das Äquivalent im Textformat, vielleicht etwas wie: (signature ...) .

Für CSP könnte die Überprüfung der Signatur über https aktiviert sein? Oder denkst du, dass es standardmäßig aktiviert sein sollte?

Hmmm, "CSP & Prüfung": das wäre noch sehr früh im Prozess. Wir benötigen einen (oder mehrere) öffentlichen Schlüssel des Servers oder einer anderen Instanz zur Verifizierung, und es muss sich um einen öffentlichen Schlüssel mit EC (Ekliptikkurve) handeln.

Wenn es sich um einen HTTP(S)-basierten Dienst handeln würde, wäre es erforderlich, Zugriff auf den entsprechenden öffentlichen Schlüssel (Elliptic Curve Key) zu erhalten. Vielleicht könnte der entsprechende öffentliche Schlüssel als HTTP-Header-Attribut der Webseite eingebettet werden, die die WASM-Module lädt.

Nach signierten WASM-Modulen können diese von jedem Ort abgeholt und verifiziert werden.

Würde eine einzelne Organisation (Hoster) WASM-Dateien signieren oder würde eine Webseite signierte Module von mehreren Organisationen/Lieferanten abrufen?

Bei mehreren Organisationen entweder die "Organisations-ID" zur Signatur selbst hinzufügen oder eine Art SignerOrg als zusätzlichen Abschnitt definieren (auch mit fester Größe). der Vorgang könnte so aussehen: zuerst den SignerOrg-Abschnitt anhängen und dann beide signieren (original module-bytecode & signerorg-section)

es scheint, dass der Anwendungsfall und der Prozess zuerst definiert werden müssen ;)

Ich würde gerne besser verstehen, wie die aktuellen Mechanismen des Webs für Signatur und Verifizierung versagen und wie erstklassige WebAssembly-Unterstützung dies beheben würde. Insbesondere verfügt das Web über HTTPS und Sub-Resource Integrity, die zwar definitiv nicht perfekt sind, aber bereits einiges für uns tun.

Könnten Sie im Detail erklären, was Sie beheben möchten und inwiefern Ihr Vorschlag nicht dieselben Fallstricke hat?

Nun, ich kann es versuchen

Eingebettete Signaturen werden bereits für PDF, Win-Binärdateien, Treiber, XML-Dokumente usw. verwendet.
Wofür könnten signierte WebAssembly-Module gut sein?

Stell dir vor

  • Web-Anwendung, die WebAssembly-Code ausführt, um Banking-PINs zu berechnen.
  • Rust/C++-Anwendungen, die WebAssembly für eingebettete Ausführungs-Engines verwenden und Kryptowährungsverträge auswerten
  • HSM-s verwenden WebAssembly-Bytecode, um PINs im Server-Backend zu berechnen
  • IoT-Geräte, deren Firmware unter Verwendung bestimmter Versionen verschiedener WebAssembly-Module zusammengestellt wird (Content Addressable Storage/Linking)

Im letzteren Fall wäre die Firmware-Version von IoT-Geräten eine Liste von WebAssembly-Modulen, die bestimmte Versionen verwenden. Die IoT-Geräte könnten ihre Version der WebAssembly-Module auf andere Geräte in der Nachbarschaft verteilen (http://www.korhal.io/whitepaper.pdf). Es wird kein zentraler Update-Server benötigt.

In all diesen Fällen reicht ein TSL-Transport nicht aus, um Vertrauen aufzubauen, aber der Code sollte signiert sein, damit der Empfänger Authentizität und Integrität entlang der gesamten Lieferkette vom Entwickler/Lieferanten bis zum Webbrowser oder der Ausführung überprüfen kann Motor.
Die Signatur verhindert die Manipulation von Daten im Ruhezustand und in rechtlicher Hinsicht Nichtabstreitbarkeit für betriebskritischen Code.

Die Verwendung einer abgetrennten Signatur (im Vergleich zu einer eingebetteten Signatur im WASM-Modul) wäre komplexer zu handhaben. Die eingebettete Signatur würde das Handling entlang der Bytecode-Supply-Chain vereinfachen.

Ich bin nicht überzeugt, dass dieses Problem am besten auf der Ebene von WASM selbst angegangen wird. Alle Daten können mit Signaturen versehen werden. Warum sollten sie Teil der Sprache selbst sein?

Für mich klingt es auch so, als ob Sie am HTTP Origin-Signed Responses Standard interessiert sein könnten.

Traurig zu hören. Teil der Sprache, weil ein signierter wasm eine gültige wasm-Datei behalten würde; es wäre also keine Art Wrapper, der vor dem Parsen entfernt werden müsste. Nun, dank der Existenz von CustomSection ist es möglich, solche Strukturen hinzuzufügen. Es wäre nur schön gewesen, es von "Custom-Feature" zu einem "Standard-Feature" zu verschieben.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

spidoche picture spidoche  ·  4Kommentare

artem-v-shamsutdinov picture artem-v-shamsutdinov  ·  6Kommentare

cretz picture cretz  ·  5Kommentare

chicoxyzzy picture chicoxyzzy  ·  5Kommentare

ghost picture ghost  ·  7Kommentare