hyperledger
Sealed Storage for ECC
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
// 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);
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?