Fabric Private Chaincode

Enhancing Chaincode Privacy with Intel^® SGX

Marcus Brandenburger (IBM Research - Zurich), Michael Steiner (Intel Labs), Bruno Vavala (Intel Labs)

Hyperledger Fabric Maintainer Meeting�

github.com/hyperledger-labs/fabric-private-chaincode

Outline

Part 1 �Motivation and Overview

Part 3�Recap & Outlook

Part 2�Integration in Hyperledger^® Fabric�(build, lifecycle, tx validation, ...)

Blockchains everywhere ...

• Blockchain is good for verifiability
• What about confidentiality?

Impact on privacy-sensitive applications

​

Sealed Auctions

Genome Analytics

e-Voting

Supply Chain

Need bid secrecy

Need ballot secrecy

Need genome secrecy

Need contract secrecy

Impact on privacy-sensitive applications

​

Built-in privacy mechanisms�of Hyperledger^® Fabric

• Channels
• Transient Fields
• Private Data Collections

Sealed Auctions

Genome Analytics

e-Voting

Supply Chain

Need bid secrecy

Need ballot secrecy

Need genome secrecy

Need contract secrecy

Impact on privacy-sensitive applications

​

Built-in privacy mechanisms�of Hyperledger^® Fabric

• Channels
• Transient Fields
• Private Data Collections

Sealed Auctions

Genome Analytics

e-Voting

Supply Chain

Need bid secrecy

Need ballot secrecy

Need genome secrecy

Need contract secrecy

Problem: �Data visibility at endorsing peers (and respective organizations)

Fabric Private Chaincode (FPC)

• A framework for Private Chaincode
• Enables blockchain applications with strong privacy requirements
• Executes chaincode securely using Intel^® SGX
• Protects secrets inside chaincode and on ledger�
• Hyperledger community project
• Contributors IBM, Intel Labs, TUBS, Uni Bern, ...�

Source code and examples available on Github�github.com/hyperledger-labs/fabric-private-chaincode

Trusted Execution Environment (TEE)

• Hardware-based TEEs offer
• Confidentiality of app code / data
• Execution integrity
• Remote attestation / verification
• TEEs can protect arbitrary apps
• TEEs (e.g., SGX) are available
• New trust model
• No trust in platform hosting the TEE
• Including VMM, OS, apps and admins
• Trust the in hardware TEE
• Trust in hardware-TEE manufacturer

​

Hardware

VMM

App

OS

SGX Enclave

Hyperledger^® Fabric

Peer

chaincode

ledger

Orderer

Orderer

Orderer

validation

Peer

chaincode

ledger

validation

Peer

chaincode

ledger

validation

1. invoke

2. endorsements

3. tx submission

4. ordered tx broadcast

5. commit

Hyperledger^® Fabric with SGX

Peer

chaincode

ledger

Orderer

Orderer

Orderer

validation

Peer

chaincode

ledger

validation

Peer

chaincode

ledger

validation

1. invoke

2. endorsements

3. tx submission

4. ordered tx broadcast

5. commit

SGX enclave

SGX enclave

SGX enclave

Enclave code identified by MRENCLAVE

Each enclave has a unique identity

FPC - Endorsement

Orderer

Orderer

(unmodified)

ordered transactions�(with attested endorsements)

(unmodified)

endorsements on attested encrypted data

Orderer

(unmodified)

invoke/response with�encrypted & authenticated�payload

ledger

update�ledger

attestation validation

FPC - Ledger Validation

Orderer

Orderer

Orderer

ledger

Problems with unprotected ledger:

• Ledger controlled by peer
• Enclave cannot check�if data is committed

FPC - Ledger Validation

Orderer

Orderer

Orderer

ledger

SGX enclave

trusted ledger

• Establishes a trusted view of the ledger (via tx validation)
• Keeps only concise ledger representation

FPC - Programming the Chaincode

SGX enclave

Private Chaincode (e.g., sealed auctions, etc.)

void invoke(...);

shim.h

void get_state(...);

void put_state(...);

void get_state_by_partial_composite_key(...);

void get_creator_name(...);

void log_*(...);

...

​

​

Enclave shim library

void de/encrypt_state(...);

void decrypt(...);

void verify_state(...);

void create_attestation(...);

...

​

​

​

attestation, state encryption, ...

“Normal” Fabric Programming Model (prototype in C/C++)

All “Magic” transparent in shim library

FPC Layer

void encrypt_tx_args(...);

void verify_attest(...);

App

Fabric Client SDK

Secure client-enclave channel

What FPC achieves (and what are the cost)

Risk Management: No need for unlimited trust in enclaves ...

• Accountability
• All involved enclaves must be registered on ledger, all transactions are traceable
• Trust but Verify
• If you trust TEEs, a single endorsement is sufficient (unusual for Hyperledger Fabric)
• However, you can require different TEE endorsement to have independent verification
• Potentially even based on different TEE technologies (Uni Bern is looking at ARM TZ)
• Informed Risk
• We can keep track value-at-risk exposed to different TEEs
• Enables bounding aggregated risk and limiting incentives of attack on TEE platform!
• Challenges
• Dealing with potential key exposure
• Affects primarily confidentiality, not necessarily integrity
• Dealing with outdated platform’s TCB
• Periodic re-validation and allow (policy-based) upgrades

Outline

Part 1 �Motivation and Overview

Part 3�Recap & Outlook

Part 2�Integration in Fabric�(build, lifecycle, tx validation, ...)

Origin of Challenges: 1 Peer for 2 Entities

SGX enclave

chaincode

shim

1

Different keys

Origin of Challenges: 1 Peer for 2 Entities

SGX enclave

chaincode

shim

1

2

Enclave awareness for clients

Different keys

Origin of Challenges: 1 Peer for 2 Entities

Peer

Peer

SGX enclave

chaincode

shim

1

2

3

Enclave awareness for clients

Enclave awareness for peers

Different keys

Origin of Challenges: 1 Peer for 2 Entities

Peer

Peer

SGX enclave

chaincode

shim

1

2

3

4

Enclave awareness for clients

Enclave awareness for peers

Mutually untrusted entities

Different keys

Origin of Challenges: 1 Peer for 2 Entities

Peer

Peer

SGX enclave

chaincode

shim

1

2

5

3

4

Enclave awareness for clients

Exposed hardware capabilities

Enclave awareness for peers

Mutually untrusted entities

Different keys

Touchpoints with �Fabric Core Architecture

Touchpoints with �Fabric Core Architecture

New trusted channel components:

• Trusted Ledger (TLCC)
• Enclave Registry (ERCC)

Different endorsement (generation &) validation

New Runtime environment

Touchpoint: Additional Meta-Data

Objective

• Agreement across orgs on security-critical data on ledger
• E.g., Intel^® IAS certificates, MRENCLAVEs
• Explicit operation

Initial Approach

• Hardcoded in binaries

25

Limitations

• No configuration/upgrade of security-critical metadata at runtime

​

Going Forward ..

• Use Configtxgen and approveForMyOrg
• already involve explicit agreement
• Explore:
• Add new Config* protobufs for configtxgen.
• Exploit init() with arguments for approveForMyOrg & commit!

​

Touchpoints with �Fabric Core Architecture

Additional metadata in

• Channel definition
• Chaincode definition

​

New trusted channel components:

• Trusted Ledger (TLCC)
• Enclave Registry (ERCC)

Different endorsement (generation &) validation

Touchpoint: Runtime ..

Objective

• Creating an SGX-enabled runtime for FPC chaincode

Initial Approach

• Runtime (ECC) via wrapper Go-chaincode
• Interacts with enclaves
• Controls enclave lifecycle (with ERCC)
• Run is new SGX-enabled container
• Peer CLI wrapper
• Hides enclave specific operations (e.g. TLCC ledger join, docker override, …)

​

27

Limitations

• Low compatibility of wrapper approach with Fabric build & lifecycle mgmt
• External enclave compilation
• Chaincode docker image override�(hacky)
• Enclave management (create, attestation) through chaincode invocation�

Touchpoint: Runtime ..

Going Forward ..

�Need “proper” chaincode type

• Stub/shim
• Instance & Runtime Management (Build, Deploy & Run)

​

• Stub: Straightforward ...
• Duplicate/steal from golang shim, API well defined with protobufs …
• Instance & Runtime Management (2 options)
• platforms interface�+ Stable & Simple�- Requires (minimal) changes in fabric core (platform registration, docker invocation with additional devices/paths for sgx & proxy-support)
• Externalbuilders�+ no fabric core changes (but: type-list in ChaincodeSpec protobuf? Other places, e.g., MSP?)�- WIP, (too) loosely coupled for underlying deployment model (e.g., docker -> kubernetes)

​

28

Touchpoints with �Fabric Core Architecture

Additional metadata in

• Channel definition
• Chaincode definition

​

Different endorsement (generation &) validation

New Runtime environment

Touchpoint: Trusted Ledger Validation

Objective

• Making an oracle which knows what data is committed

Initial Approach

• Duplicate peer’s validation mechanism inside enclave

Limitation

• Inefficient code and execution redundancy
• Sync issue ledger-trusted-ledger

Going Forward

• Modular validation mechanism (Go, C++)

Touchpoints with �Fabric Core Architecture

Additional metadata in

• Channel definition
• Chaincode definition

​

New trusted channel components:

• Trusted Ledger (TLCC)
• Enclave Registry (ERCC)

New Runtime environment

Touchpoint: Attestation-based Endorsements

Objective

• Use attested signatures for transaction endorsements
• Making attested endorsements compatible with “standard” org endorsements for lifecycle events

Initial Approach

• Enclave attests input, output, read/writeset
• Endorsement & Validation plugins
• Read enclave signature from response payload
• Check ERCC for registered enclave
• Validate enclave response signature

​

32

Limitations

• Every peer needs to run custom validation plugin
• Enclave signature is part of the response payload (somewhat hacky)

​

​

​

Touchpoint: Attestation-based Endorsements

Going Forward:

​

Leverage MSP

​

• Add a new Enclave MSP type
• MSP validation treats enclaves as members of an organization
• Replace peer's endorsing signature with "enclave signature" (using endorsement plugin)
• Validation based on enclave registry on ledger
• Context-sensitive endorsement policy evaluation
• Only enclaves running the expected chaincode are allowed to endorse
• Possibly based on endorsement policy explicitly listing code identity (MRENCLAVE)
• Advantages
• No custom validation plugin at the peers
• Solid foundation for using other TEE technologies than SGX
• Thanks to Angelo for his feedback on MSP

​

33

Outline

Part 1 �Motivation and Overview

Part 3�Recap & Outlook

Part 2�Integration in Fabric�(build, lifecycle, tx validation, ...)

Takeaways

Limited privacy features prevent several applications

FPC closes the gap, enabling privacy-sensitive apps

Several challenges are being addressed,also engaging with Fabric Maintainers

Hyperledger^®�Fabric

Fabric Private Chaincode - Roadmap

36

TODAY

�Goal:�make FPC ready for Fabric inclusion

Disclaimers

• These materials are provided as-is, with no express or implied warranties.
• All products, dates, and figures specified are preliminary, based on current expectations, and are subject to change without notice.
• Technology features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No product or component can be absolutely secure. Check with your system manufacturer or retailer.
• Intel is a trademark of Intel Corporation in the United States and other countries.
• *Other names and brands may be claimed as the property of others.

Thanks

https://github.com/hyperledger-labs/fabric-private-chaincode

​

https://chat.hyperledger.org/channel/private-data-objects

​

Tuesdays 3pm GMT�https://wiki.hyperledger.org/display/HYP/Calendar+of+Public+Meetings

Happy to have follow-up discussions

backup

Touchpoint: Client-side processing

Task

• Retrieve correct FPC CC PK and encrypt/decrypt interaction with FPC enclaves iff FPC CC.

​

Initial Approach

• Hmm, punted on this task for now …😳

40

Challenges

• Should be work transparently with all client-side SDKs

Going Forward ..

• Initial investigations seem to point to gateway as best integration point ...

removed/skipped

Talk’s Protocol

We

You

give FPC overview

highlight integration challenges with Fabric

provide feedback for improving design & implementation

​

highlight additional requirements

Privacy in Hyperledger Fabric

Fabric's built-in privacy mechanisms

• Channels
• Peers and Orderers see data
• Transient Fields
• Only endorsing peers see data (assuming chaincode encrypts state)
• Private Data Collections
• Only collection (Peer) members see data (assuming use of transient fields)

​

​

Problem: �Data visibility at endorsing peers (and respective organizations)

Impact on privacy-sensitive applications

​

Sealed Auctions

Genome Analytics

e-Voting

Supply Chain

Need bid secrecy

Need ballot secrecy

Need genome secrecy

Need contract secrecy

Fabric does not meet�the app requirements

Impact on privacy-sensitive applications

Sealed Auctions

Genome Analytics

e-Voting

Supply Chain

Need bid secrecy

Need ballot secrecy

Need genome secrecy

Need contract secrecy

Fabric does not meet�the app requirements

FPC-enabled Fabric�does!

FPC - Overview

Orderer

Orderer

Orderer

1. invoke

3. tx submission

4. ordered tx broadcast

5. commit

Peer

tx validation

SGX enclave

chaincode

shim

SGX enclave

enclave-tx validation

ledger

2. attested� endorsements

Peer

tx validation

SGX enclave

chaincode

shim

SGX enclave

enclave-tx validation

ledger

Peer

tx validation

SGX enclave

chaincode

shim

SGX enclave

enclave-tx validation

ledger

FPC - Ledger Validation

Orderer

Orderer

read committed� (encrypted) ledger data

Orderer

FPC - Programming

Orderer

Orderer

Orderer

piece of code that

• interfaces enclave with the (untrusted part of the) peer
• implements enclave management (e.g., attestation, encrypted storage)
• interfaces with trusted ledger

Risk Management

• Resource Discovery, Informed Risk, Accountability
• Managed through the ledger
• Enclave registry (user) chaincode maintains chaincode information, enclave (public) keys, Enclave-peer binding data
• Identity and Key management
• Agree or update enclave identities (i.e., code)
• Update chaincode and state encryption keys
• Risk Management
• Dealing with outdated platform’s TCB
• Dealing with potential key exposure
• Keeping track & bound value-at-risk exposed to different TEEs / reputation-mgmt of enclaves ...
• ​

What FPC achieves (and what’s the cost)

FPC - Threat Model

Trusted

• Client
• On authentication
• Chaincode enclave
• Hardware TEE
• Agreed-upon implementation
• Ledger enclave
• Hardware TEE
• Agreed-upon implementation

​

Untrusted

• Peer
• Can tamper with ledger data
• Can tamper with private data
• Orderer
• Can tamper with tx data
• Organization
• Can tamper with certificates

​

Crucial:�

• “Agreed-upon” implies consensus among organizations/peers (e.g., on genesis block, or chaincode definition, or configuration transactions).
• “Agreed-upon” components inherit their trustworthiness from the group (e.g., organizations, or peers, or endorsers) who made the decision

FPC - Threat Model

• Client
• Unmodified invoke
• Looks up enclave on registry
• Encrypts invoke parameters, decrypts response data
• Chaincode Enclave
• Unmodified ledger I/O
• Encrypts/decrypts state on ledger
• Checks committed data with trusted ledger
• Peer
• Handles encrypted ledger data
• Unmodified chaincode interface
• Orderer
• Unmodified
• Handles transactions w/ encrypted data in r/w set

Interestingly:�FPC enhances privacy even with a single-endorsement policy

Touchpoint: Additional Meta-Data

Objective

• Crucial information to bootstrap security (e.g., Intel IAS PK, code-identities (MRENCLAVE) of TLCC and FPC CC) have to be securely bound to ledger.
• Binding requires explicit mutual agreement of the involved organizations.

​

Initial Approach

• Hardcoded in binaries

53

Challenges

• Should be runtime configurable & upgradeable

​

Going Forward ..

• explicit org agreement through Configtxgen and approveForMyOrg
• Q: how extend?
• configtxgen already based on extensible Config* protobufs: just add our own ...
• init() with arguments for chaincode definition? No --ctor equivalent from instantiate in approveForMyOrg & commit!
• How does init work in new lifecycle?

Endorsement and validation

• (TO BE merged with 33?)

Initial Approach

• Using custom validation plugin
• Read enclave signature from response payload
• Check ERCC that the enclave is registered
• "good" attestation report
• "expected" MRENCLAVE
• Validate proposal response (read/writeset, ...) using enclave signature
• Challenges
• Every peer needs to run custom validation plugin
• Enclave signature is part of the response payload (somewhat hacky)

Custom VSCC

Takeaways

Limited privacy features prevent several applications

Several challenges (integration, risk management) are being addressed,also engaging with Fabric Maintainers

FPC closes the gap, enabling privacy-sensitive apps

SGX-enable container

trusted ledger

E2E secure implementation

new channel definition

Fabric 2.0

certified enclaves