in hyperledger fabric

1. Blockchain and Trusted Computing:
Problems, Pitfalls, and
a Solution for Hyperledger Fabric
Marcus Brandenburger, Christian Cachin, Alessandro Sorniotti (IBM
Research - Zurich)
Rüdiger Kapitza (TU Braunschweig)
Presented by Yongrae Jo, System software lab. at POSTECH

2. https://blog.theabacus.io/the-verge-hack-explained-7942f63a3017

3. No detailed description
about how to prevent
rollback attack!!

4. 4
1 2 3 4 Smart contract
enclave
5 6 7 8
5’
Unique, committed state input
Not unique, committed state input
PoW-Blockchain
GetState(k)

5. 5
Strawman design
: High TCB size
This sentence seems to exclude an attack by adversary;
“providing valid, but old state”
1 2 3 4 Smart contract
enclave
5 6 7 8
5’
Unique, committed state input, but old state?
Not unique, committed state input
PoW-Blockchain
GetState(k)

6. 6
In a trusted way? How?
Especially, OS’s attack of offering valid, but old state to smart contract enclave?

7. 7
Threat Model
●
Considered
– Adversary fully controls OS / Application
– Memory / Persistent storage (Blockchain state)
– “incorrect” input or order
●
Not considered
– DDOS(Message dropping, Completely halting an enclave)
– SGX’s non-volatile monotonic counter; may prevent
rollback attack but, slow / complicated
●
Trusted ordering service
Feeding old state; Replay attack

8. 8
Consensus with Non-fianl Decisions
●
Bitcoin-like public blockchains do not reach consensus
with finality
●
Significant probability that a node has to revert
transactions during regular operation
●
Problem: Rollback is possible by design
– non-final consensus protocols may fork temporarily

9. 9
Peer B’s view
Peer A’s view
will be stale blocks

10. 10
TEE + Blockchain with PoW
TEE + Blockchain with finality-guaranteed
consensus
Bad: Rollback by protocol design
Good: No rollback by protocol design
(Hyperledger/Fabric)

11. 11
A Solution for Hyperledger/Fabirc
●
Hyperledger/Fabric offers finality-guaranteed
consensus
– Execute-Order-Validate protocol
– Eliminate rollback by protocol design
●
But, rollback is still possible from using TEEs
●
Two approaches
– Strawman design
– Better design than strawman

12. 12
Strawman design
●
Idea: Put the whole peer into TEE
●
Problems
– Violating the principle of minimizing the size of the
trusted computing base
●
Small TCB: less {error / attack surface}, easy to security
analysis
– Limited memory available to enclave
●
Enclave memory resides in EPC (Enclave Page Cache)
●
EPC’ size < 128M
Or put the whole OS into TEE?

13. 13
Preventing rollback attack in
Order-Execute Architecture
●
Prevents rollback attack by protocol design
●
Chaincode enclave executes a transaction only once
after the transaction is totally ordered
– tx. with seq. # n is uniquely executed during run time if tx
with seq. # n-1 is already executed
– Seq. # is kept in volatile memory (variable)
●
Even though malicious OS reboot the chaincode enclave
or providing old-state, chaincode enclave executes the tx
which is uniquely identified by seq #. in monotonically
increasing and deterministic way
●
(e.g.) TrInc, MinBFT, Hybster, ...

14. 14
Rollback attack in
Execute-Order-Validate Architecture
●
Speculative execution
– (rollback) Executing the transaction before consensus
– (confidentiality) Malicious peer/client can infer a secret
of application by executing any transaction in any order
(e.g. auction) (+ Lottery)
Any tx
in any order
OS’s cut
Infer
a secret

15. 15
Preventing rollback attack in
Execute-Order-Validate Architecture
●
Solution: Introducing barrier
– Adapt the applications to respect the speculative nature
of execution in Fabric
– Enforce the relative ordering of some chaincode ops.
(e.g. “close” before “evaluation” in auction)
– Set by invoking the chaincode with a specific transaction
http://www.albahari.com/threading/part4.aspx
“evaluation” ops
are blocked
Set after “close” op.
Similar to a memory
barrier in a multi-
core computer
system
●
submit
●
close
●
evaluate

16. 16
Secure chaincode execution
●
System architecture
●
System initialization(static consortium config.)
●
Chaincode enclave bootstrapping (admin-driven init.)
●
Chaincode execution

17. 17
System Architecture
: Extending existing peer
Newly added
components
Compoents
in SGX Enclave
Maintains a list of all existing
chaincode enclaves
●
Maintains the ledger of integrity-specific metadata representing the most
recent blockchain state
●
Performs block validation

18. 18
Chaincode Execution (1)
1) Request enclave’s
public key PKCC
and attestation
from Enclave Registry

19. 19
Chaincode Execution (2)
2) Verify attestation using
IAS verificationkey
(Intel Attestation Key)

20. 20
Chaincode Execution (3~4)
3) Encrypts the chaincode operation using PKCC .
4) Send the proposal to chaincode enclave
(op, args)

21. 21
Chaincode Execution (5)
(op, args)
5) Chaincode library decrypts the proposal using SKCC
and Invokes the chaincode with the operation as
argument.

22. 22
Chaincode Execution (6)
(op, args)
6) Chaincode processes the operation,
produces a result, and
returns it to the chaincode library

23. 23
Chaincode Execution (7)
7) Chaincode library creates a response
signed by SKCC
, returns it to the client through
the peer

24. 24
Chaincode Execution (7)
●
Read set
●
Write set
●
Execution result
7) Chaincode library creates a response
signed by SKCC
, returns it to the client through
the peer
Response
optionally encrypted
by a key provided by client

25. 25
Chaincode Execution (8~9)
: Validation and state update
●
Read set
●
Write set
●
Execution result
Response
8) Client broadcasts the
responses to Ordering
Service
9) Ordering service
creates a new block and
broadcasts to all peers

26. 26
Chaincode Execution (10)
: Validation and state update
10) Enclave tx. Validator verifies
the block (VSCC steps)
●
Conflicts
●
Endorsement Policy
●
Authenticity (valid
chaincode enclave)

27. 27
Chaincode Execution (11)
: Validation and state update
11) Peer commits the block(tx) to
local ledger and update
blockchain state accordingly

28. 28
Accessing the blockchain state (1)
State integrity and consistency
(op,
args)
z: nonce

29. 29
Accessing the blockchain state (2) :
State confidentiality
●
Mode 1. Client-based encryption
– Client is responsible for key management
– Client must provide an encryption key together with each
chaincode operation
●
Mode 2. Encryption per chaincode
– chaincode-specific key must be provisioned by an admin
to all chaincode enclaves during bootstrapping
●
Encryption / Decryption occurs during putState and
getState calls

30. 30
Experimental setup
●
1 ordering service, 1 channel, 3 peers
●
Run on a separate machine
– Supermicro 5019-MR server
– 3.4GHzfour-coreE3-1230 V5 IntelCPU
– 32 GB memory
– 1 Gbps network
– SSD
●
Fabric Client SDK for Go
●
128-bit AES-GCM encryption

31. 31
Measuring
●
TCB
– 5,000 lines of trusted C/C++ code
●
Chaincode enclave (1200)
●
Ledger enclave (3800)
– 4,000 lines of untrusted C/C++ and Go code
●
Other peer main components
●
Endorsement throughput
●
End-to-end throughput
Entire Linux kernel: > 2,500,000 lines
Whole Fabric peer: 100,000 lines

32. 32
Evaluation
: Endorsement throughput
receives a bid,
encrypts it, and stores
it on the blockchain

33. 33
Evaluation
: End-to-end throughput

34. 34
Related works
●
Smart-contract execution with Intel SGX
– Cocoframework, The R3 Corda
– (suggested); Ring of Gyges, Hawk
●
Blockchain oracles and off-chain data
– Teechain
●
Consensus protocol
– TrInc, CheapBFT, Hybster, REM, Hyperledger/Sawtooth
●
State continuity and TEEs
– State continuity for memoryless secure processors
– Detecting rollback attacks
Oracles are data feeds external to the
blockchain that inform a smart contract
about “facts” in the environment.

35. 35
Thanks
Any questions?

36. 36
https://hyperledger-fabric.readthedocs.io/en/release-1.2/gossip.html
Gossip protocol in Fabric Peer

37. 37
My Guess
●
Gossip protocol and endorsement policy

38. 38
Where the rollback comes from?
1. Not using non-volatile monotonic counter
2.Using (rollback by design) PoW based Blockchain
3.Speculative execution protocol ( execute-order-
validate)

39. 39
Barrier in detail
●
By adding a barrier into the blockchain, an application
essentially benefits from the guarantees of the order-
execute design with respect to rollbacks across the
barrier
●
Requiring a barrier after every transaction would
actually impose the order-execute paradigm onto
Fabric.

40. 40
Chaincode enclave bootstrapping