As noted in https://github.com/oasisprotocol/oasis-core/pull/5715#discussion_r1627576520 we should add support for "arbitrary application secret storage" where anyone can request derived key shares and the hash of the policy is part of the key derivation (e.g. changing the policy changes the derived keys).
In this case, the request for a share contains two arguments, a policy and proof. Both are CBOR documents and H(policy) is used as part of the key identifier. The proof is validated against the policy and if it passes, the key share is released.
A possible policy component would be one that requires a merkle proof for a specific path under a given runtime's state or IO root, enclave identity, etc. The policy could also say that the share is released encrypted in a specific way based on the data from the proof (e.g. the structure of the key-value pair that is proven using a merkle proof contains a public key used to encrypt the share to).
One problem with this design is how to address denial of service attacks. If a policy can be validated rather quickly then this is less of an issue.
As noted in https://github.com/oasisprotocol/oasis-core/pull/5715#discussion_r1627576520 we should add support for "arbitrary application secret storage" where anyone can request derived key shares and the hash of the policy is part of the key derivation (e.g. changing the policy changes the derived keys).
In this case, the request for a share contains two arguments, a policy and proof. Both are CBOR documents and
H(policy)is used as part of the key identifier. The proof is validated against the policy and if it passes, the key share is released.A possible policy component would be one that requires a merkle proof for a specific path under a given runtime's state or IO root, enclave identity, etc. The policy could also say that the share is released encrypted in a specific way based on the data from the proof (e.g. the structure of the key-value pair that is proven using a merkle proof contains a public key used to encrypt the share to).
One problem with this design is how to address denial of service attacks. If a policy can be validated rather quickly then this is less of an issue.