side-channel limits: keymanager should emit usage statistics even if it does not implement rate limiting policy itself

What is the problem that you're trying to solve?

Our TEE transaction system should make it expensive to mount transaction replays that would make TEE-based compute nodes use key material in a way that exploit side channels at a high bandwidth.

Logging at (or, more realistically, before entry to this TEE code):

https://github.com/oasislabs/ekiden/blob/4d88a8b2bb803e5137e682698530ff47de00e2ed/keymanager-runtime/src/methods.rs#L20

Describe the solution you'd like

The TEE-based compute nodes should make replays expensive for the adversary without making confidential contract context switches too expensive -- maybe ensure that there is freshness in obtaining key material from the key manager (it should already be over TLS so replays should not be feasible), possibly not caching keys so that the key manager is aware of every new subcontract call; keeping a cache of recent transaction IDs to prevent replay without doing a full enclave process restart, assuming creating transactions is somewhat expensive; etc. The key manager should in turn generate logging entries -- but beware of quantity, so logging storage won't be DOS'able -- so that we can implement anomaly detection / alarms and do firewall/sentry-node based blocking even if we haven't implemented policy enforcement within the key manager.

Are the node key used to sign the keymanager requests in addition to the SGX side key? IIRC SGX signatures are still group sigs and does not allow us to identify the actual node making the request (though the key manager will have the IP).

Have a slashing policy that severely punishes such key extraction attempts. Must ensure that the likelihood of false positives -- perhaps due to a node restarting and getting network replays? -- is extremely low.

Describe alternatives you've considered

• Enforce a minimum context switch / contract start-up delay in TEE-based compute code. Potential bad impact on net throughput.
• Reduce side channel bandwidth by doing (bogus/useless) crypto operations to taint / reduce the bandwidth of d-cache based side channels. Wastes cycles. Need to have concrete estimates of costs vs bandwidth reduction.
• Wait for Intel to release a better SGX. Let users bear the risk since existence of sidechannels is widely known at this point. As long as we enable TEE subtype selection, contract authors ok with using current SGX TEEs can proceed, and future users can require the use of a future SGX TEE subtype.

Additional context

Start with keymanager-runtime/src/methods.rs at line 20, where logging before TEE entry is identified, and trace the key-material request path from there. Define the required usage statistics, replay or freshness behavior, node identity, and bounded logging behavior; done means an agreed implementable design, since the issue names no test or concrete change.