Workload (WASM binary) loading - connection termination

[MikeCamel]

Once a Keep is prepped, with microkernel, WASM runtime, etc., the workload (WASM binary) needs to be loaded into it. There are three ways this could be managed: which is our plan?

1. Enarx client agent encrypts workload, sends to CPU/firmware via Enarx host agent. CPU/firmware decrypts workload, loads into Keep. This has the advantage that we use an existing network connection, and there's no need to establish a connection nor a session key between the Keep and the client agent.
2. Enarx client agent encrypts workload, sends to Keep via a listening agent within the Keep. Keep decrypts, loads and runs. This requires a route to be available between the Keep and the client agent. (2a. It would be possible to have the Keep call out to the client agent, but this is quite a different model.)
3. Enarx client agent encrypts workload, sends to host agent. Host agent sends to Keep via a listening agent in the Keep. Keep decrypts, loads and runs. This maintains the host agent's status as a proxy between other components, and doesn't make further assumptions about routing which is made by 2. (3a. As with 2a, Keep could call out to the host agent).

[steveej]

Thanks for writing this issue up so far.

I think the implementation effort for the network connections is not the primary aspect to evaluate here.
Much more I'd like to understand the security implications for the various options, as well as the compatibility with the use-case of having an orchestrator, which might be a middle-man between the client-agent and the host to which the workload will be deployed after the client has submitted the workload.
I'm noticing that my understanding of the PKI that we rely on for this project is still vague to me, so please point me to educating references where appropriate.

It seems that the biggest difference is the use of no session key in option 1, where the workload is directly encrypted towards the CPU/firmware of the chosen host system. Could any host which has the same CPU/firmware type which the client agent encrypted the workload for later decrypt the workload? This would be a risk if the encrypted workload is captured and could later be decrypted when the CPU/firmware suffers from a security breach. This risk could be avoided by using a session key.

[MikeCamel]

... use-case of having an orchestrator, which might be a middle-man between the client-agent and the host to which the workload will be deployed after the client has submitted the workload.

We're clear that the orchestrator should never be a middle-man. Any integration with the orchestrator should have the Enarx client agent being provided with workload, data, config, etc. by the orchestrator, and the client agent managing all communications with host agent.

It seems that the biggest difference is the use of no session key in option 1, where the workload is directly encrypted towards the CPU/firmware of the chosen host system. Could any host which has the same CPU/firmware type which the client agent encrypted the workload for later decrypt the workload?

There is always a session key constructed as part of the attestation step, and it's always unique to that TEE instance and therefore that Keep instance. This means that even Keeps on the same host will have different session keys. The SEV demo, for instance, shows perfect forward secrecy (PFS).

[steveej]

I'm pretty sure I have a different understanding of what the orchestrator and the client agent are and do in the Enarx architecture.

Is the client agent the CLI tool which is run by the tenant interactively, or is it a long-running Keep which acts on behalf of the tenant?

[MikeCamel]

If you look here, you'll find a set of slides. The slides in the section "Process Flow" give an indication of the various components.

The Enarx client agent may be a daemon or a library (tbd), and is trusted by the tenant. Assuming that you're running it on a trusted machine, there's no need for it to be in a Keep (though that's possible, with appropriate boot-strapping). You may have a CLI or an orchestrator (Openshift, Openstack, etc.) talking to it.

[steveej]

there's no need for it to be in a Keep (though that's possible, with appropriate boot-strapping). You may have a CLI or an orchestrator (Openshift, Openstack, etc.) talking to it.

The boot-strapping case you mention is part of what I was wondering about. The other part is the fact that we'll probably have a CLI which is for controlling the orchestrator.

[MikeCamel]

@npmccallum notes:
a) 1 is not plausible for architectures
b) another benefit to 2 is that you can cache workloads if you encrypt them under a separate workload key. There's a trade-off here: you don't have one-off encyrption (Perfect Forward Secrecy) for each instance.

[MikeCamel]

The tenant should always be the party to decide whether caching is turned on. Not all instances need to support caching.

[MikeCamel]

Written up as rfc draft. Under review: #2

[MikeCamel]

Move to rfcs project?

[axelsimon]

Indeed, moving this issue.