Sicurezza dei Dati - parte Blockchain

Corso di sicurezza dei dati - Parte Esposito

Indice

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. Ethereum ........................................................................................................................................................... 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. Vulnerabilità dei contratti in Solidity – Esercizio 4 (descrivere una vulnerabilità) – Esercizio 2 (scrivere un chaincode in Solidity) scritto. Questo argomento è oggetto di valutazione scritta. ........................... 30

3. Vulnerabilità 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 è 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 controllare 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 interazione, 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 distribuito asincrono: un sistema è asincrono se non esistono limiti alla velocità di esecuzione dei 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 canale 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 ha 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 interazione è 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 sì 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 integrità (integrity): sono raggiunti se si dimostra che tutti i processi sopravvissuti pervengono allo stesso vettore al termine 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 proposer, 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