hyperledger
Deterministic (de-randomized) state encryption & randomness
To enable multi-enclave endorsement, state encryption should be deterministic (so we can handle multi-enclave endorsement policies) yet should still provide semantic security which implies randomized encryption. Additionally, we should be careful with bounds on numbers of encryption per key where in our case an enclave might be easily used as a fast "encryption-oracle".
Additionally, solving above also should enable a secure way to provide chaincode access to (pseudo-)random values, something which is generally very difficult to achieve in "normal" smart contracts but unlocks additional smart contract functionalities.
On a high-level, the approach is to derive a key from the contract master key and then derive a transaction-encryption-randomness seed from that key using a PRF with the complete transaction context (state, inputs) as input. This seed can the be taken to seed a PRNG which generates the randomness (e.g., IV for AES-GCM) during the state encryption. This assumes that the actual chaincode (and the shim) is deterministic (which is anyway a requirement). This approach should ensure that randomness should be identical for a repeated execution of the same transaction/state yet is (cryptographically) independent for different transactions. Additionally, the randomness should be completely unpredictable, even for insiders.
There are though some challenges with above to address/think through:
-
it is paramount that not only encryption state but also inputs are considered when computing the PRF. One challenge related to this are sub-transactions as they might(?) potentially run on different states and hence returned results might make the computation deviate with different plaintext being encrypted with the same randomness. In the case of AES-GCM this might completely break the integrity and might also break confidentiality (as it would leak leak relations of plaintexts between the different code-paths).
-
If the chaincode itself (or the shim) is not deterministic, a similar confidentiality issue arises. Using AES-GCM-SIV might mitigate that to some extent (e.g., leakage of equality would seem worst case confidentiality breach). AES-GCM-SIV might also improve to some extent the "fast-encryption-oracle" issue, although maybe additional levels of key-diversification might be useful to go beyond the (not-so-hard-to-reach) 2^32 encryptions bound with AES-GCM but that needs further investigation. A special case of non-determinism might be early abort/failures which still result in a valid return message. One simple way to to handle that is to treat randomness needs for response via a separate PRNG from the PRNG used to do state encryption, both seeded via (differently tweaked) PRF based on the same master secret derived on input and state?
-
Another challenge is on how to characterize state. A natural thought would be to use the block-id of the last processed block. While this would be secure, it very likely leads to false conflicts as peers might be at different last blocks even though they would have agreed on the state of the chaincode. One way to address this is to keep track in tlcc for each namespace the last block where changes happened and use this as reference. Alternatively is to first encrypt with some ephemeral local key, at the end of the transaction use the read/write-set (keys & versions thereof) as the state indicator as input (in addition to the transaction inputs) to the seed-generating PRF and then re-encrypt the changes for "public digestion". This should handle sub-transactions/cc2cc and accidental non-deterministic chaincode securely but obviously requires more work and also would not allow to offer randomness to the chaincode itself.
Above approach should also work directly to expose randomness to the application (important, though, that the user-level transaction-encryption-randomness seed is independent from the state-encryption version thereof, implying an additional level of key-derivation or tweaking the PRF.
Relevant prior work:
- Duan and Haibin, Practical State Machine Replication with Confidentiality, SRDS2016, https://doi.org/10.1109/SRDS.2016.031
- Cachin, Schubert and Vukolic, Non-determinism in Byzantine Fault-Tolerant Replication, OPODIS'16, https://doi.org/10.4230/LIPIcs.OPODIS.2016.24 & https://arxiv.org/abs/1603.07351 (more complete TR version)
- AES-GCM-SIV:
- Bose et al, Revisiting AES-GCM-SIV: Multi-user Security, Faster Key Derivation, and Better Bounds, EuroCrypt'18, https://eprint.iacr.org/2018/136
- Iwata et al, Reconsidering the Security Bound of AES-GCM-SIV, EPrint 2017/708, https://eprint.iacr.org/2017/708
- Gueron et al, AES-GCM-SIV: Specification and Analysis, EPrint 2017/168, http://eprint.iacr.org/2017/168
- Rogaway and Thomas Shrimpton, Deterministic Authenticated-Encryption: A Provable-Security Treatment of the Key-Wrap Problem, EuroCrypt'16, http://web.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf