Accountability in a Permissioned Blockchain: Formal Analysis of Hyperledger Fabric
Authors: Ralf Kusters, Daniel Rausch, Mike Simon (Institute of Information Security University of Stuttgart)
Accountability as a stand-alone property
Accountabilty can be considered as a stand-alone property from other security properties.
(i) Accountability might already be achievable with weaker but more efficient components compared to what is needed for strict goals. (e.g. CFT instead of BFT)
(ii) In order to fulfill accountability properties one might need less assumptions.
(iii) Accountability properties might be stronger in some aspects than strict security notions
Accountability as an additional, orthogonal layer of defense
accountability can be used as an additional security requirement and another security layer on top of strict notions. Even in the strict setting, security can still be broken because the underlying assumptions, such as an honest majority, might not be fulfilled.
Levels of accountability
there are different levels of accountability (and hence levels of security) that a blockchain can provide. To be sufficient for practical purposes, it should be possible to hold at least one individual party accountable for misbehavior, a property called individual accountability.
Analyzing accountability for blockchains
analyzing accountability for blockchains is based on a generic accountability framework from Kusters et al. A key task for instantiating this framework for the analysis of blockchains is to formalize appropriate security goals, for which parties can be held accountability if they are violated. Case study: Hyperledger Fabric
Analyzing Fabric within the above mentioned framework involves instantiating the framework by carrying out the following main tasks:
(i) build an appropriate system model, including a model of corruption,
(ii) formalize the security goals to be achieved, including, among others, consistency,
(iii) specify who is to be blamed if a security goal is violated, including a procedure for how to identify misbehaving parties, and (iv) use the resulting instantiation of the accountability framework to formally analyze accountability
Fabric using Kafka provides a certain weak level of accountability with respect to the most crucial security goal of blockchains:
consistency. That is, if blockchains of different parties are inconsistent, one can blame a set of parties with the guarantee that at least of one of them misbehaved. However, that level of accountability, as already argued above, it insufficient for practice.
the paper will propose small modifications to Fabric with Kafka and show that this slightly modified version, which we call Fabric*, indeed achieves individual accountability w.r.t. consistency. We also prove that Fabric* achieves accountability w.r.t. further security goals from the literature
the paper emphasize that we do not propose that accountability should replace strict security notions. On the contrary, as mentioned, it is highly desirable to have blockchains fulfilling both strict security notions and accountability, as these are orthogonal and complement each other. But in some cases, such as typical deployments of permissioned blockchains, accountability when used as a stand-alone security property can offer an alternative approach to strict security notions with several advantages.
Security Goals of Blockchains
consistency: the chains of honest participants share a common prefix
chain-quality: the percentage of blocks of a chain that were created by malicious miners is upper bounded
chain-growth: over time, a blockchain continues to grow.
liveness: transactions cast by honest clients will eventually be included in the blockchain