Wasm module signature label

[tiziano88]

One of the ways that Oak allows for delegation is in the choice of declassification modules.

Currently it is possible to label data with a label referring to the hash of an individual Wasm module with the following:

oak/oak/proto/label.proto

Lines 58 to 65 in 1b3b4b2

	// Policies related to modules, referring to the native WebAssembly node within the TCB.
	message WebAssemblyModuleTag {
	// The attestation for a single WebAssembly module, a SHA256 digest of the module in binary
	// format.
	// TODO(#630): Replace this with identity assertions for multiple module
	// versions, based on a public verifiable log.
	bytes web_assembly_module_hash_sha_256 = 1;
	}

But in many cases it is not possible or desirable to enumerate the list of allowed Wasm modules upfront at label creation time. Oak should provide a way of specifying a family of Wasm modules.

This proposal is to allow cryptographic signatures of Wasm module to be used as labels.

A possible implementation would add a tag such as:

message WebAssemblyModuleSignature {
  bytes public_key = 1;
}

in which the public key may be a minisign key: https://jedisct1.github.io/minisign/ or some other public key suitable for signing arbitrary data.

Any Wasm module signed with the provided key would be granted the privilege to declassify tags referring to that key.

Key distribution and discovery is a separate problem, i.e. it needs to happen out-of-band. How keys are published and obtained (and also revoked) is out of scope for this issue, but should probably be investigated more closely in a separate issue at some point once we have a better idea.

[ipetr0v]

What if we need the data to be processed by two nodes A and B, signed by the same party?

What would the label look like if we will not use exact module hashes?

If it will look like google_public_key ∧ google_public_key, then it will just merge into google_public_key, and it will be possible for Oak to release the data without processing it by the node B.

[ipetr0v]

I think the label should also include the name of the module:

message WebAssemblyModuleSignature {
  string name = 1;
  bytes public_key = 2;
}

[tiziano88]

What if we need the data to be processed by two nodes A and B, signed by the same party?

What would the label look like if we will not use exact module hashes?

If it will look like google_public_key ∧ google_public_key, then it will just merge into google_public_key, and it will be possible for Oak to release the data without processing it by the node B.

That should be the same as having only one module signed by that party? I don't think there is an intuitive meaning of "needs to be declassified by two arbitrary modules signed by google.com, but really not just one, there must be exactly two of them"?

[ipetr0v]

It could be just two different modules that serve different purpose.
For example, a third-party developer wants to use already existing Google modules, and he will not be able to ask Google to merge these two modules into a single one.

[tiziano88]

I think the label should also include the name of the module:

message WebAssemblyModuleSignature {
  string name = 1;
  bytes public_key = 2;
}

I initially thought that too, but now I think it's simpler to just assume that whoever is doing the signing, would just derive separate signing keys for different names, via a key derivation function from a master key, or by generating distinct keys for distinct "names".

[tiziano88]

It could be just two different modules that serve different purpose.
For example, a third-party developer wants to use already existing Google modules, and he will not be able to ask Google to merge these two modules into a single one.

if they serve different purposes, probably they have different "names", right? in which case, either:

• the keys will be different: google_public_key_A ∧ google_public_key_B, or
• the labels should include the actual name: google_public_key:A ∧ google_public_key:B

[ipetr0v]

Is :A a name from the string name = 1; ?
Or it is some kind of label metadata?

[tiziano88]

yes it would be the name, of course we are just using an informal, made-up textual representation of actual protobuf objects in this discussion, but the two should be isomorphic.

[ipetr0v]

Also, since we will probably use minisign to sign module during the build phase, should we install minisign outside Docker too?
Or inside Docker is enough, since we can reproducibly build only inside Docker for now #865?

[ipetr0v]

Based on the following discussion https://project-oak.slack.com/archives/CHE9E13C3/p1596545541005600?thread_ts=1596538417.497200&cid=CHE9E13C3

Parties involved: developer, maintainer, CA and client.

The workflow could look like this:

• Developer asks the CA to sign his public key
• Developer writes down an Oak module code and compiles it into a Wasm module
• Developer signs Wasm module's hash (possibility of hasing multiple hash functions, signature types and file types)
• Developer packs Wasm module, signature and a public key into an Oak configuration file
• Maintainer ships the file into the server and runs oak_loader
• oak_runtime checks signatures
• Client sends a message labeled with the module's public key

[ipetr0v]

Possible workflow from the point of view of the maintainer (organization/person who runs already written and packed Oak applications):

The maintainer:

• Downloads app.bin (which is basically a protobuf file with Oak modules compiled by the application developer)
• Downloads public keys and signatures that correspond to Oak modules packed into the app.bin
• Runs oak_loader --app=app.bin --sign=./signature_directory

The disadvantage of this approach is that the maintainer will need to know which modules are in the app.bin in order to separately download their signatures.

[ipetr0v]

In order to clearer understand how it is better to implement signature checking and specification, here is a life cycle overview of an Oak application: from development to deployment.

Platforms used in Oak life cycle:

• Deployment server
  • Runs Oak applications on trusted hardware
• Application store
  • Stores separate Oak modules (module.wasm files) and compiled Oak applications (app.oak files)
• Review platform
  • Provides a service for Oak modules reviewing

In reality the Application store and the Review platform could be merged into a single platform for convenience.

The parties involved are:

• Application developer
  • Organization who writes an Oak application
• Third party module developer
  • Another organization who develops and publishes Oak modules to be used by the Application developer
• Reviewer
• Maintainer
  • Organization who deploys Oak applications on the Deployment server
• Client

The life cycle:

• Application developer:
  • Writes an Oak application (possibly using third-party Oak modules published on the Application store)
  • Publishes the application and first party modules used in it on the Application store
  • Publishes a review request on the Review platform for first party modules used in the Oap application
• Reviewer
  • Uses the Review platform to write reviews for Oak modules
  • Signs Oak modules (signatures and Reviewer's public keys are stored on the Review platform)
• Maintainer
  • Downloads an Oak application (app.oak file) from the Application store
  • Downloads module signatures/keys corresponding to modules inside the app.oak from the Review platform
    • In order to achieve this the Application store should have a link to the Review platform where Maintainer can download all signatures for a specific Oak applications
    • Review platform can also pack signatures into a single binary file sign.bin
  • Deploys Oak applications on the Deployment server by running ./oak_loader --app=app.oak --sign=sign.bin
• Client
  • Looks into the Review platform and chooses which Oak modules he can trust
  • Downloads Reviewer's public keys from the Review platform
  • Assigns corresponding labels (modules hashes and public keys) to the data and sends it to an Oak application deployed on the Deployment server

cc @project-oak/core

[tiziano88]

Thanks, I think this looks much more realistic!

A few notes:

• I don't think the client looks at the review platform, and even if they did, they would not look at the modules; the whole point of having the signatures is that they just need to trust the reviewer (otherwise they would just use the wasm hashes directly, right?)
  • I think for now we can assume that the client figures out the public key of the trusted reviewers in some out-of-band way
• I don't think it's realistic to assume that the maintainer does all the work to figure out the modules of an application, and pulling out the signatures for them; instead, the oak_loader is pointed to the review platform directly and downloads both keys and signatures from there for the modules that are part of the application
  • for now we can simulate this with a single file / folder / database that contains all the signatures for any module in any application
• I suspect the more common flow is that the app developer uses already reviewed modules, not that they would write the modules and wait for the reviews to happen (that may take a while / forever!)