The Usability, Security, and Privacy Limits of Blockchain J I B E . - - PowerPoint PPT Presentation

▶
the usability security and privacy limits of blockchain
SMART_READER_LITE
LIVE PREVIEW

The Usability, Security, and Privacy Limits of Blockchain J I B E . - - PowerPoint PPT Presentation

Jun 05, 2023 276 likes •1.73k views

The Usability, Security, and Privacy Limits of Blockchain J I B E . C O M P A N Y Codiax 2019 Hello! Im Joris van Rooij Software Architect at Jibe.Company From Eindhoven, the Netherlands J I B E . C O M P A N Y I like...

slide-1
SLIDE 1

J I B E . C O M P A N Y

The Usability, Security, and Privacy Limits of Blockchain

Codiax 2019

slide-2
SLIDE 2

J I B E . C O M P A N Y

Hello!

➔ I’m Joris van Rooij ➔ Software Architect at Jibe.Company ➔ From Eindhoven, the Netherlands I like... Free Software I’m all about... Digital Rights My pet peeves are... Operational / Information Security

slide-3
SLIDE 3

J I B E . C O M P A N Y

Our goals

➔ Get to know what “blockchain” actually means ➔ Find out what its strengths are ➔ Uncover its weaknesses ➔ Learn when its application is appropriate

slide-4
SLIDE 4

J I B E . C O M P A N Y

DISCLAIMER TIME

slide-5
SLIDE 5

J I B E . C O M P A N Y

Our Agenda

1. Blockchain 101 2. Introducing PoSeID-on 3. Blockchain in PoSeID-on 4. Blockchain applicability

slide-6
SLIDE 6

J I B E . C O M P A N Y

Blockchain 101

slide-7
SLIDE 7

J I B E . C O M P A N Y

Quick High-Level Overview

slide-8
SLIDE 8

J I B E . C O M P A N Y

Distributed Systems

slide-9
SLIDE 9

J I B E . C O M P A N Y

Distributed System

A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another.

slide-10
SLIDE 10

J I B E . C O M P A N Y

Distributed System

A working distributed system is a state machine, distributed across a network on multiple machines, with consensus about the state.

slide-11
SLIDE 11

J I B E . C O M P A N Y

State Transition Function

slide-12
SLIDE 12

J I B E . C O M P A N Y

Distributed System

1 1 1 1 1 1

slide-13
SLIDE 13

J I B E . C O M P A N Y

Approach: Full Mesh Broadcast

1 1 1 1 1 1

slide-14
SLIDE 14

J I B E . C O M P A N Y

Approach: Full Mesh Broadcast

1 1 1 2 1 1

slide-15
SLIDE 15

J I B E . C O M P A N Y

Approach: Full Mesh Broadcast

2 2 2 2 2 2

slide-16
SLIDE 16

J I B E . C O M P A N Y

Approach: Full Mesh Broadcast

Every computer has a direct connection to every other computer

slide-17
SLIDE 17

J I B E . C O M P A N Y

Approach: Full Mesh Broadcast

That won’t scale very well

slide-18
SLIDE 18

J I B E . C O M P A N Y

Approach: Partial Mesh Broadcast

1 1 1 1 1 1

slide-19
SLIDE 19

J I B E . C O M P A N Y

Approach: Partial Mesh Broadcast

1 1 1 2 1 1

slide-20
SLIDE 20

J I B E . C O M P A N Y

Approach: Partial Mesh Broadcast

1 2 2 2 1 2

slide-21
SLIDE 21

J I B E . C O M P A N Y

Approach: Partial Mesh Broadcast

2 2 2 2 2 2

slide-22
SLIDE 22

J I B E . C O M P A N Y

Approach: Partial Mesh Broadcast

It’s better, but...

slide-23
SLIDE 23

J I B E . C O M P A N Y

Node Failures

Computers are not connected all the time

slide-24
SLIDE 24

J I B E . C O M P A N Y

Node Failures

➔ Network interference ➔ Hardware failure ➔ Software failure ➔ Your mom unplugging your computer ...etc

slide-25
SLIDE 25

J I B E . C O M P A N Y

Remember these?

00:00 -!- Netsplit a.irc.net <-> b.irc.net quits: usera, userb, userc 00:00 -!- Netsplit over, joins: usera, userb, userc

slide-26
SLIDE 26

J I B E . C O M P A N Y

Node Failures

1 1 1 1 1

slide-27
SLIDE 27

J I B E . C O M P A N Y

Node Failures

1 1 1 2 1

slide-28
SLIDE 28

J I B E . C O M P A N Y

Node Failures

1 2 2 2 1

slide-29
SLIDE 29

J I B E . C O M P A N Y

Node Failures

2 2 2 2 1

slide-30
SLIDE 30

J I B E . C O M P A N Y

Node Failures

2 2 2 2 1 1

slide-31
SLIDE 31

J I B E . C O M P A N Y

Node Failures

This is not fault tolerant

slide-32
SLIDE 32

J I B E . C O M P A N Y

Approach: Transaction Log

We need sequential transactions; a log

slide-33
SLIDE 33

J I B E . C O M P A N Y

Approach: Transaction Log

Step 1: set value to 1 Step 2: set value to 2 Step 3: set value to 42

slide-34
SLIDE 34

J I B E . C O M P A N Y

Approach: Transaction Log

2:2 2:2 2:2 2:2 1:1 1:1

slide-35
SLIDE 35

J I B E . C O M P A N Y

Approach: Transaction Log

2:2 2:2 2:2 2:2 1:1 1:1

slide-36
SLIDE 36

J I B E . C O M P A N Y

Approach: Transaction Log

2:2 2:2 2:2 2:2 2:2 2:2

slide-37
SLIDE 37

J I B E . C O M P A N Y

Approach: Transaction Log

It’s better, but...

slide-38
SLIDE 38

J I B E . C O M P A N Y

Approach: Transaction Log

1:1 1:1 1:1 1:1 1:1 1:1

slide-39
SLIDE 39

J I B E . C O M P A N Y

Approach: Transaction Log

1:1 1:1 1:1 1:1 1:1

slide-40
SLIDE 40

J I B E . C O M P A N Y

Approach: Transaction Log

1:1 1:1 1:1 2:2 2:3

slide-41
SLIDE 41

J I B E . C O M P A N Y

Approach: Transaction Log

1:1 2:2 2:2 2:2 2:3

slide-42
SLIDE 42

J I B E . C O M P A N Y

Approach: Transaction Log

2:2 2:2 2:2 2:2 2:3

slide-43
SLIDE 43

J I B E . C O M P A N Y

Approach: Transaction Log

2:2 2:2 2:2 2:2 2:3 ?

slide-44
SLIDE 44

J I B E . C O M P A N Y

Approach: Transaction Log

Step 1: set value to 1 Step 2: set value to 2 Step 2: set value to 3

slide-45
SLIDE 45

J I B E . C O M P A N Y

Approach: Master Node

Introduce a master with the final say in the order and validity of transactions

slide-46
SLIDE 46

J I B E . C O M P A N Y

Approach: Master Node

Step 1: set value to 1 Step 2: set value to 2 Step 2: set value to 3

slide-47
SLIDE 47

J I B E . C O M P A N Y

Approach: Master Node

Who gets to be master?

slide-48
SLIDE 48

J I B E . C O M P A N Y

Approach: Master Node

1:1 1:1 1:1 1:1 1:1 1:1

slide-49
SLIDE 49

J I B E . C O M P A N Y

Approach: Master Node

1:1 1:1 1:1 1:1 1:1 1:1

slide-50
SLIDE 50

J I B E . C O M P A N Y

Approach: Master Node

1:1 1:1 1:1 1:1 1:1 1:1

slide-51
SLIDE 51

J I B E . C O M P A N Y

Approach: Master Node

1:1 1:1 1:1 1:1 1:1 1:1

slide-52
SLIDE 52

J I B E . C O M P A N Y

Recap

➔ Partial mesh broadcast ➔ Transaction log ➔ Master node

slide-53
SLIDE 53

J I B E . C O M P A N Y

Recap

It’s better, but...

slide-54
SLIDE 54

J I B E . C O M P A N Y

Recap

Everybody has to play by the rules

slide-55
SLIDE 55

J I B E . C O M P A N Y

Crash Fault Tolerance

We have only achieved crash fault tolerance

slide-56
SLIDE 56

J I B E . C O M P A N Y

Crash Fault Tolerance

This consensus algorithm is CFT

slide-57
SLIDE 57

J I B E . C O M P A N Y

Crash Fault Tolerance

➔ Paxos (1989) ➔ Raft (2013)

slide-58
SLIDE 58

J I B E . C O M P A N Y

Byzantine Fault Tolerance

What if not everybody plays by the rules?

slide-59
SLIDE 59

J I B E . C O M P A N Y

Byzantine Fault Tolerance

➔ We can’t trust all messages we receive ➔ We can’t trust all other nodes ➔ We still want to reach consensus ➔ We still want to remain crash fault tolerant

slide-60
SLIDE 60

J I B E . C O M P A N Y

Blockchain

slide-61
SLIDE 61

J I B E . C O M P A N Y

Blockchain

Let’s focus on Bitcoin for now

slide-62
SLIDE 62

J I B E . C O M P A N Y

Blockchain

Bitcoin is a byzantine fault tolerant distributed state machine

slide-63
SLIDE 63

J I B E . C O M P A N Y

Blockchain

Bitcoin’s consensus algorithm is BFT

slide-64
SLIDE 64

J I B E . C O M P A N Y

Step 1: Identity

Every user on the network has a private-public keypair

slide-65
SLIDE 65

J I B E . C O M P A N Y

Step 1: Identity

Every user on the network is identified by their public key; their Address

slide-66
SLIDE 66

J I B E . C O M P A N Y

Step 1: Identity

Every user on the network keeps their private key safe

slide-67
SLIDE 67

J I B E . C O M P A N Y

Step 1: Identity

A public key is a pseudonym; a “random” 256-bit number

slide-68
SLIDE 68

J I B E . C O M P A N Y

Step 1: Identity

A public key can be used to verify signatures made using the corresponding private key

slide-69
SLIDE 69

J I B E . C O M P A N Y

Step 2: Transaction

Sign the input of the state transition function and broadcast it

slide-70
SLIDE 70

J I B E . C O M P A N Y

State Transition Function

slide-71
SLIDE 71

J I B E . C O M P A N Y

State

Bob’s Address: 2.3 BTC Alice’s Address: 0.4 BTC Eve’s Address: 567 BTC ...etc

slide-72
SLIDE 72

J I B E . C O M P A N Y

Step 2: Transaction

For instance, “move 1 BTC from me to Bob’s Address”

slide-73
SLIDE 73

J I B E . C O M P A N Y

Step 3: Transaction Verification

Every node receives the transaction and verifies it

slide-74
SLIDE 74

J I B E . C O M P A N Y

Step 3: Transaction Verification

➔ Is the signature correct? ➔ Does the sender have enough bitcoin?

slide-75
SLIDE 75

J I B E . C O M P A N Y

Step 3: Transaction Verification

Discard all unverified transactions

slide-76
SLIDE 76

J I B E . C O M P A N Y

Step 4: Block Creation

slide-77
SLIDE 77

J I B E . C O M P A N Y

Cryptographic Hash

➔ hello

2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

➔ Hello

185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969

slide-78
SLIDE 78

J I B E . C O M P A N Y

Step 4: Block Creation

The blockchain is an immutable, append-only data structure

slide-79
SLIDE 79

J I B E . C O M P A N Y

Step 4: Block Creation

Who gets to add the block to the chain? Who gets to be the master?

slide-80
SLIDE 80

J I B E . C O M P A N Y

Step 5: Proof of Work

A computationally intensive puzzle, of which the answer is easy to verify

slide-81
SLIDE 81

J I B E . C O M P A N Y

Step 5: Proof of Work

On average, only one node comes up with the correct answer every 10 minutes

slide-82
SLIDE 82

J I B E . C O M P A N Y

Step 5: Proof of Work

That node gets a reward in BTC

slide-83
SLIDE 83

J I B E . C O M P A N Y

Step 5: Proof of Work

➔ Fairly select a master node for each iteration of the blockchain ➔ Protect against denial-of-service ➔ Incentivize the stewardship of the network

slide-84
SLIDE 84

J I B E . C O M P A N Y

Step 5: Proof of Work

➔ Slow transaction completion ➔ Huge amount of power (ab)used

slide-85
SLIDE 85

J I B E . C O M P A N Y

Step 6: Block Distribution

The puzzle winner distributes the block to the network

slide-86
SLIDE 86

J I B E . C O M P A N Y

Step 6: Block Distribution

The nodes ➔ Verify the block ➔ Verify the puzzle answer ➔ Verify the transactions ➔ Execute the verified transactions, updating the state

slide-87
SLIDE 87

J I B E . C O M P A N Y

Recap

10 IDENTITY 20 TRANSACTION 30 TRANSACTION VERIFICATION 40 BLOCK CREATION 50 PROOF OF WORK 60 BLOCK DISTRIBUTION 70 GOTO 20

slide-88
SLIDE 88

J I B E . C O M P A N Y

Crash Fault Tolerance

What if the network becomes split?

slide-89
SLIDE 89

J I B E . C O M P A N Y

Crash Fault Tolerance

slide-90
SLIDE 90

J I B E . C O M P A N Y

Crash Fault Tolerance

slide-91
SLIDE 91

J I B E . C O M P A N Y

Crash Fault Tolerance

slide-92
SLIDE 92

J I B E . C O M P A N Y

Smart Contracts

slide-93
SLIDE 93

J I B E . C O M P A N Y

Smart Contracts

➔ User-configurable state transition functions ➔ Deployed using a transaction ➔ Have their own Address

slide-94
SLIDE 94

J I B E . C O M P A N Y

Blockchain

➔ Distributed state machine ➔ Byzantine fault tolerant ➔ Immutable transaction history ➔ Shared transactions and state on all nodes ➔ Pseudonymous transparency ➔ Relatively slow ➔ Relatively expensive

slide-95
SLIDE 95

J I B E . C O M P A N Y

Case study

slide-96
SLIDE 96

J I B E . C O M P A N Y

slide-97
SLIDE 97

J I B E . C O M P A N Y

PoSeID-on

Protection and control Of Secured Information by means of a privacy enhanced Dashboard

slide-98
SLIDE 98

J I B E . C O M P A N Y

PoSeID-on

➔ Give organizations the means to comply with the GDPR ➔ Give users the means to exercise their GDPR-derived rights

slide-99
SLIDE 99

J I B E . C O M P A N Y

GDPR in a Nutshell: Organization

➔ Only ask for personal information when you really need it ➔ Explain why you need that information and what you intend to do with it ➔ Explicitly get permission from the person to whom that information belongs ➔ Keep that personal information secure at all times ➔ Be transparent about what information you have on someone ➔ Don’t keep personal information if you don’t need it anymore ➔ Make it possible for someone to move their information to a competitor

slide-100
SLIDE 100

J I B E . C O M P A N Y

GDPR in a Nutshell: User

➔ You know what personal information an organization has about you ➔ What they do with it and for what purpose they have it ➔ With your explicit permission ➔ You can update your information at any time ➔ You can request deletion of your information at any time* ➔ You can move your information to a competitor

slide-101
SLIDE 101

J I B E . C O M P A N Y

PoSeID-on

PoSeID-on will develop and deliver an innovative intrinsically scalable platform, as an integrated and comprehensive solution aimed to safeguard the rights of data subjects, exploiting the cutting-edge technologies of Smart Contracts and Blockchain, as well as support organizations in data management and processing while ensuring GDPR compliance.

slide-102
SLIDE 102

J I B E . C O M P A N Y

slide-103
SLIDE 103

J I B E . C O M P A N Y

slide-104
SLIDE 104

J I B E . C O M P A N Y

PoSeID-on

https://www.poseidon-h2020.eu

slide-105
SLIDE 105

J I B E . C O M P A N Y

One-stop shop for all personal information

slide-106
SLIDE 106

J I B E . C O M P A N Y

Challenges

➔ Accessibility ➔ Security ➔ Scalability ➔ Ease of use ➔ Budget

slide-107
SLIDE 107

J I B E . C O M P A N Y

Accessibility

➔ All European citizens ➔ Regardless of technological literacy ➔ Regardless of disabilities ➔ Regardless of device

slide-108
SLIDE 108

J I B E . C O M P A N Y

Accessibility

➔ Web-based Dashboard

slide-109
SLIDE 109

J I B E . C O M P A N Y

Security

➔ Strong authentication (eIDAS) ➔ Strong end-to-end encryption ➔ No central authority with access to all personal information

slide-110
SLIDE 110

J I B E . C O M P A N Y

Security

➔ No central repository with personal information ➔ Facilitate a secure conduit between organizations to transport information ➔ While managing and checking access permissions

slide-111
SLIDE 111

J I B E . C O M P A N Y

Scalability

➔ Scale from a few hundred users to hundreds of millions while staying adequately performant

slide-112
SLIDE 112

J I B E . C O M P A N Y

Ease of use

➔ Easy for users to understand and use ➔ Easy for organizations to integrate with

slide-113
SLIDE 113

J I B E . C O M P A N Y

Budget

➔ Limited timeframe ➔ Limited EU-given budget

slide-114
SLIDE 114

J I B E . C O M P A N Y

Budget

➔ Use as many pre-existing (open-source) solutions as possible

slide-115
SLIDE 115

J I B E . C O M P A N Y

Blockchain

➔ PoSeID-on is a research project

slide-116
SLIDE 116

J I B E . C O M P A N Y

Blockchain

➔ Exchange personal information using blockchain

slide-117
SLIDE 117

J I B E . C O M P A N Y

Blockchain

➔ Exchange personal information using blockchain

slide-118
SLIDE 118

J I B E . C O M P A N Y

Blockchain

➔ Exchange personal information using blockchain ➔ Blockchain is immutable ➔ Blockchain has a shared state

slide-119
SLIDE 119

J I B E . C O M P A N Y

Blockchain

➔ Exchange encrypted personal information using blockchain

slide-120
SLIDE 120

J I B E . C O M P A N Y

Blockchain

➔ Exchange encrypted personal information using blockchain

slide-121
SLIDE 121

J I B E . C O M P A N Y

Blockchain

➔ Exchange encrypted personal information using blockchain ➔ Encryption will fail over time ➔ Blockchain is append-only

slide-122
SLIDE 122

J I B E . C O M P A N Y

Blockchain

➔ Exchange permissions over personal information using blockchain

slide-123
SLIDE 123

J I B E . C O M P A N Y

Blockchain

➔ Exchange permissions over personal information using blockchain` ➔ Organization A has the right to have info B from user C ➔ Organization D has the right to read info B from user C from organization A

slide-124
SLIDE 124

J I B E . C O M P A N Y

Blockchain

➔ Exchange permissions over personal information using blockchain ➔ Asking for permissions ➔ Giving permissions ➔ Checking permissions ➔ Revoking permissions

slide-125
SLIDE 125

J I B E . C O M P A N Y

Blockchain

➔ Smart contract for permission management

slide-126
SLIDE 126

J I B E . C O M P A N Y

Blockchain

Person Recipient Sender Data Permission Alice Bank Government Passport details Requested Bob Car insurance Car company Location data Given Eve Hospital

  • Weight

Given

slide-127
SLIDE 127

J I B E . C O M P A N Y

Blockchain

Exchange permissions over personal information using a smart contract 1. Bank asks Alice for access to her passport details 2. Alice gives explicit permission 3. Bank asks the government for Alice’s passport details 4. The government validates the given permission 5. The government supplies Bank with a copy of Alice’s passport

slide-128
SLIDE 128

J I B E . C O M P A N Y

Blockchain

Person Recipient Sender Data Permission Alice Bank Government Passport details Requested Bob Car insurance Car company Location data Given Eve Hospital

  • Weight

Given

slide-129
SLIDE 129

J I B E . C O M P A N Y

Blockchain

Even relationships are potentially sensitive personal information

slide-130
SLIDE 130

J I B E . C O M P A N Y

Blockchain

➔ Use Quorum by JP Morgan Chase ➔ Use burnable pseudo-identities

slide-131
SLIDE 131

J I B E . C O M P A N Y

Quorum

slide-132
SLIDE 132

J I B E . C O M P A N Y

➔ Keep a list of identities (Addresses) for each user ➔ Use a new Address every transaction/hour/day ➔ Remove the association when the user wants to be forgotten

Burnable pseudo-identities

slide-133
SLIDE 133

J I B E . C O M P A N Y

➔ Only exchanges permissions using blockchain ➔ Uses a permissioned blockchain network ➔ Uses Quorum to further separate state ➔ Uses burnable pseudo-identities to further protect identities

PoSeID-on Blockchain

slide-134
SLIDE 134

J I B E . C O M P A N Y

➔ There is still room for improvement

PoSeID-on Blockchain

slide-135
SLIDE 135

J I B E . C O M P A N Y

Room for Improvement

➔ A web-based dashboard introduces a central, trusted authority

slide-136
SLIDE 136

J I B E . C O M P A N Y

Room for Improvement

➔ Burnable identities still need a central, trusted, correlation database

slide-137
SLIDE 137

J I B E . C O M P A N Y

Room for Improvement

➔ PoSeID-on is a very capable solution; a big step in the right direction

slide-138
SLIDE 138

J I B E . C O M P A N Y

Blockchain Applicability

slide-139
SLIDE 139

J I B E . C O M P A N Y

Questions to ask yourself

1. Do you have a distributed state machine? 2. Does it need to be crash fault tolerant? 3. Does it need to be byzantine fault tolerant? 4. Does it have shared state on all nodes? 5. Are all parties involved capable of running a node? 6. Do all nodes have adequate processing/storage capacity? 7. Are you okay with relatively slow transactions?

slide-140
SLIDE 140

J I B E . C O M P A N Y

Questions to ask yourself

1. Do you have a distributed state machine? ✔ 2. Does it need to be crash fault tolerant? ✔ 3. Does it need to be byzantine fault tolerant? ✔ 4. Does it have shared state on all nodes? ❌ 5. Are all parties involved capable of running a node? ❌ 6. Do all nodes have adequate processing/storage capacity? ✔ 7. Are you okay with relatively slow transactions? ❌

slide-141
SLIDE 141

J I B E . C O M P A N Y

Possible Alternatives

slide-142
SLIDE 142

J I B E . C O M P A N Y

Possible Alternatives

➔ “Classic” authenticated encrypted message exchange ➔ Distributed multi-party signatures ➔ Distributed zero-knowledge proofs ➔ DHT using homomorphic encryption

slide-143
SLIDE 143

J I B E . C O M P A N Y

Are you interested?

slide-144
SLIDE 144

J I B E . C O M P A N Y

Join our team!

Jibe.Company Woenselsestraat 350 5623 EG Eindhoven The Netherlands +31 40 767 6001

hello@jibecompany.com

Spyhce Calea Moților no. 28 Cluj Napoca +31 77 8080 140 (NL, DE, EN) +49 211 21070426 (DE)

hello@spyhce.com