-
Notifications
You must be signed in to change notification settings - Fork 691
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WASM Module Signature/Verification #1185
Comments
I believe we also need the equivalent in the text format, maybe something like: For CSP, checking the signature could be ON over https? Or do you think that it should be on by default behavior? |
Hmmm, "CSP & checking": that would be very early in the process. We would need a (or multiple) public key of the server or any other instance for verification, and it must be a public key using EC (eclliptic curve). If it would be related to HTTP(S)-based service, it would be necessary to get access to the corresponding public-key (elliptic curve key). Maybe the corresponding public key could be embedded as HTTP-header-attribute of web-page which is loading the WASM modules. Having signed WASM-modules, these could be fetched from any location and being verified. Would there be a single organization (hoster) signing WASM files or would a web-page fetch signed-modules from multiple organizations/suppliers? In case of multiple organizations, either adding the "organization-id" to the signature itself, or defining some some kind of SignerOrg as additional Section (fixed size as well). the process might look like: first attaching the SignerOrg Seciton and then signing both (original module-bytecode & signerorg-section) it seems the use-case and process must be defined first ;) |
I'd like to better understand how the Web's current mechanisms for signature and verification fail, and how first-class WebAssembly support would fix this. Specifically, the Web has HTTPS and Sub-Resource Integrity which, while definitely not perfect, do quite a bit for us already. Could you explain in detail what you'd like fixed, and how your proposal doesn't have the same pitfalls? |
Well, I can try Embedded signatures are already used for PDF, Win-binaries, drivers, XML-documents, etc. Just imagine
In latter case, the firmware-version of IoT devices would be a list of WebAssembly-modules using specific versions. The IoT devices could spread their version of WebAssembly modules to other devices in the neighborhood (http://www.korhal.io/whitepaper.pdf). No central update-server would be required. In all of these cases a TSL-transport is not sufficient to establish trust, but the code should be signed so the recipient is able to verify authenticity, integrity all along the supply-chain from developer/supplier up to the web-browser or execution engine. Using a detached signature (compared to an embedded-signature into the WASM-module) would be more complex to handle. The embedded signature would simplify the handling all along the bytecode-supply-chain. |
I'm not convinced this is a problem best addressed at the level of WASM itself. Signatures can be added on to any data. Why would they need to be part of the language itself? Also, it sounds to me like you might be interested in the HTTP Origin-Signed Responses Standard. |
Sad to hear. Part of the language, because a signed wasm would keep a valid wasm file; so it would not be kind of wrapper to be removed before parsing. Well, thanks to the existence of CustomSection it is possible to add such structures. Just, would have been nice to move it from "custom-feature" to a "standard-feature". |
The Wasm-module lacks a concept for security signatures and verification of the Wasm-module-bytecode.
Such signature would permit the verification of authenticity and integrity of WebAssembly module files being transfered over network.
The binary encoding (Wasm-module-files) should contain a signature.
It should be possible to create and verify a signature without parsing the Wasm-bytecode.
A proof of concept has been implemented and is available at https://github.com/frehberg/wasm-sign
Here the Wasm-Module-Signature is a CustomSection (0) using the section-name "signature" and being attached to the end of the Wasm-module-bytecode. Total size/overhead is 118 bytes. The signature created using ECDSA. Supported curves are secp256k1/SHA256. In future the following curves shall be supported Ed25519 and secp384r1.
For interoperability it would be useful to standardize the signature format.
The text was updated successfully, but these errors were encountered: