Sealed Storage for ECC

[g2flyer]

Description

To allow ecc restarts (e.g., due to peer restart, #282, or just ecc external builder getting terminated by peer and restarted), ecc will eventually require to store enclave and cc secrets to sealed storage.

• API definition
  • presumably we can do that as only local library calls with all ecalls/ocalls behind the scenes?
• implementation of API as libraries
  • will need a trusted and an untrusted component, although likely only one of them will have public interfaces which are called from other call, the other side just implements ecalls/ocalls called from the "other" side of the library ...
• Integrate library into ECC

Link to feature or bug

Link to dependent issues

[g2flyer]

See PR #420 and #405 for some discussion on sealed storage ...

[mbrandenburger]

// Provided/implemented by a common sealed storage module
void ocall_load(
        [in, string] const char *str, 
        [out, size=max_data_len] uint8_t *data, uint32_t max_data_len
        [out] uint32_t *data_len);

void ocall_store(
        [in, string] const char *str, 
        [in, size=data_len] uint8_t *data, uint32_t data_len);

[g2flyer]

Presumably, above EDL would, though, be a module-internal API? Or put differently, i suggest the public API used by the rest of ECC would be a (trusted) c functions along the lines of

int seal_and store_state(ECC_State state)
int retrieve_and_unseal_state(ECC_State *state)

with ECC_State with a struct (maybe protobuf?) of whatever we want to have sealed (see also #420) and the second function allowing to distinguish via return code whether simply nothing was sealed or there was a processing error.

The API/module itself then would then implemented by two libraries -- one in enclave, the other one outside --, connected via above EDL?