You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As noted in #5715 (comment) 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.
The text was updated successfully, but these errors were encountered:
As noted in #5715 (comment) 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.
The text was updated successfully, but these errors were encountered: