SlideShare a Scribd company logo
1 of 43
Download to read offline
Thanatos
Implementazione di un attacco a Forza Bruta sul Crittosistema D.E.S.
tramite un’infrastruttura di calcolo distribuito e parallelo
In ordine Alfabetico:
Francesco Pietralunga
Idriss Riouak
Renato Garavaglia
Tommaso Campari
Corso di Laurea in
Informatica
SOMMARIO
• Strumenti utilizzati
• Scopo del progetto
• DES - Implementazione in C
• Introduzione CUDA–C
• Architettura CUDA
• Implementazione DES su CUDA -C
Strumenti Utilizzati
Strumenti Utilizzati
Strumenti Utilizzati
Strumenti Utilizzati
Strumenti Utilizzati
Strumenti Utilizzati
Strumenti Utilizzati
Strumenti Utilizzati
Scopo del Progetto
Lo scopo del nostro lavoro è quello non tanto di mettere in evidenza le già note vulnerabilità del crittosistema DES, ma
piuttosto quello di fare un confronto tra due approcci distinti di attacco al crittosistema che utilizzano la medesima
modalità ma con strumenti differenti, in particolare verranno utilizzate nella prima parte dei test le CPU presenti sui nodi
della rete, mentre nella seconda parte verranno utilizzate le GPU.
Il DES (Data Encryption standard ) è un Crittosistema scelto come standard dal Federal Information Processing Standard
(FIPS) per il governo degli Stati Uniti d’America nel 1976.
Si basa su chiavi a 64 bit (di cui 8 sono di controllo, quindi lo spazio dei valori si riduce a 56 bit)
e per questo si presta a un attacco a Forza Bruta. Seppur 256 chiavi siano poche, un singolo processore impiegherebbe
anni a testarle tutte, per questo già nel 1998 gli EFF’s DES cracker (Deep Crack) ruppero il DES in appena 56 ore grazie a
un supercomputer equipaggiato con 1856 chip.
DES -Implementazione in C
DEMO PRATICA
Il	C		è	un	linguaggio	di	programmazione	di	basso	livello,	per	questo	è	spesso	visto	come	uno	dei	linguaggi	più	́	
performanti	in	circolazione.	Inoltre	ha	svariate	librerie	che	permettono	di	svolgere	funzioni	altrimenti	
complicate	come	il	trasferimento	delle	chiavi	dal	master	ai	vari	Worker	con	OpenMPI	o	l’esecuzione	con	
multithreading	grazie	a	OpenMP.
Introduzione CUDA-C
Perché	CUDA-C	? Noi	abbiamo	scelto CUDA-C	in	quanto	si	prestava	
particolarmente	ai	nostri	fini:	fornisce	infatti	supporto	a	
OpenMPI e	OpenMP e	le	parti	CPU	si	presentano	
comunque	efficienti	in	quanto		C è	tra	i	linguaggi	più	
performanti.	
Cos’è	CUDA-C	?
Le	schede	grafiche	con	supporto	a	CUDA (Compute	Unified	Device	Architecture)	
sono	un	tipo	di	Hardware	creato	da	NVIDIA	per	permettere	l’esecuzione	di	
calcolo	parallelo	su	GPU.	I	linguaggi	di	programmazione	disponibili	
nell’ambiente	di	sviluppo	per	CUDA,	sono	estensioni	dei	linguaggi	più	diffusi	
per	scrivere	programmi.	Il	principale	è	CUDA-C	(C	con	estensioni	NVIDIA),	altri	
sono	estensioni	di	Python,	Fortran,	Java	e	MATLAB.
Architettura CUDA
CUDA basa il suo funzionamento sul concetto di esecuzione parallela,
questo è possibile grazie a particolari funzioni marcate con la keyword
global che sono anche definite come funzioni kernel.
Una funzione kernel si presenta esattamente come una funzione C nella sua
definizione, le differenze si mostrano
infatti al momento della chiamata che è strutturata come:
kernel	<<<	NumBlocks,	NumThreads	>>>	(Arguments);
Implementazioni DES su CUDA-C
1° Implementazione	CUDA-C
2° Implementazione	CUDA-C
PROFILING
• Profiling DES su CUDA-C
• ZeroCopyMemory
• Profiling Jetson TX1
Profiling DES su CUDA-C
Profiling	dei	tempi	
d’esecuzione	con	
nvprof.
Profiling generate_all_subkeys. (1)
Kernel
Performance
Profiling generate_all_subkeys. (2)
Function Unit
Utilization
Profiling try_all. (1)
Kernel
Performance
Profiling try_all. (2)
Function Unit
Utilization
Profiling try_all. (3)
Stall Reasons:
Ragioni di Stallo.
Jetson TX1
L’università ci ha fornito l’accesso ad una scheda Jetson TX1 sulla quale
effettuare dei test.
Questa scheda, ha un’unica memoria centrale, condivisa tra CPU e GPU.
Infatti per utilizzare questa scheda, per allocare la memoria, bisogna
utilizzare il metodo d’allocazione ZeroCopy.
ZeroCopyMemory
Per l’implementazione è stato modificata la seconda implementazione in CUDA-C cfr(Slide 7)
Sostituendo le classiche cudaMalloc con le chiamate cudaHostAlloc fornite
dalla libreria CUDA e le cudaMemcpy con cudaGetHostDevicePointer con le seguenti
Sintassi.
cudaError_t cudaHostAlloc(void** pHost, size_t size, unsigned int flags).
cudaError_t cudaHostGetDevicePointer(void ** pDevice, void * pHost, unsigned int flags).
Profiling Jetson TX1
Analisi dei tempi d’esecuzione sulla macchina Jetson TX1
Comunicazione & Distribuzione Chiavi
• Entità Server e Client
• Scatter
• Coda
• Opzioni d’esecuzione
• Gestione delle richieste
Comunicazione & Distribuzione Chiavi
OpenMPI(Message	Passing Interface): API	per	la	gestione	delle	comunicazioni tra	i	vari	nodi.
OpenMP(MultiProcessing): è un API multipiattaforma per la creazione di applicazioni
parallele su sistemi a memoria condivisa.
Comunicazione & Distribuzione Chiavi
• L’entità	Server:	che	distribuisce	blocchi	di	chiavi	ai	singoli	Client	e	ne	testa	il	
risultato.	
• L’entità	Client:	che	per	ogni	chiave	del	blocco	passatogli	prova	a	decifrare	il	
messaggio	e	se	ha	successo	informa		il	Server	che	la	chiave	è stata	trovata	e	
dunque	il	messaggio	messaggio	viene	ridecifrato	dal	Server e	mostra	all’utente	
la	chiave	trovata.
Scatter & Coda (1)
Int MPI_Scatter( const void* sendbuf,
int sendCount,
MPI_Datatype sendtype,
void* recvbuff,
int recvcount,
MPI_Datatype recvtype,
int root, MPI_Comm comm);
Scatter & Coda (2)
256 chiavi
255 chiavi
• Supponiamo di avere K client con CPU a disposizione
Numero di Blocchi	=
255
#	$%&'()
L’eventuale resto viene calcolato dall’ultimo client.
Gestito tramite coda. Slide successiva
Scatter & Coda (2)
225 + 224
225
224
0
Server Client
Server comunica l’offset
Una volta comunicato l’offset viene eliminato.
Una volta
ricevuto
l’offset il client
elabora le
chiavi.
Per l’opzione -cpu
sono stati utilizzati
offset d’ampiezza
262.144
Opzioni d’esecuzione (1)
typedef struct {long	long	possibileChiave;
long	long	processID;	
double tempo;
int tipo;	
}	infoExec;
static MPI_Datatype Info_Type;
Opzioni d’esecuzione (2)
-cpu: vengono utilizzate come unica unità d’elaborazione le CPU.
-gpu: vengono utilizzate come unica unità d’elaborazione le GPU.
-zcmem: deve essere preceduta da –gpu o da -hybrid, e permette di eseguire i
test utilizzando i costrutti CudaHostAlloc e CudaGetHostDevicePointer.
-hybrid: permette di utilizzare contemporaneamente sia l’unità d’elaborazione CPU
che GPU, sfruttando dunque al massimo tutta la potenza computazionale a
disposizione.
Gestione delle richieste
Per poter gestire i diversi messaggi che i client devono mandare al server, utilizziamo
diversi tipi di TAG. cfr(OpenMPI)
• Key_found_tag (0): Utilizzando questo Tag, il client comunica al master che ha
trovato la chiave per decifrare il messaggio di partenza.
• New_offset_request_tag (1): Utilizzando questo Tag, il master è in grado di capire
che uno dei client ha bisogno di un nuovo blocco di chiavi da processare.
• Info_on_elaboration_tag(2): Utilizzando questo Tag, il client raccoglie il messaggio
e lo elabora per ricavare l’avanzamento totale dell’attacco.
GREEN COMPUTING VS GRID COMPUTING
• TESLA VS XEON VS JETSON
• ARM VS XEON
• ZeroCopyMemory
• Hybrid Function: 4K40 VS TX1
• 1998 VS 2016
TESLA VS XEON VS JETSON
TESLA VS XEON VS JETSON
ARM VS XEON
ZeroCopyMemory Testing (1)
ZeroCopyMemory Testing (2)
HYBRID FUNCTION: 4K40 VS TX1
1998 VS 2016 (1)
Grafico delle chiavi testate per giorno da DESCHALL
nel 1998.
Grafico dei Client connessi in ogni giorno di elaborazione
su DESCHALL nel 1998.
1998 VS 2016 (2)
In particolare osservando il seguente grafico
notiamo come nel massimo picco di potenza di
calcolo (con all’incirca 14000 Client connessi)
DESCHALL elaborasse “solo” 600 trilioni di
chiavi al giorno, mentre oggi il nostro sistema con
lo stesso numero di Client ne elaborerebbe
2,536 Quadrilioni cfr(Slide 34), garantendo quindi un
incremento delle prestazioni del 422 %

More Related Content

What's hot

Sistemi Operativi: CPU Scheduler - Lezione 09
Sistemi Operativi: CPU Scheduler - Lezione 09Sistemi Operativi: CPU Scheduler - Lezione 09
Sistemi Operativi: CPU Scheduler - Lezione 09
Majong DevJfu
 
LUG - Logical volumes management
LUG - Logical volumes managementLUG - Logical volumes management
LUG - Logical volumes management
Alessandro Manfredi
 

What's hot (8)

[SLIDE]Modellazione della dinamica di un liquido bifase mediante GPU CUDA
[SLIDE]Modellazione della dinamica di un liquido bifase mediante GPU CUDA[SLIDE]Modellazione della dinamica di un liquido bifase mediante GPU CUDA
[SLIDE]Modellazione della dinamica di un liquido bifase mediante GPU CUDA
 
Heartbleed - OpenSSL Bug
Heartbleed - OpenSSL BugHeartbleed - OpenSSL Bug
Heartbleed - OpenSSL Bug
 
Sistemi Operativi: CPU Scheduler - Lezione 09
Sistemi Operativi: CPU Scheduler - Lezione 09Sistemi Operativi: CPU Scheduler - Lezione 09
Sistemi Operativi: CPU Scheduler - Lezione 09
 
MITM Attack with Patching Binaries on the Fly by Adding Shellcodes
MITM Attack with Patching Binaries on the Fly by Adding ShellcodesMITM Attack with Patching Binaries on the Fly by Adding Shellcodes
MITM Attack with Patching Binaries on the Fly by Adding Shellcodes
 
Thread
ThreadThread
Thread
 
LUG - Logical volumes management
LUG - Logical volumes managementLUG - Logical volumes management
LUG - Logical volumes management
 
Processi e Thread
Processi e ThreadProcessi e Thread
Processi e Thread
 
Summary of “The Case for Writing Network Drivers in High-Level Programming La...
Summary of “The Case for Writing Network Drivers in High-Level Programming La...Summary of “The Case for Writing Network Drivers in High-Level Programming La...
Summary of “The Case for Writing Network Drivers in High-Level Programming La...
 

Similar to Thanatos

PIT2012: Workshop@UniNA - Compilazione del Kernel Linux
PIT2012: Workshop@UniNA - Compilazione del Kernel LinuxPIT2012: Workshop@UniNA - Compilazione del Kernel Linux
PIT2012: Workshop@UniNA - Compilazione del Kernel Linux
Marco Ferrigno
 
Architettura dei Calcolatori 06 Elementi Architetturali Di Base
Architettura dei Calcolatori 06 Elementi Architetturali Di BaseArchitettura dei Calcolatori 06 Elementi Architetturali Di Base
Architettura dei Calcolatori 06 Elementi Architetturali Di Base
Majong DevJfu
 
Traffic Shaping Su Linux
Traffic Shaping Su LinuxTraffic Shaping Su Linux
Traffic Shaping Su Linux
Majong DevJfu
 
Sistemi Operativi: Thread - Lezione 08
Sistemi Operativi: Thread - Lezione 08Sistemi Operativi: Thread - Lezione 08
Sistemi Operativi: Thread - Lezione 08
Majong DevJfu
 

Similar to Thanatos (20)

Thanatos
ThanatosThanatos
Thanatos
 
OpenCL - Introduzione al framework OpenCL
OpenCL - Introduzione al framework OpenCLOpenCL - Introduzione al framework OpenCL
OpenCL - Introduzione al framework OpenCL
 
PIT2012: Workshop@UniNA - Compilazione del Kernel Linux
PIT2012: Workshop@UniNA - Compilazione del Kernel LinuxPIT2012: Workshop@UniNA - Compilazione del Kernel Linux
PIT2012: Workshop@UniNA - Compilazione del Kernel Linux
 
Elementidi informatica
Elementidi informaticaElementidi informatica
Elementidi informatica
 
Presentazione - Algoritmo di Dijkstra
Presentazione - Algoritmo di DijkstraPresentazione - Algoritmo di Dijkstra
Presentazione - Algoritmo di Dijkstra
 
DHow2 - L5
DHow2 - L5DHow2 - L5
DHow2 - L5
 
Assemblare un pc
Assemblare un pcAssemblare un pc
Assemblare un pc
 
Jvm performance Tuning
Jvm performance TuningJvm performance Tuning
Jvm performance Tuning
 
Thesis Amicucci Slides IT
Thesis Amicucci Slides ITThesis Amicucci Slides IT
Thesis Amicucci Slides IT
 
Architettura dei Calcolatori 06 Elementi Architetturali Di Base
Architettura dei Calcolatori 06 Elementi Architetturali Di BaseArchitettura dei Calcolatori 06 Elementi Architetturali Di Base
Architettura dei Calcolatori 06 Elementi Architetturali Di Base
 
Introduzione ai Sistemi Operativi
Introduzione ai Sistemi OperativiIntroduzione ai Sistemi Operativi
Introduzione ai Sistemi Operativi
 
Hadoop analyzerJR
Hadoop analyzerJRHadoop analyzerJR
Hadoop analyzerJR
 
Progettazione e sviluppo di un software applicativo su un single board computer
Progettazione e sviluppo di un software applicativo su un single board computerProgettazione e sviluppo di un software applicativo su un single board computer
Progettazione e sviluppo di un software applicativo su un single board computer
 
Linux Security Hardening - panoramica sui principi generali per la riduzione...
Linux  Security Hardening - panoramica sui principi generali per la riduzione...Linux  Security Hardening - panoramica sui principi generali per la riduzione...
Linux Security Hardening - panoramica sui principi generali per la riduzione...
 
Hardening
HardeningHardening
Hardening
 
Traffic Shaping Su Linux
Traffic Shaping Su LinuxTraffic Shaping Su Linux
Traffic Shaping Su Linux
 
Pf e netfilter, analisi dei firewall open source
Pf e netfilter, analisi dei firewall open sourcePf e netfilter, analisi dei firewall open source
Pf e netfilter, analisi dei firewall open source
 
Relazione Progetto cRIO
Relazione Progetto cRIORelazione Progetto cRIO
Relazione Progetto cRIO
 
Relazione Progetto cRio
Relazione Progetto cRioRelazione Progetto cRio
Relazione Progetto cRio
 
Sistemi Operativi: Thread - Lezione 08
Sistemi Operativi: Thread - Lezione 08Sistemi Operativi: Thread - Lezione 08
Sistemi Operativi: Thread - Lezione 08
 

Thanatos

  • 1. Thanatos Implementazione di un attacco a Forza Bruta sul Crittosistema D.E.S. tramite un’infrastruttura di calcolo distribuito e parallelo In ordine Alfabetico: Francesco Pietralunga Idriss Riouak Renato Garavaglia Tommaso Campari Corso di Laurea in Informatica
  • 2. SOMMARIO • Strumenti utilizzati • Scopo del progetto • DES - Implementazione in C • Introduzione CUDA–C • Architettura CUDA • Implementazione DES su CUDA -C
  • 11. Scopo del Progetto Lo scopo del nostro lavoro è quello non tanto di mettere in evidenza le già note vulnerabilità del crittosistema DES, ma piuttosto quello di fare un confronto tra due approcci distinti di attacco al crittosistema che utilizzano la medesima modalità ma con strumenti differenti, in particolare verranno utilizzate nella prima parte dei test le CPU presenti sui nodi della rete, mentre nella seconda parte verranno utilizzate le GPU. Il DES (Data Encryption standard ) è un Crittosistema scelto come standard dal Federal Information Processing Standard (FIPS) per il governo degli Stati Uniti d’America nel 1976. Si basa su chiavi a 64 bit (di cui 8 sono di controllo, quindi lo spazio dei valori si riduce a 56 bit) e per questo si presta a un attacco a Forza Bruta. Seppur 256 chiavi siano poche, un singolo processore impiegherebbe anni a testarle tutte, per questo già nel 1998 gli EFF’s DES cracker (Deep Crack) ruppero il DES in appena 56 ore grazie a un supercomputer equipaggiato con 1856 chip.
  • 12. DES -Implementazione in C DEMO PRATICA Il C è un linguaggio di programmazione di basso livello, per questo è spesso visto come uno dei linguaggi più ́ performanti in circolazione. Inoltre ha svariate librerie che permettono di svolgere funzioni altrimenti complicate come il trasferimento delle chiavi dal master ai vari Worker con OpenMPI o l’esecuzione con multithreading grazie a OpenMP.
  • 13. Introduzione CUDA-C Perché CUDA-C ? Noi abbiamo scelto CUDA-C in quanto si prestava particolarmente ai nostri fini: fornisce infatti supporto a OpenMPI e OpenMP e le parti CPU si presentano comunque efficienti in quanto C è tra i linguaggi più performanti. Cos’è CUDA-C ? Le schede grafiche con supporto a CUDA (Compute Unified Device Architecture) sono un tipo di Hardware creato da NVIDIA per permettere l’esecuzione di calcolo parallelo su GPU. I linguaggi di programmazione disponibili nell’ambiente di sviluppo per CUDA, sono estensioni dei linguaggi più diffusi per scrivere programmi. Il principale è CUDA-C (C con estensioni NVIDIA), altri sono estensioni di Python, Fortran, Java e MATLAB.
  • 14. Architettura CUDA CUDA basa il suo funzionamento sul concetto di esecuzione parallela, questo è possibile grazie a particolari funzioni marcate con la keyword global che sono anche definite come funzioni kernel. Una funzione kernel si presenta esattamente come una funzione C nella sua definizione, le differenze si mostrano infatti al momento della chiamata che è strutturata come: kernel <<< NumBlocks, NumThreads >>> (Arguments);
  • 15. Implementazioni DES su CUDA-C 1° Implementazione CUDA-C 2° Implementazione CUDA-C
  • 16. PROFILING • Profiling DES su CUDA-C • ZeroCopyMemory • Profiling Jetson TX1
  • 17. Profiling DES su CUDA-C Profiling dei tempi d’esecuzione con nvprof.
  • 22. Profiling try_all. (3) Stall Reasons: Ragioni di Stallo.
  • 23. Jetson TX1 L’università ci ha fornito l’accesso ad una scheda Jetson TX1 sulla quale effettuare dei test. Questa scheda, ha un’unica memoria centrale, condivisa tra CPU e GPU. Infatti per utilizzare questa scheda, per allocare la memoria, bisogna utilizzare il metodo d’allocazione ZeroCopy.
  • 24. ZeroCopyMemory Per l’implementazione è stato modificata la seconda implementazione in CUDA-C cfr(Slide 7) Sostituendo le classiche cudaMalloc con le chiamate cudaHostAlloc fornite dalla libreria CUDA e le cudaMemcpy con cudaGetHostDevicePointer con le seguenti Sintassi. cudaError_t cudaHostAlloc(void** pHost, size_t size, unsigned int flags). cudaError_t cudaHostGetDevicePointer(void ** pDevice, void * pHost, unsigned int flags).
  • 25. Profiling Jetson TX1 Analisi dei tempi d’esecuzione sulla macchina Jetson TX1
  • 26. Comunicazione & Distribuzione Chiavi • Entità Server e Client • Scatter • Coda • Opzioni d’esecuzione • Gestione delle richieste
  • 27. Comunicazione & Distribuzione Chiavi OpenMPI(Message Passing Interface): API per la gestione delle comunicazioni tra i vari nodi. OpenMP(MultiProcessing): è un API multipiattaforma per la creazione di applicazioni parallele su sistemi a memoria condivisa.
  • 28. Comunicazione & Distribuzione Chiavi • L’entità Server: che distribuisce blocchi di chiavi ai singoli Client e ne testa il risultato. • L’entità Client: che per ogni chiave del blocco passatogli prova a decifrare il messaggio e se ha successo informa il Server che la chiave è stata trovata e dunque il messaggio messaggio viene ridecifrato dal Server e mostra all’utente la chiave trovata.
  • 29. Scatter & Coda (1) Int MPI_Scatter( const void* sendbuf, int sendCount, MPI_Datatype sendtype, void* recvbuff, int recvcount, MPI_Datatype recvtype, int root, MPI_Comm comm);
  • 30. Scatter & Coda (2) 256 chiavi 255 chiavi • Supponiamo di avere K client con CPU a disposizione Numero di Blocchi = 255 # $%&'() L’eventuale resto viene calcolato dall’ultimo client. Gestito tramite coda. Slide successiva
  • 31. Scatter & Coda (2) 225 + 224 225 224 0 Server Client Server comunica l’offset Una volta comunicato l’offset viene eliminato. Una volta ricevuto l’offset il client elabora le chiavi. Per l’opzione -cpu sono stati utilizzati offset d’ampiezza 262.144
  • 32. Opzioni d’esecuzione (1) typedef struct {long long possibileChiave; long long processID; double tempo; int tipo; } infoExec; static MPI_Datatype Info_Type;
  • 33. Opzioni d’esecuzione (2) -cpu: vengono utilizzate come unica unità d’elaborazione le CPU. -gpu: vengono utilizzate come unica unità d’elaborazione le GPU. -zcmem: deve essere preceduta da –gpu o da -hybrid, e permette di eseguire i test utilizzando i costrutti CudaHostAlloc e CudaGetHostDevicePointer. -hybrid: permette di utilizzare contemporaneamente sia l’unità d’elaborazione CPU che GPU, sfruttando dunque al massimo tutta la potenza computazionale a disposizione.
  • 34. Gestione delle richieste Per poter gestire i diversi messaggi che i client devono mandare al server, utilizziamo diversi tipi di TAG. cfr(OpenMPI) • Key_found_tag (0): Utilizzando questo Tag, il client comunica al master che ha trovato la chiave per decifrare il messaggio di partenza. • New_offset_request_tag (1): Utilizzando questo Tag, il master è in grado di capire che uno dei client ha bisogno di un nuovo blocco di chiavi da processare. • Info_on_elaboration_tag(2): Utilizzando questo Tag, il client raccoglie il messaggio e lo elabora per ricavare l’avanzamento totale dell’attacco.
  • 35. GREEN COMPUTING VS GRID COMPUTING • TESLA VS XEON VS JETSON • ARM VS XEON • ZeroCopyMemory • Hybrid Function: 4K40 VS TX1 • 1998 VS 2016
  • 36. TESLA VS XEON VS JETSON
  • 37. TESLA VS XEON VS JETSON
  • 42. 1998 VS 2016 (1) Grafico delle chiavi testate per giorno da DESCHALL nel 1998. Grafico dei Client connessi in ogni giorno di elaborazione su DESCHALL nel 1998.
  • 43. 1998 VS 2016 (2) In particolare osservando il seguente grafico notiamo come nel massimo picco di potenza di calcolo (con all’incirca 14000 Client connessi) DESCHALL elaborasse “solo” 600 trilioni di chiavi al giorno, mentre oggi il nostro sistema con lo stesso numero di Client ne elaborerebbe 2,536 Quadrilioni cfr(Slide 34), garantendo quindi un incremento delle prestazioni del 422 %