Toward Evaluation of Privacy and Confidentiality in Hyperledger Platforms

Toward Evaluation of Privacy and Confidentiality in Hyperledger Platforms
https://www.meetup.com/Hyperledger-Seattle-Chapter/events/264855643/

The talk was recorded and all being well the video should be posted on the Hyperledger YouTube channel within a month. https://www.youtube.com/channel/UC7_X0WkMtkWzaVUKF-PRBNQ/videos

Transcript

1. Toward the Evaluation of Privacy and Confidentiality in Hyperledger Platforms Architecture Working Group - P&C track. Copy of paper (draft) pdf http://bit.ly/2OWTlrG Presented by Clive Boulton @iC
2. This talk... • How the Arch-WG P&C track went about developing the goals for the paper • The methods for analysis • The commonly used technologies • And the ever evolving Evaluation of P&C in Hyperledger platforms
3. Not this talk... What are the differences between Hyperledger and other blockchain technologies? Watch this quick video of @brianbehlendorf who breaks it down: https://youtu.be/hXBoYxMlB58
4. Toward Business Federation … Centralized Web to Decentralized Web. - IPFS meetup in Tokyo.
5. Why a culture clash threatens Tesla/ Panasonic battery relationship CEO Elon Musk’s behavior has rattled some top executives at Panasonic, and both sides are pointing fingers about production - WSJ https://www.wsj.com/articles/tesla-needs-its-bat tery-maker-a-culture-clash-threatens-their-relati onship-11570550526
6. Evaluation for Healthcare Flow of information ...
7. Is P&C relevant on Permissioned Blockchain? Sybil attacks on DLTs Identity based blockchain - spin up multiple identities. Are we vulnerable? Make spinning up identities a little bit difficult. Biometrics.
8. Introduction and Goals The target audience for this paper is a general technical audience. Specifically, we expect it to be read by people familiar with the implementation details of blockchain technologies, but our readers need not be familiar with methods for creating and analyzing cryptographic proofs. https://docs.google.com/document/d/1lemA53PyC4HqDmpnsRdGZFeA5mpcoJ34dJiBG6T3g-0/edit#heading=h.eqr047yyqo2
9. Definitions For the purposes of this paper, we are concerned about the protection of information and enforcement of acceptable policies for WHO has access to WHAT information about blockchain transactions, and WHEN they have that access. Owners of information should be able to control who has access to the information, for what period of time. https://docs.google.com/document/d/1lemA53PyC4HqDmpnsRdGZFeA5mpcoJ34dJiBG6T3g-0/edit#
10. Confidentiality for the Paranoid Side channels represent a second, and far less obvious, form of exposing confidential information. For example, Bitcoin uses addresses for transactions which, in theory, provide anonymity for transactors. However, correlation between transactions on an address and activity in an exchange often enable disclosure of the actual identity of the address owner. Even systems designed for confidential transactions can expose information through side channels [[add citation about zcash, https://arxiv.org/pdf/1805.03180.pdf]]. https://docs.google.com/document/d/1lemA53PyC4HqDmpnsRdGZFeA5mpcoJ34dJiBG6T3g-0/edit#heading=h.37z7309v0j op
11. Section Summary It is nearly impossible to prevent all information leakage in any Internet-based computation. Our intent in this paper is to provide the reader with some tools for evaluating what information is leaked and how to balance the cost of prevention versus the cost of leakage.
12. Use Case Deep Dive: Supply Chain Factoring Current practice places all control of data under “a single organization” but with blockchain-based solutions this data is potentially shared (or will be unless managed well). [Tesla/Panasonic battery production a case in point] https://docs.google.com/document/d/1lemA53PyC4HqDmpnsRdGZFeA5mpcoJ34 dJiBG6T3g-0/edit#heading=h.acpustd782df
13. Functional Requirements Particular usage suggest several general functional requirements for privacy and confidentiality: • Participants have the ability to keep data about the transaction confidential (entitlement to data access control rights). This may include the ability to hide the existence of the objects like the contract. • Participants have the ability to choose when and with whom to disclose data. • Participants have the ability to selectively disclose parts of the data with chosen parties. • The right to disclose information is transferred with ownership transfer.
14. Side channel issues How can somebody steal my information
15. Method for Analysis The factor/supplier usage described in the previous section shows the potential complexity of information access policies for even relatively simple usages. Adhoc methods for evaluating the preservation of confidentiality provided by a specific blockchain platform often lead to incomplete or ineffective analysis. We would like to propose a more formal method for evaluating whether a given blockchain platform meets the functional requirements for a usage. Our proposal consists of a formal definition of an adversarial models and a method for explicitly capturing a functional requirement using a cryptographic “game”. https://docs.google.com/document/d/1lemA53PyC4HqDmpnsRdGZFeA5mpcoJ34 dJiBG6T3g-0/edit#heading=h.6vt5h5agxsa2
16. Reference System Model It can be very difficult to properly analyze privacy and confidentiality in a rigorous way due to the complexity of blockchain systems. Proving properties of blockchain systems in settings that involve real-world things like continuous time and outside influences can be extremely difficult or outright impossible. So, one popular way to analyze the privacy and confidentiality properties of distributed ledgers is to consider a reference system model. In this context, a reference system model is a construct used for analysis and is NOT intended to be a practical system. [We introduce the simpler “ideal” system”] https://docs.google.com/document/d/1lemA53PyC4HqDmpnsRdGZFeA5mpcoJ34dJiBG6T3g-0/edit#
17. The “Ideal” Solution To make the concept more concrete, we can use the bulletin board to model an “ideal” solution for the supply-chain factoring use-case that was described previously. We can imagine a solution that works as follows: when a user sends an (encrypted) message to the bulletin board, the bulletin board posts it and makes it available to all participants in an encrypted form. The bulletin board is also responsible for ordering the messages as they come in.
18. Commonly Used Technologies Segmented Ledgers Zero Knowledge Proofs Trusted Hardware Multi-party Computation and Homomorphic/Functional Encryption Decentralized, Off-Chain Storage
19. Segmentation Encrypted data? Unencrypted data? See data going by … Different projects handle segmentation differently.
20. Managing on-chain state The job of each Hyperledger Platform
21. Hyperledger Besu process Conceptually enclave setup secure Transfer keys to enclave Know Allis and Bob sent 10,000 transactions Special addresses (changing the address) Watch the private enclave Everyone in the privacy group has access to information (H2 20…) Sender sends the private payload. As of version 1.2 only support networks that support finality (no PoW).
22. Toward the Evaluation of Privacy and Confidentiality in Hyperledger Platforms Architecture Working Group - P&C track. Copy of paper (draft) pdf http://bit.ly/2OWTlrG Presented by Clive Boulton @iC