WASM module signatures proposal

[asraa]

Hi, this is a copy of WebAssembly/WASI#425 essentially.

We would like to formally introduce Wasm module digital signatures and verification of Wasm bytecode. There was a number of people who were interested in this and I have an interest in getting this working for Istio/Wasm as well as supporting Wasm types in sigstore (e.g. by supporting it in a transparency log to allow easy signing/verification for developers).

Right now, there are people who are signing packages or whole .wasm files (https://bytecodealliance.github.io/lucet/Integrity-and-authentication.html, https://medium.com/wasmer/securing-wapm-packages-with-package-signing-3cf0d12f32f3 container signing). But, embedded signatures could allow implementations to validate and make decisions before instantiating the module and allow signatures irrespective of the delivery module (OCI image, etc). This way, recipients can verify the authenticity along the whole supply-chain, from who built the module, to who adds information, directly to the execution engine.

Custom sections are natural places to hold this information (see the linked specification below) in the module.

@jedisct1 started a "specification" repository with what requirements, options, and possible solutions we have https://github.com/wasm-signatures/design. Please take a look, and feel free to comment or add more use-cases.

Links:
#1185
https://github.com/jedisct1/wasmsign
https://github.com/frehberg/wasm-sign
proxy-wasm/proxy-wasm-cpp-host#147
wasm-signatures/design#1

[lukewagner]

In case folks are interested and not subscribed to the new repo, there's also a discussion of some of the motivation for having a wasm standard in wasm-signatures/#6.

[tiziano88]

In general I believe the signatures should be detached, rather than embedded in the Wasm file (or any other format) itself.

1. That way it is possible to create a signature for an existing Wasm module (possibly published by someone else), without having to re-distribute the entire module.

2. Allow multiple parties to actually sign it, potentially at different times (e.g. someone publishes a binary, then some other party publishes a signature to confirm that it passes some audit, or an automated tool may generate a proof / attestation of some property of the binary). Multiple signatures for the same module may be circulated and distributed more easily as detached files.

3. Another advantage of detached signatures is that they do not affect the cryptographic integrity of the original Wasm file; if its hash was logged somewhere -- sigstore? --, an embedded signature would modify the overall binary, and therefore its hash, because of the addition of a signature section; unless a specialised hash function is used that knows how to ignore it. The presence of one or more signatures should not affect the cryptographic identity of a module.

4. It is simply not scalable to invent a new embedded signature format for every new format. 🙂

[tiziano88]

embedded signatures could allow implementations to validate and make decisions before instantiating the module and allow signatures irrespective of the delivery module (OCI image, etc)

I think any delivery system these days would support multiple files, so it seems plausible to expect that a Wasm module comes with zero or more signatures, and the instantiator of the module would verify them before actually running the module. In fact this is probably even more practical than embedded signature, since the verification (which usually relies on some policies, e.g. whose signatures to accept) does not need to happen inside the Wasm interpreter itself, since it may be verified by a binary / library that does not need to be specialised to parse Wasm modules at all, and may be reused for validating signatures on any sort of files.

[jedisct1]

Looks like embedded signatures makes is more convenient for some applications, and detached signatures makes more sense for others.

Both are not incompatible. Some of the proposed formats store the signatures in a single custom section. Instead of that custom section, the exact same content can be provided separately.

Ultimately, this is more about API design. Verification and signature functions can take an optional signature file as a parameter, an empty parameter meaning that the data is embedded. Existing signatures can trivially be detached and reattached if needed.

In this context, maybe we should make the fact that the signatures must be stored in a single section a requirement.

[rossberg]

I share some of @tiziano88's sentiment. How a module is signed, what structure signatures have, how they are associated, how they are validated, may differ significantly between eco systems. So while it probably makes sense to develop a format for a signature custom section, I'd be a bit more sceptical if the expectation was to define the format of such a section with the intention of a universal mechanism.

[asraa]

since it may be verified by a binary / library that does not need to be specialised to parse Wasm modules at all, and may be reused for validating signatures on any sort of files.

I think this first with the most minimal use case of singing and verifying a whole module itself. The only time that doesn't fit is when distributors may want to sign parts of a module that aren't required, e.g. additional custom sections.

So while it probably makes sense to develop a format for a signature custom section, I'd be a bit more sceptical if the expectation was to define the format of such a section with the intention of a universal mechanism.

I think that's the intention. Like @jedisct1 detached and attached can be implemented with the same mechanism. Defining a format that can be compatible with these applications rather than the format which is likely not going to be applicable in all use cases.

Another advantage of detached signatures is that they do not affect the cryptographic integrity of the original Wasm file; if its hash was logged somewhere -- sigstore? --, an embedded signature would modify the overall binary, and therefore its hash, because of the addition of a signature section; unless a specialised hash function is used that knows how to ignore it. The presence of one or more signatures should not affect the cryptographic identity of a module.

In cases where you need a reference by hash for lookup it would make sense to have the detached model. But otherwise I don't see much of a concern. If you have an emmbedded signature, your verifier would know how to parse the signature out and would also then know how to hash to ignore out.

Maybe in summary I'm less concerned about attached/detached, and more interested in whether a signature format can cover things that may happen in Wasm specific use-cases that make it different than signing any "blob". Can signatures cover optional custom sections? Can users optionally trust those? But those may be too complicated right now.

[andrejusc]

How about introducing manifest definition into module to suite this proposal? If some provider/producer is capable to fill it - then it could be parsed/verified on the hosting side. As if WASM module is the unit of deployment - that then should be self-consistent to guarantee it's own integrity. And if that is not present within module - then some parametrization on host side could introduce then detached signatures handling.

Not sure where discussion stands at the moment as last comment was almost 2 years ago. But seeing more and more usage of WASM technology these days - this proposal I think is important to implement in some common way.

[dtig]

This was discussed at one of the previous meetings, and there was some interest in finding/documenting a common solution. More about that can be found in this document. However, I'm not aware of the current status, or the usage of the digital signature format that is documented.

[jedisct1]

There's a full implementation of this proposal (both a CLI and a library): https://github.com/wasm-signatures/wasmsign2

I heard the Wasmedge folks are also working on adding support for it.

[andrejusc]

@jedisct1 - thank you for pointer on one of current implementations, wasn't aware it's up to date. But obviously support within Wasmedge would be great as well.

[jedisct1]

wasmsign2 has multiple implementations that can be useful as reference code.

In particular, the simple one verifies the entire module. It's a subset of what the format supports, but can be enough for your needs, and is very easy to implement.