What is the role of Provision Service?
zlonqi opened this issue · 5 comments
PS looks like an intermediate service that provides encryption key generation and management. I am not sure how many keys it will provide. At least I know that there are Enclave encryption keys, contract signing keys, and contract state keys. . can you help me? Thank you so much~
The PSs are meant to decentralize the generation of the state encryption key. You can find an explanation in this paper.
Each contract that is registered on the ledger is associated with a set of PSs. Each PS produces a key share for that contract. The contract enclave in the eservice combines these key shares to extract the state encryption key.
thanks. I've read the paper, but I have some new confusion.
The contract enclave in the eservice combines these key shares to extract the state encryption key.
But In the paper, It says:
It means which don't need all key shares to combines to extract the state encryption key?
I circled it with a red frame on it.
The two encryption keys look different. The first is like an asymmetric key, and the second is like a symmetric encryption key used to contract state encryption, Why do we need first key pair?
contract state is a private data of PDO, Can I ask you to give an example? and will it store on DL with contract? thank you so much~ @bvavala
- It means which don't need all key shares to combines to extract the state encryption key?
No.
It means that the state encryption key will be random provided that at least one PS is honest.
This immediately follows from the construction of the secret, which is currently an XOR of the key shares.
Also, in the current implementation, all of the key shares are necessary to rebuild the secret.
- The two encryption keys look different. The first is like an asymmetric key, and the second is like a symmetric encryption key used to contract state encryption
Correct.
Why do we need first key pair?
The public encryption key is necessary to send encrypted (confidential) data to the contract enclave, for example: the key shares in the provisioning protocol; or the clients' requests in usual PDO usages.
- contract state is a private data of PDO, Can I ask you to give an example?
The contract state could be used for instance to: maintain the balance of an account; or store a set of receipts; or append personal confidential data. In all these cases, the contract would keep some local state, and the enclave would keep it confidential and integrity protected through the state encryption key.
and will it store on DL with contract?
Only the hash of the state, not the state itself.
The transaction processor on the ledger will commit the state hash only if it comes from the right enclave, and if it extends correctly the state transition chain.
Sorry I still don't understand this.
in the current implementation, all of the key shares are necessary to rebuild the secret.
I thought of the following example.
When the contract was first registered, It got the state encryption key K from P1-P3, which is equal to k1^k2^k3. When I need to use K next time, I need to get shares from P1-P3, then rebuild K. But if P2 is not honest, then K is not the one before.
Is there still another possibility that K will be registered insecurely on the ledger.
thank you for your patience.
When the contract was first registered, It got the state encryption key K from P1-P3
This is not accurate. It's the contract enclave (which will run the contract) which gets K.
You can see this from the protobufs of the contract registry.
A contract is associated with a set of PSs
An enclave (already registered in the ledger -- see the enclave registry) is then "added" to the contract -- meaning that it gets provisioned and will be able to run the contract.
In this step, the enclave generates a transaction over the PSs and the (encrypted) state encryption key that it recovered.
When I need to use K next time, I need to get shares from P1-P3
It's important to specify in what enclave you want to use it.
As mentioned above, if the enclave has already been added to the contract, the encrypted K (for that specific enclave!) is already available on the ledger. So anybody can grab it.
However, if the enclave has not yet been added to the contract, then you're correct. It has to go through the provisioning step.
But if P2 is not honest, then K is not the one before.
Correct, this is a limitation of the current implementation. This could be addressed with a more robust key sharing scheme that can tolerate bad PSs. Also, it would be desirable to make PSs commit to the key shares they provide (this is already the case), and to keep them accountable in the case of misbehavior.
Anyway, ideas and contributions on this aspect are more than welcome!
Is there still another possibility that K will be registered insecurely on the ledger.
Not sure what you mean here.