Distribution of pre-compiled Wasm modules

[tiziano88]

One of the main features of Oak is to allow declassification by nodes that have a WebAssembly logic that is trusted by the owner of the data. For instance, a client may want to specify, via the label / IFC system, that a piece of data can be declassified by a particular Wasm node that aggregates or anonymizes the data before releasing it or further processing it.

In practice this is done by labelling the data with the principal corresponding to that specific node (e.g. the actual hash of the Wasm module, or a key belonging to an entity that is trusted to sign a family of nodes with the desired functionality, or some other schemes involving verifiable logs).

Ideally, an (untrusted) developer of an Oak Application would reuse pieces of logic that implement declassification functionality that have been written / verified by other parties that are more trusted by actual clients / users. For this, we should clarify how a developer would go about including pre-built (and potentially also signed) Wasm modules in a larger Oak Application.

cc @project-oak/core

[tiziano88]

Thinking some more about this:

• we need a way for "trusted" module authors to publish their compiled Wasm modules (e.g. aggregation, redaction, etc.), and ideally show provenance from some Rust source code via a reproducible build
• we need a way for third party application developers to use "trusted" modules as part of their (generally untrusted) application

My current thinking is that there should be a mechanism in the app config serializer to specify that a particular module is to be downloaded from a URL, and checked against a provided hash.

For instance, in the aggregator example, we should have a step that builds the Wasm node from sources and publishes that on Google Cloud Store, or as a GitHub release artifact (I think we need to split the aggregator logic from the part of the application that actually creates the gRPC node etc, cc @ipetr0v ). We already have hashes generated for all the Wasm modules. Then as part of the overall application, we would build the untrusted part of the application locally (does not even need to be reproducibly buildable), and reuse the pre-compiled aggregation logic (which is the one that actually uses its declassification privilege in IFC) by downloading it from from where it is published.

[seefeldb]

FYI, https://github.com/WICG/webpackage might be useful prior art for distributing signed content on the web as files (see signed http exchange). It would also be a way to bundle resources with a module.

[tiziano88]

Thanks @seefeldb , from a quick look that seems aimed at preserving TLS-like signatures in content that was saved offline, but I'll follow the various links and try to understand it better, it may be that it helps with something in Oak.

In terms of the original discussion, I think it could be separated into the following orthogonal issues:

• as the author of a reusable wasm module, I want to publish the compiled wasm bytecode of the module
  • ideally also show provenance from some source code
  • at a minimum, upload the bytecode (anywhere, even on an untrusted storage system), and publish its hash on a trusted platform (e.g. github, verifiable log, etc.)
  • optionally / alternatively sign the module itself with a key whose public counterpart may be used as principal in IFC labels in Oak (any code signed with key XYZ)
• as the reviewer of reusable wasm modules, I want to publish the result of my reviews
  • perhaps something like Ent or https://github.com/crev-dev/cargo-crev may help here
• as the developer of an Oak application, I want to find and use wasm modules as part of my application
  • in particular, writing an untrusted application, I want to use a piece of trusted logic for a declassification step
• as the user of an Oak application, I want to map high level concepts (e.g. "aggregation", "redaction", etc..) to something that can be enforced by my devices when using untrusted apps
  • behind the scenes, this assumes the existence of a web of trust of some sort, which connects end users to expert reviewers, and maps english statements to hashes of Wasm modules (essentially Ent)

[seefeldb]

Yes, it's just a way to sign one or more files with a TLS key, reusing that infrastructure. Would apply to what authors and reviewers do. I imagine there are other standards for signing files with a key that we could look at.

Would be nice to leverage existing public key infrastructure (letsencrypt.org is doing a lot of useful stuff, though of course depends on domains).

Either way, we should have binary transparency for modules and reviews.

[tiziano88]

I think @benlaurie mentioned https://github.com/FiloSottile/age for signing / encryption at some point, though from a quick look I cannot figure out how to actually use it for signing only (@benlaurie do you know how?)

[tiziano88]

A few pointers that were discussed in a team meeting earlier today:

• https://webassembly.org/docs/dynamic-linking/
• https://docs.wasmer.io/ecosystem/wapm/manifest
• Should we use ELF as a container format? WebAssembly/design#74
• https://github.com/WebAssembly/tool-conventions/blob/master/Linking.md
• “Introducing wax: a WebAssembly package runner” by Syrus Akbary https://link.medium.com/PWKFn3D3y7

[ipetr0v]

I think as a first step we could rewrite the Config Serializer in Rust (#740), and add the ability to download Wasm modules from Google Cloud Storage.

[tiziano88]

I agree porting the config serializer should be the first step.

I don't think we should limit it to download from google cloud though.

I would suggest coming up with a manifest file (TOML or protobuf) for applications that describes where to get the various modules (locally or URLs, specify their names, hashes, any other details about the application). Then use this instead of the partially filled-in text protobuf version of the application configuration.

[ipetr0v]

If we will implement and add hashed to example .toml files, we also probably need a script that updates them, once examples have been changed.

[tiziano88]

One of the reasons for having the manifest for the application is that the compiled modules will be dowloaded instead of built locally, so I am not sure how such a script would possibly work. But sure, if you can think of any reasonable way of automating that, it would be great!

[ipetr0v]

Currently saving compiled Wasm modules in Google Storage in a bucket called oak-modules as:

• Directories named after modules
• Files in these directories named as sha256sum

hello_world/
    e658111a1de72d79ea6b1832e3b4a0af27f6fe3b9c2f121d040ae6109db15e7f  
translator/
    ea7628b0b3158c94b36601609c65fa7c68eeea817760f5097c53bab652821e2d

[ipetr0v]

Should this issue be closed after #1232 or we need a different mechanism for module distribution?

[tiziano88]

I don't think we need a different mechanism, but also I don't think the current mechanism is sufficiently documented that a developer would actually know how to publish a Wasm module if they wanted to.