Sicurezza dei Dati - parte Blockchain

Corso di Sicurezza dei Dati - Parte Esposito

INTRODUZIONE DI SISTEMI DISTRIBUITI E PROBLEMI DI CONSENSO – LEZ 1 ................................................................ 2

1. CARATTERIZZAZIONE DEI SISTEMI DISTRIBUITI .................................................................................................. 2

2. IL CONSENSO NEI SISTEMI DISTRIBUITI ............................................................................................................... 4

COMUNICAZIONE DI GRUPPO E CONSISTENZA – LEZ 2 .................................................................................................. 8

1. PRIMITIVE DI COMUNICAZIONE DI GRUPPO ....................................................................................................... 8

2. FAILURE DETECTORS ........................................................................................................................................... 10

3. CONSISTENZA DEI DATI ...................................................................................................................................... 12

BLOCKCHAIN - LEZ 3 ....................................................................................................................................................... 14

1. IL TEMPO NEI SISTEMI DISTRIBUITI ................................................................................................................... 14

2. INTRODUZIONE ALLE BLOCKCHAIN ................................................................................................................... 15

3. IL CONSENSO NELLA BLOCKCHAIN ..................................................................................................................... 18

SMART CONTRACTS – LEZ 4 ........................................................................................................................................... 21

1. SMART CONTRACTS ............................................................................................................................................ 21

2. BITCOIN ............................................................................................................................................................... 21

Esercizio 1 scritto. Questo argomento è oggetto di valutazione scritta. .............................................................. 22

3. ETHERIUM ........................................................................................................................................................... 23

4. HYPERLEDGER FABRIC ........................................................................................................................................ 25

Esercizio 3 scritto. Questo argomento è oggetto di valutazione scritta. .............................................................. 26

SICUREZZA E PRIVACY IN BLOCKCHAIN – LEZ 5 ............................................................................................................. 28

1. ATTACCHI ............................................................................................................................................................ 28

2. VULNERABILITA’ DEI CONTRATTI IN SOLIDITY – Esercizio 4 ( descrivere una vulnerabililtà) – Esercizio 2

(scrivere un chaincode in solidity) scritto. Questo argomento è oggetto di valutazione scritta. ........................... 30

3. VULNERABILITA’ DEI CHAINCODE IN HYPERLEDGER FABRIC – Esercizio 5 (descrizione contratto in go)

scritto. Questo argomento è oggetto di valutazione scritta. .................................................................................... 39

4. BLOCKCHAIN VS GDPR ....................................................................................................................................... 42

TRUSTED EXECUTION ENVIRONMENT AND BLOCKCHAIN – LEZ 6 ................................................................................ 44

1. INTRODUZIONE A TEE ........................................................................................................................................ 44

2. SECURE ELEMENT (SE) ........................................................................................................................................ 45

3. TRUSTED PLATFORM MODULE (TPM) ............................................................................................................... 45

4. TRUSTED EXECUTION ENVIRONMENT (TEE) ...................................................................................................... 46

• ARM TrustZone ............................................................................................................................................... 46

• INTEL SGX. ....................................................................................................................................................... 47

• OPEN-TEE ....................................................................................................................................................... 47

5. APPLICAZIONE DI TEE NELLE BLOCKCHAIN ........................................................................................................ 48

• HYPERLEDGER SAWTOOTH ............................................................................................................................ 48

• HYPERLEDGER AVALON. ................................................................................................................................. 48

1

INTRODUZIONE DI SISTEMI DISTRIBUITI E PROBLEMI DI CONSENSO – LEZ 1

1. CARATTERIZZAZIONE DEI SISTEMI DISTRIBUITI

a. DEFINIZIONE: un sistema distribuito è un sistema i cui componenti sono localizzati in

computer connessi in rete, comunicano e coordinano le loro azioni solo attraverso scambio

di messaggi. Caratteristiche fondamentali sono la concorrenza dei componenti, assenza di

un clock globale e possibilità di guasti indipendenti dei componenti.

b. PROGETTAZIONE DEI SISTEMI DISTRIBUITI: per progettare un sistema distribuito vanno

considerati diversi fattori di complessità e servizi specificati attraverso interfacce.

• Eterogeneità: a vari livelli.

• Apertura (openness): servizi e risorse condivise possono essere resi accessibili a una

varietà di clienti.

• Sicurezza (security): confidenzialità (protezione dall’accesso da parte di utenti non

autorizzati), integrità (protezione dall’alterazione o compromissione), disponibilità

(protezione a risorse e servizi condivisi)

• Concorrenza: l’accesso a risorse e servizi condivisi deve essere consentito in maniera

virtualmente simultanea a più utenti.

• Trasparenza: un sistema distribuito deve nascondere che i suoi processi e risorse

sono fisicamente distribuite.

• Scalabilità: un sistema p scalabile se resta efficace ed efficiente anche a seguito di un

aumento considerevole di utenti o risorse.

• Flessibilità: un sistema distribuito flessibile deve rendere semplice la configurazione

del Sistema e l’aggiunta di nuove componenti.

• Guasti: i guasti sono parziali e vanno gestiti in modo da controllar e il livello di

servizio offerto in caso di guasti.

c. MODELLI DI SISTEMI DISTRIBUITI: avendo i sistemi distribuiti molteplici caratteristiche, si

utilizzano i modelli. Un modello descrive tutte e sole le caratteristiche essenziali di un

sistema distribuito. Descrivono le proprietà delle unità software secondo cui decomporre e

programmare i sistemi distribuiti. Un modello fondamentale è un’astrazione delle

caratteristiche essenziali di un sistema, necessarie per analizzare e comprenderne il

funzionamento. Lo scopo del modello fondamentale è rendere esplicite le ipotesi rilevanti

sul sistema, consentire di studiare comportamenti e proprietà possibili o non possibili del

sistema. Il modello fondamentale descrive il modello di iterazione, modello dei guasti e

modello di sicurezza. Le CPU che formano un sistema distribuito possono essere organizzate

in Multiprocessori, dove le CPU condividono una memoria, e Multicomputer, dove ogni

macchina possiede una memoria privata.

d. MODELLO DI INTERAZIONE prevede processi che incapsulano risorse (oggetti) e che

forniscono ad altri processi l’accesso ad esse mediante interazioni con scambio di messaggi.

Possiamo distinguere sistema sincrono, sistema asincrono o sistema parzialmente sincrono.

• SISTEMA DISTRIBUITO SINCRONO: per natura sono sistemi piccoli, è definito tale se

esistono e sono noti i limiti inferiori e superiori al tempo di esecuzione di ogni passo

di elaborazione, il limite superiore al tempo di consegna di un messaggio, il limite

superiore al tasso di deviazione di ciascun orologio locale (clock drift rate). Se non è

possibile garantire tali valori limite. Vantaggi: è possibile definire algoritmi distribuiti

basati sull’individuazione dei fallimenti tramite time-out. Svantaggi: è difficile

assicurare tali proprietà in un sistema su grande scala e nel tempo. Tipicamente i

sistemi reali sono asincroni e si tenta di trasformarli in sistemi parzialmente sincroni.

2

• SISTEMA DISTRIBUTO ASINCRONO: un sistema è asincrono se non esistono limiti

alla velocità di esecuzione de processi, al ritardo di trasmissione dei messaggi, o alla

deviazione degli orologi. Non è possibile formulare ipotesi temporali relativamente

all’elaborazione, allo scambio messaggi e alla sincronizzazione. Alcuni problemi non

hanno soluzione nei sistemi asincroni.

e. MODELLO DEI FALLIMENTI: prima di entrare nello specifico del modello di fallimento,

definiamo tre termini:

• Fallimento (failure): scostamento da un comportamento considerato corretto o

desiderabile.

• Guasto (fault): causa originaria del fallimento. Anche se presente il fault può non

essere attivato in una esecuzione, quando il fault degenera in errore a causa

dell’attivazione, esso si dice active, altrimenti è dormiente, dormant.

• Errore (error): lo stato in cui transita il sistema a seguito dell’attivazione di un

guasto.

Il modello dei fallimenti definisce le modalità con cui si possono verificare guasti ai processi

o ai canali di comunicazione. In pratica si possono avere fallimenti per crash, per

omissione, di valore o bizantini. I fallimenti vengono classificati in:

• Omission failure: si ha quando un processo o un cannale non eseguono un’azione

che ci si aspetta che eseguano;

• Arbitrary o Byzantine Failure: è la semantica peggiore per un guasto, in cui ci si può

verificare qualunque tipo di errore;

• Timing failure: applicabile sono ai sistemi sincroni, mancato rispetto di una

scadenza.

Possiamo definire diverse tipologie di fallimenti:

• Fail stop: si ah quando un processo non esegue più azioni e gli altri processi sono in

grado di rilevarne il fallimento;

• Crash: si ha quando un processo non esegue più azioni e gli altri processi possono

non essere in grado di rilevarne il fallimento;

• Omissione: il canale non trasporta i messaggi oppure il processo fa una send/receive

ma il messaggio non viene spedito/ricevuto;

• Prestazionale: il tempo di consegna di un messaggio eccede il limite superiore, il

tempo di esecuzione di una azione eccede il limite superiore, la deriva rispetto a un

clock ideale eccede il limite superiore;

• Bizantino: un fallimento di un processo o di un canale, che si comportano in modo

arbitrario.

f. MODELLO DI SICUREZZA: il modello di iterazione è la base di quello di sicurezza in quanto la

sicurezza di un sistema distribuito può essere ottenuta rendendo sicuri i processi e i canali di

comunicazione, e proteggendo le risorse che i processi incapsulano. Aspetti della sicurezza

sono: • Confidenzialità: Protezione dall’accesso di non autorizzati;

• Integrità: protezione dall’alterazione o compromissione;

• Disponibilità: protezione dei mezzi di accesso alle risorse. 3

Le possibili minacce alla sicurezza sono intercettazione, interruzione, alterazioni e

fabbricazione. Un sistema distribuito ha bisogno di una politica di sicurezza, che definisce le

azioni che le entità del sistema possono eseguire e quelle che sono proibite. I meccanismi di

sicurezza nei sistemi distribuiti sono generalmente posti a livelli del middleware.

Le dipendenze tra servizi di sicurezza portano al concetto di Trusted computing base (TCB),

ovvero l’insieme di tutti i meccanismi di sicurezza in un sistema distribuito che sono

necessari per rispettare la sicurezza del sistema.

2. IL CONSENSO NEI SISTEMI DISTRIBUITI

a. PROBLEMA DEL CONSENSO: il problema del consenso distribuito consiste nel far si che

alcuni processi convengano su un valore, dopo che almeno uno di essi ha effettuato una

proposta a riguardo. I requisiti che devono essere soddisfatti da un algoritmo di consenso

sono: • TERMINAZIONE (TERMINATION): prima o poi ogni processo corretto prende una

decisione;

• ACCORDO (AGREEMENT): due qualsiasi processi corretti non decidono

diversamente;

• INTEGRITÀ (INTEGRITY): se tutti i processi corretti propongono lo stesso valore, la

decisione finale di ogni processo corretto corrisponde a quel valore.

b. PROBLEMA DEL COMPORTAMENTO BIZANTINO: è un difetto di un sistema bizantino in cui i

componenti possono guastarsi e c’è imperfetta conoscenza sull’eventuale guasto di un

componente. Un componente può apparire incoerentemente sia guasto che funzionante ai

sistemi di rilevamento degli errori ed è molto difficile dichiararlo guasto ed escluderlo dalla

rete, perché devono prima raggiungere un consenso su quale componente ha fallito. Il

problema differisce dal consenso in quanto solo il generale fornisce un valore sul quale

devono convenire e in questo problema il tipo di fallimento può essere solo bizantino nel

problema del consenso abbiamo diversi tipi di fallimento.

• TERMINAZIONE (TERMINATION): prima o poi ogni processo corretto prende una

decisione;

• ACCORDO (AGREEMENT): due qualsiasi processi corretti non decidono

diversamente;

• INTEGRITÀ (INTEGRITY): se il comandante è corretto, tutti i processi corretti

decidono per il valore proposto dal comandante.

c. PROBLEMA DELLA CONSISTENZA INTERATTIVA: è una variante del problema del consenso.

Ogni processo propone un valore e l’obiettivo è che tutti i processi concordino su un vettore

di valori, uno per ciascuno di essi. L’identificativo del processo è la posizione all’interno del

vettore.

• TERMINAZIONE (TERMINATION): prima o poi ogni processo corretto prende una

decisione;

• ACCORDO (AGREEMENT): il vettore di decisione è lo stesso per tutti i processi

corretti; 4

•

INTEGRITÀ (INTEGRITY): se è corretto, tutti processi corretti decidono per il

valore proposto da come elemento i-esimo del vettore.

d. CONSENSO IN UN SISTEMA SINCRONO: abbiamo f processi e la disponibilità di una primitiva

b-multicast che garantisce che i processi destinatari corretti ricevano il messaggio, finché il

mittente (multicaster) non fallisce. Nel caso peggiore abbiamo al più f+1 iterazioni del ciclo,

la cui durata è limitata da un apposito timeout (sistema sincrono), e possono fallire al

massimo f processi. Dopo f+1 cicli, ogni processo sceglie il valore secondo una determinata

funzione (minimo).

• TERMINAZIONE (TERMINATION): ovvia, il sistema è sincrono;

• ACCORDO (AGREEMENT) E INTEGRITA’ (INTEGRITY): sono raggiunti se si dimostra

che tutti i processi sopravvissuti pervengono allo stesso vettore al temine

dell’algoritmo, in quanto poi tutti applicano la stessa funzione.

Il problema dei generali bizantini in un sistema sincrono ammette soluzione solo se N <= 3f.

e. CONSENSO IN UN SISTEMA ASINCRONO: Non esiste nessun algoritmo deterministico in

grado di garantire il raggiungimento del consenso in un sistema asincrono a scambio di

messaggi. Sono, però, possibili delle operazioni per trasformare un sistema asincrono in

parzialmente sincrono. Alcune tecniche sono:

• INDEBOLIRE LA CONDIZIONE DI TERMINATION: introducendo elementi di non

determinismo oppure garantendo la termination esclusivamente durante periodi di

sincronia del sistema;

• INDEBOLIRE LA CONDIZIONE DI AGREEMENT: individuando un insieme finito per i

possibili valori decisionali dei singoli processi;

• INDEBOLIRE IL MODELLO DEL SISTEMA: introducendo dei failure detectors per

distinguere i processi lenti (ma corretti) da quelli effettivamente falliti.

f. CONSENSO DI PAXOS: proprietà del consenso di Paxos.

• LIVENESS: uno tra i valori proposti prima o poi viene scelto. Se un valore viene

scelto, ogni processo prima o poi apprenderà tale scelta;

• SAFETY: un valore può essere scelto tra quelli proposti, il valore scelto deve essere

unico. Un processo non deve mai apprendere che un valore è stato scelto a meno

che non sia stato effettivamente scelto.

Ogni processo può svolgere uno o più dei seguenti ruoli:

• PROPOSER: è un processo che ha la facoltà di proporre un valore;

• ACCEPTOR: è un processo che ha la facoltà di accettare un valore precedentemente

proposto da un proposer;

• LEARNER: è un processo che ha la facoltà di apprendere la scelta di un valore

effettuata da un acceptor. 5

Avendo un singolo acceptor abbiamo un single point of failure e fallendo il processo

renderebbe impossibile il progresso dell’algoritmo. Quindi consideriamo un insieme di

acceptors e un valore proposto è scelta se un insieme sufficientemente grande di essi lo

accetta. In assenza di fallimenti o perdite di messaggi, è desiderabile che un valore venga

scelta anche se proposto da un solo propopser, quindi definiamo il requisito:

P1: Un acceptor deve accettare la prima proposta che riceve.

Ma nel caso in cui ci sono più proposer che propongono valori diversi in tempi vicini, P1

potrebbe portare alla situazione che non venga accettato nessun valore da una

maggioranza di acceptors. Quindi teniamo traccia delle diverse proposte associando un

seriale alla proposta, così che una pr