POLITECNICO DI MILANO. Studio degli acceleratori crittografici per IPsec: alternative di design e scheduling efficiente dei pacchetti

Transcript

1 POLITECNICO DI MILANO V Facoltà di Ingegneria di Milano Corso di Laurea in Ingegneria delle Telecomunicazioni Studio degli acceleratori crittografici per IPsec: alternative di design e scheduling efficiente dei pacchetti Relatore: Corelatore: Chiar.ma Prof.ssa Maria Giovanna SAMI Dott. Ing. Alberto FERRANTE Tesi di Laurea di: Antonio Vincenzo TADDEO Mat Anno Accademico

2 a mia nonna Nina...

3 Ringraziamenti I ringraziamenti... Come si può essere originali quando si vuole dire grazie a qualcuno? Ho pensato molto a cosa scrivere in questo spazio cercando di non cadere nel banale e nel ridicolo. Più mi sforzo di trovare una qualche alternativa al solito elenco di persone, più mi rendo conto di quanta gente abbia contribuito al raggiungimento di questo mio traguardo universitario. Ogni giorno, ogni istante, qualcuno mi ha versato una goccia di sè, spesso senza neanche accorgersene. Chi direttamente, chi a distanza, chi con l amicizia e l amore o con la semplice presenza, tutti quanti hanno riempito questi miei anni. Sono sicuro che se leggessi questa tesi cercando di dare un volto ad ogni pagina, riuscirei a trovare a chi appartiene. Capisco che la cosa possa sembrare strana vista con occhi indifferenti ma non lo è se si pensa che se sono arrivato fino a questo punto lo devo anche alla serie di causa ed effetto del vivere e del relazionarsi quotidiano. Perchè non provare a risalire lungo il fiume del tempo e tentare di far riaffiorare un grazie per ognuno? Non credo sia un impresa impossibile, l unica mia paura è quella di trascurare qualcuno. Ebbene eccomi ripercorrere il mio passato per donare di cuore il mio GRAZIE... Il primo gradino è tutto dei miei zii e delle mie cugine di Cantù. Loro è il primo appoggio; con loro i primi passi. GRAZIE. Un tempo che non sembra finire mai è tutto di Luca. Inaspettata e sorprendente l amicizia che ci lega. Suoi sono i lunghi anni vissuti tra Como e Milano. 2

4 Gli devo molto anche se non lo sa. GRAZIE. Ad intervalli imprevedibili ma sempre indimenticabili trova posto Diego. La sua speciale personalità e la sua generosa disponibilità sono qualcosa di unico ed indispensabile. GRAZIE. I primi tre anni di week end comaschi sono tutti delle mie sorelline del nord, Laura e Valeria. Non si può vivere l università se non si vive la città; a loro il merito di avermi mostrato le dolci notti comasche. GRAZIE E poi... E poi saltiamo... saltiamo lo scoglio di Milano e viaggiamo al di là dei confini. In svizzera sono i 10 mesi più lunghi mai vissuti, per la loro intensità emotiva e per l enorme crescita professionale. Sono i giorni del Master ALaRI a Lugano. Ho girato per il mondo standomene comodamente seduto sul divano ad ascoltare i racconti dei miei compagni di classe. Non me ne vogliano male se cito solo due esemplari come un valido campione rappresentativo. Di Giuseppe sono le notti insonni. Suoi sono le lezioni su Linux e i tanti progetti insieme. Un grande esempio professionale. GRAZIE. Un immedita intesa e una prolungata amicizia è invece di Leandro. Sua è la grande bontà d animo e l appoggio costante nei giorni finali. Con lui è il rimpianto di tante partite mai più giocate. GRAZIE E poi... marginali ma sempre punti di riferimento sono Francesco e la sua pazzia, Marco e i suoi ragionamenti e Luca ed il suo bluetooth, Umberto ed i suoi incubi, Yum e Carola per la loro gentilezza. GRAZIE. E se gli ultimi istanti sono quelli che si ricordano di più come dimenticare Alberto. Con lui ho condiviso il mio lavoro di tesi. Indispensabile la sua sapienza e la disponibilità dimostrata. Sua è la mia sopportazione. GRAZIE. Fondamentale l apporto della Prof.ssa Sami. Sua è la possibilità offertami al master, così come la disponibilità ad avermi come tesista. Suoi sono i precisi suggerimenti scientifici. Sue le mirate osservazioni. GRAZIE. Tutto questo rivivere il mio tempo rischia di distrarmi dalle cose importanti. 3

5 Per fortuna so a chi devo tutto ciò. Tutto dall origini ad adesso è della mia famiglia. Loro è la mia crescita. Con loro è la mia gioia ed il mio dolore. Loro è il continuo apporto e l interminabile fiducia data e ricevuta. Loro sono i sacrifici e loro è l orgoglio di accogliermi da ingegnere. GRAZIE Un pezzettino di tutto è di mio fratello Adriano. Suo è il periodo milanese. Suo è il merito di essere stato presente nel bene e nel male. GRAZIE. E monica? Lei è qualcosa di speciale. Onnipresente in ogni periodo dei miei studi, dai precorsi fino ad ora. Onnipresente in ogni forma, da collega ad amica ad amante. Onnipresente in ogni emozione. GRAZIE. 4

6 Indice 1 Introduzione 14 2 IPsec Introduzione Architettura di IPsec Overview Security Association (SA) Modalità Trasporto e Tunnel Security Policy Database (SPD) Security Association Database (SAD) Il protocollo ESP Il protocollo AH I protocolli IKE e ISAKMP IKE phase_ IKE phase_ Implementazioni di IPsec Gestione ed elaborazione del traffico IPsec Traffico Inbound Traffico outbound Elaborazione IPsec dei pacchetti IPSec in azione Le reti private virtuali (VPN)

7 INDICE La rete Road Warrior Stato dell arte Introduzione Broadcom Corrent Hifn IBM Motorola/FreeScale Sun Approccio metodologico al design degli acceleratori hardware Introduzione Metodologia di design per l acceleratore Panoramica esterna Design generale e posizionamento del modulo Tipologie di posizionamento, pro e contro Interfaccia fisica di comunicazione Struttura Interna Design dell architettura, approccio multi-livello Il livello STACK Il livello APPLICATION Il livello CORE Rappresentazione grafica Selezione di un design Visione d uso Design del firmware e del software Metodologie di valutazione per un acceleratore Criterio ad uso pratico La certificazione NIST, FIPS PUB

8 INDICE 5 Acceleratore crittografico, sistema di riferimento e modello Analisi del problema e scelte progettuali Specifiche dell acceleratore crittografico Sistema di riferimento Architettura del modello I processori Il bus La memoria Lo scheduler Algoritmo di scheduling Funzionamento del sistema Analisi ed obiettivi del modello Simulazioni sul modello e sliding window Design space exploration I pattern di traffico Velocità di elaborazione relativa per i processori Test preliminari e scheduling efficiente Ulteriore ottimizzazione del sistema La sliding window Il nuovo scheduling con la sliding window Test post ottimizzazione Esempio e test di scalabilità del modello Conclusioni Sviluppi futuri A Cenni di crittografia 147 A.1 Algoritmi a chiave simmetrica A.2 Algoritmi a chiave pubblica A.3 Il protocollo Diffie-Hellman

9 INDICE A.4 Algoritmi di identificazione Bibliografia 150 8

10 Elenco delle figure 2.1 IPsec Roadmap: protocolli e loro relazioni Modello UML di IPsec Modalità Tunnel e Trasporto per AH e ESP, combinazioni possibili Header ESP Header e Trailer EPS per crittografia ed autenticazione dei pacchetti IP Header AH Autenticazione del pacchetto IP tramite AH IKE phase_1: Scambio messaggi in modalità Main Mode (sx) e Aggressive Mode (dx) [12] IKE phase_2: Scambio di messaggi in modalità Quick Mode [12] Elaborazione pacchetti IPsec: Inbound [13] Elaborazione pacchetti IPsec: Outbound [13] Elaborazione IPsec in dattaglio: sequenza di operazioni Mappatura del datagramma IP all interno del protocollo ESP [14] Diagramma UML degli Stati per la creazione dell Header ESP Diagramma UML degli stati per la creazione del Trailer ESP Diagramma UML degli stati per l elaborazione IPsec in modalità Tunnel La rete privata virtuale con IPsec [13] Processore Broadcom

11 ELENCO DELLE FIGURE 3.2 Applicazioni VPN che usano il Broadcom Corrent CR7110, schema a blocchi Esempio di uso del chip CR7110 all interno di una scheda PCI Hifn HIPP III 8350 Security Processor Diagramma a blocchi del chip Hifn HIPP III Esempio di uso di Hifn HIPP III 8350 in una scheda PCI IBM 4753 Cryptographic Coprocessor IBM 4753 Module Schema a blocchi dell IBM 4758 Cryptographic Coprocessor Diagramma a blocchi del MPC Sun Crypto Acceleretor 4000 board Il modulo Acceleratore (ACC) Fabric Side Connection Inline Fabric Side Look-aside Mode (Off-line) Network Side Connection In-line Network Side Connection Look-aside Mode (Off-Line) Spazio di design interno di un acceleratore hardware Partizionamento HW/SW dello stack IPsec in funzione del posizionamento: In-line, Off-line[30] Rete VPN fra secure gateway con canale sicuro protetto tramite ESP Modello di riferimento del sistema Schema di funzionamento in realtime IPsec Throughput in funzione delle dimensioni dei pacchetti [36] Distribuzione cumulativa della lunghezza dei pacchetti su internet [37] Media e mediano, e rispettive varianze, dei pacchetti su internet in 11 mesi di osservazioni. [37] Flusso di analisi e generazione obiettivi Istogramma della distribuzione esponenziale

12 ELENCO DELLE FIGURE 6.2 Istogramma della distribuzione uniforme Istogramma del traffico reale Throughtput della CPU senza algoritmo di scheduling in funzione di E ratio, per diversi pattern di traffico. In (a) I ratio = 1, in (b) I ratio = Latenza media del sistema con la sola CPU operativa Confronto tra throughput del sistema: (a) solo CPU vs (b) CPU + acceleratore Confronto sulla latenza media del sistema: (a) solo CPU vs (b) CPU + acceleratore Percentuale di pacchetti processati dalla CPU Dimensione media dei pacchetti processati: (a) dall acceleratore, (b) dalla CPU Istogrammi dei pacchetti processati (a) dall acceleratore e (b) dalla CPU La sliding window Schema di principio di funzionamento dello scheduler con sliding window Percentuale sul totale dei pacchetti merged, per diverse dimensione della finestra, con distribuzione di SA (a) 4-equal, (b) 4- incremental Percentuale di pacchetti processati dalla CPU per ogni pattern di traffico. (a) W = 1 e (b) W = Percentuale di pacchetti processati dalla CPU. Confronto tra sistema con sliding window (W = 5) e senza (W = 1) nel caso di pattern real Confronto tra le lunghezze medie dei pacchetti elaborati dai processori e la dimensione media di un pacchetto merged Confronto tra i throughput del sistema (a) senza sliding window e (b) con sliding window W =

13 ELENCO DELLE FIGURE 6.18 Confronto dei tempi medi di latenza per il sistema (a) senza sliding window e (b) con sliding window W = Variazione percentuale relativa del throughput calcolata rispetto al sistema senza sliding window, per dimensioni della finestra pari a 1 e 5, diversificata per pattern di traffico Variazione percentuale relativa della latenza media calcolata rispetto al sistema senza sliding window, per dimensioni della finestra pari a 1 e 5, diversificata per pattern di traffico Variazione percentuale relativa dell uso della CPU calcolata rispetto al sistema senza sliding window, per dimensioni della finestra pari a 1 e 5, diversificata per pattern di traffico Throughput del sistema multi-acceleratore Sistema multi-acceleratore: percentuale sul totale di pacchetti processati (a) nella CPU e (b) nell acceleratore Percentuale di conflitti sul numero di richieste di accesso al bus per l acceleratore-1 con (a) W = 1 e (b) con W =

14 Elenco delle tabelle 4.1 Interfacce di comunicazione per un generico acceleratore hardware Criteri di valutazione di un acceleratore hardware [21] Performance degli algoritmi crittografici per un tipico generalpurpose [14] Pattern di traffico usati nelle simulazioni. Distribuzione del payload dei pacchetti Dettagli sulle singole distribuzioni dei pattern di traffico Caratterizzazione del traffico in base alla SA Range dei parametri per i pattern di traffico usati nelle simulazioni Range dei valori per I ratio ed E ratio Throughput dell acceleratore senza algoritmo di scheduling in funzione dei pattern di input Range di valori per i parametri della sliding window Numero medio di pacchetti con la stessa SA in funzione delle dimensioni della finestra, per le due distribuzioni di traffico 4- equal e 4-incremental

15 Capitolo 1 Introduzione Portato alla ribalta dalla tecnologia (Information Technology - IT) e reso globale dal diffondersi di internet, il trattamento dell informazione ha risvegliato antiche paure quali quella dell ignoto o quella di essere spiati. Si intuisce come in ambiti quali militare o, più semplicemente, aziendale, la protezione dell informazione rappresenta un elemento di vitale importanza. Comprensibile è la reazione che ne consegue: si escogitano soluzioni in grado di proteggere i dati e rendere sicure le comunicazioni. Nato come appendice al trattamento dei dati, oggi il problema della sicurezza dell informazione si è ritagliato uno spazio tutto suo andando a costituire parte essenziale di ogni nuovo sviluppo tecnologico. Da dove proviene la maggiore fonte di rischio? Dalla miscela esplosiva di tre fattori: dalla diffusione capillare della rete e dal conseguente aumento del valore complessivo delle informazioni, dallo sviluppo della tecnologia e dal differenziale di conoscenza tra vittime e aggressori. Il primo fattore, la crescita esponenziale del numero degli utenti, è certo il fenomeno piú evidente. Molti di questi nuovi utenti non hanno la minima consapevolezza dei rischi legati alla connessione in rete; sono attratti dalle potenzialità e dalla quantità di informazioni disponibili ma del tutto indifferenti alla protezione della comunicazione e della privacy. 14

16 1. Introduzione Al contrario una moltitudine di aziende, appartenenti a svariati settori, sono interessate ad instaurare canali di comunicazione sicuri. Il loro obiettivo si scontra, però, con la realtà della rete internet che risulta essere di pubblico dominio. In generale esistono due modi di rendere il canale privato: separazione fisica con controllo di accesso; tramite offuscamento dove solo l interlocutore abilitato è in grado di comprendere l informazione, ai più incomprensibile. L offuscamento dei dati è alla base delle moderne virtual private network (VPN). Lo scopo delle VPN è usare la rete pubblica di internet per stabilire comunicazioni private, mantenendo la qualità del canale intatta, ed offrendo servizi di sicurezza ed affidabilità. L utilizzo delle Internet-based VPN networks ha parecchi vantaggi riassumibili in: uso dell infrastruttura flessibile e ad accesso multiplo offerta da internet. riduzione dei costi legati alle economie di scala del sistema internet ed eliminazione dei costi di gestione legati ad una comunicazione special-purpose realizzata ad hoc. uso della crittografia per la confidenzialità ed integrità dei dati trasmessi. facilitazione e sviluppo dell E-commerce B2B e B2C offrendo un alto grado di sicurezza delle transazioni. possibilità di realizzazioni e gestione delle VPN sia hardware che software. scelta tra una multitudine di tecnologie e protocolli (IPSec, SSL, etc..) in grado di costituire differenti architetture di sicurezza. Il cardine su cui si fondano le VPN, la crittografia dei dati, è anche il suo punto debole, inteso in termini di prestazioni del sistema. Stabilire e gestire una connessione sicura (sia usando SSL o IPSec) richiede infatti un complesso meccanismo di scambio di chiavi, l elaborazione dei pacchetti, la verifica dell autenticità, la 15

17 1. Introduzione crittografia dei dati e ciò risulta particolarmente intenso per qualsiasi processore general-purpose. Inoltre, con reti ad alta velocità, la capacità del server di processare i pacchetti diviene il collo di bottiglia del sistema. Ottenere delle buone performance in questo contesto diventa abbastanza complicato. Non si deve dimenticare che l innovazione tecnologica di internet è indirizzata verso la trasmissione ad alte velocità di pacchetti dati con dimensioni ben superiori a 4 KB, quindi, con ulteriore sovraccarico di lavoro per il server che espleta l algoritmo di crittaggio. La necessità di gestire la crescente richiesta di connessioni simultanee allo stesso server, il fabbisogno di trasmissioni ad elevata velocità, la volontà di mantenere un elevato livello di riservatezza delle comunicazioni porta alla richiesta di dispositivi ed algoritmi in grado di accrescere le performance del sistema VPN. L interesse, mostrato in questo settore, è principalmente rivolto verso lo sviluppo di dispositivi hardware col compito di accelerare o la cifratura dei dati, o l intero protocollo di sicurezza. Giustificare la presenza di un acceleratore crittografico è abbastanza semplice: il costo per aggiungere un acceleratore, al fine d incrementare il volume di dati processati, è significativamente minore rispetto ad avere un nuovo server; inoltre, alleggerisce il carico di lavoro del server ospitante liberandolo dall onere di crittare i dati. L approccio da adottare nella progettazione di un acceleratore hardware deve far fronte ad una serie di scelte spesso fra loro contrastanti, e trovare un giusto equilibrio tra performance, costi di sviluppo e vincoli architetturali. Alcuni fattori chiave da tenere in considerazione nella realizzazione e/o analisi di un acceleratore sono riassunti di seguito: Protocollo di sicurezza supportato (tipicamente SSL o IPSec). Acceleratore protocol-aware oppure packet-aware. Capacità di memorizzazione delle informazioni di sicurezza per ogni sessione. Gestione delle chiavi e delle sessioni. 16

18 1. Introduzione Livello di interazione con le risorse del sistema (processore dell host, memoria, etc..). Tipo di implementazione, p.e., in-line/off-line col flusso di dati. Performance dell acceleratore in funzione del traffico e dimensione dei pacchetti. Tutti gli aspetti più interssanti che caratterizzano gli acceleratori hardware sono stati esaminati e discussi in questa tesi analizzandoli da un punto di vista ad alto livello. Un primo contributo innovativo che si riscontra in questo lavoro di tesi è, appunto, rappresentato da un approccio metodologico di carattere generale applicabile al design degli acceleratori hardware. Si vuole offrire in questo modo un quadro schematico e chiaro sulla vastità di proposte provenienti dal mercato degli acceleratori hardware. L idea di una metodologia di design per gli acceleratori nasce quindi dall osservazione del lavoro svolto in ambito aziendale e si mescola con le opere nella letteratura per dare un aspetto formale e scientifico ai contenuti. Facendo uso della metodologia di design proposta si è poi considerato un acceleratore hardware da includere in un sistema di riferimento costituito da una secure gateway che utilizzi tale acceleratore per il solo crittaggio dei dati. L acceleratore è modellizzato facendo avendo in mente un light weigh accelerator. Volendolo classificare secondo i criteri sopra esposti, il dispositivo è packet-aware, dedicato alla sola elaborazione dei pacchetti, senza nessun tipo di memoria interna, offline al flusso di dati e connesso tramite bus PCI alla CPU del sistema. L idea di base è quella di avere un chip estremamente semplice, di ridotte dimensioni ed elevate performance crittografiche. La presenza di un dispositivo del genere ha il vantaggio di essere versatile, adattabile a qualsiasi protocollo di sicurezza, di facile installazione, eventualmente parametrico, riprogrammabile ed infine scalabile. Di contro, come precedentemente accennato, fa uso di risorse limitate e condivise, come bus e memoria; necessita di un continuo flusso di dati ed istruzioni di controllo da/per la CPU. 17

19 1. Introduzione Il modello del sistema, sviluppato in SystemC, si prefigge di essere indipendente dalla piattaforma, con una profondità di dettagli che si colloca a livello di System Design, e focalizzato sull aspetto funzionale dei componenti. Particolarità del modello è data dalla possibilità di cifrare i dati sia tramite l acceleratore che contemporaneamente tramite la CPU. Uno scheduler amministrerà i pacchetti distribuendoli adeguatamente tra i due processori secondo un ben definito algoritmo. L obiettivo è quello di studiare il comportamento dell intero sistema (CPU e acceleratore) sottoposto ad un flusso in ingresso ad elevato rate che necessita di essere crittato secondo le regole dettate da IPSec. L attenzione è posta su un aspetto in particolare: vagliare l effetto delle dimensioni dei pacchetti sulle performance del sistema ed individuare un algoritmo di scheduling che ne ottimizzi il crittaggio scegliendo tra un implementazione software (CPU) o in hardware (acceleratore). Le linee guida nella progettazione dell algoritmo di scheduling sono, naturalmente, quelle di massimizzare il throughput del sistema e minimizzare il tempo di elaborazione complessivo. Sul modello di riferimento sono quindi state effettuate delle simulazioni per valutare e misurare gli effetti dello scheduling dei pacchetti tra CPU ed acceleratore. I risultati ottenuti dimostrano che il partizionamento del processo di crittaggio tra hardware e software, se adeguatamente gestito in funzione delle dimensioni dei dati e dello stato del sistema, è una soluzione necessaria per evitare, da un lato, che l acceleratore si saturi e, dall altro, compensare il vincolo imposto dalla limitata banda del bus PCI. Il bus rappresenta, infatti, una risorsa condivisa da memoria ed acceleratore, e risulta particolarmente sovraccaricato, oltre che dai dati, anche dalle numerose istruzioni di gestione e controllo dell acceleratore stesso. I miglioramenti introdotti all algoritmo di scheduling dei pacchetti, sono stati pensati con l intenzione di ridurre il numero di interazioni CPU-acceleratore, numero di richieste sul bus, e, possibilmente, accresce la località dei dati per un rapido accesso e riduzione della tempistica. 18

20 1. Introduzione Un secondo aspetto innovativo estraibile da questo lavoro di tesi è dato dall idea di usare una sliding window per pre-analizzare il flusso di dati in funzione dell appartenenza di un pacchetto ad una security association (SA). I pacchetti aventi la stessa SA sono gestiti come fossero un unico dato e cifrati nei processori in un unico step. In questo modo si risparmia sui tempi di inizializzazione del dispositivo e si compensano le inefficienze riscontrate nel processamento di pacchetti di dimensioni ridotte. La sliding window ha il pregio di essere tecnologicamente facile da implementare; si interfaccia immediatamente con qualsiasi algoritmo di scheduling pre-esistente; è altamente parametrizzabile ed adattabile al flusso di dati; produce risultati confortanti in termini di performance, pagando un lieve dazio sulla latenza del sistema; riduce l uso della CPU nel processo di crittaggio dei pacchetti favorendo invece l acceleratore, che risulta essere, in questo modo, sfruttato a dovere. Di seguito viene fornito un indice ragionato circa i contenuti e gli argomenti trattati in questa tesi. La struttura dei capitoli rispecchia il flusso di lavoro. Innanzi tutto viene data una breve introduzione su IPsec, il protocollo usato per la creazione delle reti private virtuali (VPN). Si è partiti poi da uno studio dell esistente nel campo degli acceleratori hardware nelle reti VPN-IPsec per individuare un approccio metodologico al design dei dispositivo. Tale approccio metodologico è servito per produrre le specifiche dell acceleratore da usare nel modello del sistema di riferimento preso in considerazione in questa tesi. Infine una serie di simulazioni sono state svolte per testare il comportamento del modello. Capitolo 2: IPsec Introduzione al protocollo di sicurezza IPsec, comunemente usato nella creazione delle VPN. Si definiscono le linee guida per realizzare un implementazione del protocollo secondo lo standard dell IETF. Sono esposti: il nucleo di IPsec costituito da ESP e AH nelle due modalità, trasporto e tunnel; i concetti chiave di SA e policy ed i database SAD e SPD; il protocollo 19

21 1. Introduzione per lo scambio delle chiavi IKE; e sono forniti dettagli circa l elaborazione del traffico IPsec. Capitolo 3: Stato dell arte. Viene data una descrizione schematica e generale dell architettura e delle funzionalità degli acceleratori presenti sul mercato. Le informazioni raccolte provengono da un lavoro di ricerca svolto tra le maggiori aziende produttrici di acceleratori crittografici hardware. Capitolo 4: Approccio metodologico al design degli acceleratori hardware. Sono descritti gli acceleratori hardware attraverso differenti livelli di analisi per offrire una visione macroscopica del sistema acceleratore, che sia il più possibile teorica e si distacchi da una specifica realizzazione in commercio. Si sono individuati due approcci metodologici, uno da applicare al design degli acceleratori e l altro da usare per una valutazione generale dei dispositivi. Capitolo 5: Acceleratore crittografico, sistema di riferimento e modello. In questo capitolo si definiscono le specifiche dell acceleratore crittografico da usare nel sistema di riferimento. Si descrive il modello del sistema in ogni suo componente. Sono dati i dettagli dell algoritmo di scheduling e si focalizzano i dettagli circa lo studio da effettuare sul modello. Capitolo 6: Simulazioni sul modello e sliding window. In questo capitolo sono presentati i risultati delle simulazioni. Viene introdotta l idea della sliding window e mostrati gli effetti sul sistema. Infine è fornito un esempio di scalabilità del nostro modello verso un architettura multi-acceleratore. 20

22 Capitolo 2 IPsec 2.1 Introduzione La sicurezza delle comunicazioni è parte integrante della nuova versione del protocollo internet IPv6. La sicurezza viene interamente affidata ad una suite di protocolli accumunati sotto la sigla IPsec. Le reti attuali basate su IPv4 possono comunque supportare IPsec come estensione. IPsec è uno standard di IETF, la cui architettura di base è esposta in [1], e fornisce, attraverso tecniche crittografiche, servizi di sicurezza al traffico IP. La protezione prende la forma di autenticazione dell origine dei dati, integrità senza connessione, confidenzialità, controllo degli accessi e antireplay. Servizio supplementare di IPsec, non strettamente connesso con la sicurezza, è IPcomp [2], per la compressione dei pacchetti, motivata, in parte, dall impossibilità dei livelli sottostanti di effettuare una compressione efficiente a causa dell impiego della cifratura. Poichè tali servizi vengono forniti a livello IP, livello di rete, possono essere utilizzati, in maniera del tutto trasparente, da un qualunque protocollo sovrastante. IPsec protegge i dati tra singoli hosts, tra reti di secure gateway (p.e., router, firewall, etc.), e tra host e secure gateway. L utilizzo principale di IPsec è nella creazione delle reti private virtuali (VPN) e in ambito del cosidetto road warrior. 21

23 2. IPsec Figura 2.1: IPsec Roadmap: protocolli e loro relazioni L architettura di IPsec è schematizzata in Figura 2.1, e comprende anche le relazioni tra i protocolli di cui è costituito. Dettagli circa i protocolli ed i servizi saranno esposti nelle sessioni successive. 2.2 Architettura di IPsec Overview Documento di riferimento per l architettura di IPsec è la RFC [1], in cui si definiscono le linee guida per realizzare un implementazione del protocollo. Sono esposti i servizi di sicurezza che IPsec deve provvedere, come e dove possono essere usati, come sono costruiti i pacchetti e in che modo vengono processati, ed, infine, le interazioni tra l elaborazione IPsec e le politiche (policy). Come si può osservare in Figura 2.1, il nucleo di IPsec è costituito da due protocolli: l Authentication Header (AH) e l Encapsulated Security payload (ESP). Entrambi possono essere usati per proteggere l intero datagramma IP oppure la sola parte del livello superiore inclusa nel payload di IP. Questa distinzione è gestita considerando due differenti modi di IPsec: tunnel mode e transport mode, rispettivamente. 1 Request For Comment (RFC) 22

24 2. IPsec IPsec necessita di protocolli ed elementi supplementari per permetterne un reale utilizzo ed un implementazione coerente con l infrastruttura internet. A questo scopo, IPsec richiede un protocollo per lo scambio delle chiavi; suggerimento di IETF è IKE (Internet Key Exchange). Elementi fondamentali collegati con IPsec sono le Security Association (SA) e i parametri che definiscono la policy di sicurezza, dai quali hanno origine il Security Policy Database (SPD) e Security Association Database (SAD). IPsec distingue il flusso di pacchetti in entrata (inbound) o in uscita (outbound) per i quali esistono differenti policy e SA. In Figura 2.2 è mostrata una schematizzazione di IPsec tramite UML. Il modello tiene conto delle specifiche dello standard IETF Security Association (SA) Per processare propriamente i pacchetti IPsec è necessario avere un modo per associare i servizi di sicurezza e una chiave crittografica al traffico che deve essere protetto, ed aggiungere, inoltre, le informazioni circa il computer paritario remoto con il quale il traffico IPsec è scambiato. In altre parole, come proteggere il traffico, quale traffico è protetto e con chi avviene lo scambio. Il problema viene risolto tramite la creazione di una Security Association (SA), la quale contiene le informazioni necessarie per processare i pacchetti IP secondo le direttive di IPsec. Una SA è unidirezionale, definisce i servizi di sicurezza associati al traffico per singola direzione, in entranta ed in uscita; pertanto, se viene richiesta una relazione per uno scambio sicuro bidirezionale, sono necessarie almeno due SA. Inoltre, IPSec permette di negoziare SA asimmetriche: un host può avere, in questo modo, il traffico in uscita, p.e., cifrato con 3DES ed autenticato tramite SHA-1, mediante l impiego del protocollo ESP; mentre il traffico in ingresso, p.e., solo autenticato tramite MD5 attraverso il protocollo AH. Si intuisce che ogni SA può essere associata sia ad AH che ESP, ma non ad entrambi. Nel caso si voglia proteggere il traffico, utilizzando congiuntamente AH e ESP, serviranno, pertanto, due security association, una per ogni protocollo. 23

25 2. IPsec SP_DB SAD Inbound_SPD Is composed by 0..* Rules AHProtocol Outbound_SPD - - uses Is composed by queries 0..* Policy_SPD IPSecProtocol -- ESPProtocol manages queries calls - - IKEProtocol Trailer_ESP Header_ESP TransportAH TunnelAH TransportESP TunnelESP NewIPHeader SA_DB Inbound_SAD Outbound_SAD Is composed by 0..* 0..* Is composed by SA IKE_SAD is composed by 0..* IKE_SA Figura 2.2: Modello UML di IPsec 24

26 2. IPsec Per identificare una SA si utilizza una tripla di parametri così definiti: Securty Parameters Index (SPI): Una stringa di bit assegnata a questa security association. Tale valore è trasportato nell intestazione di AH ed ESP e viene deciso dal destinatario della security association. Indirizzo IP di destinazione: Indica il punto terminale della security association, nel caso di modalità tunnel (esposta nella sezione 2.2.3) si tratta dell indirizzo presente nell header esterno. Protocollo di sicurezza: Indica quale protocollo utilizzare (AH o ESP). Le SA possono essere create manualmente o dinamicamente, e vengono memorizzate all interno del Security Association Database (per il quale si veda la sezione 2.2.5). Se creata manualmente una SA non ha un tempo di vita. Viceversa, se creata dinamicamente, una security association possiede un tempo di vita che può essere espresso sia in termini temporali che di traffico ricevuto (bytes), scaduto il quale la SA deve essere dichiarata non più valida e rimossa dal SAD. Tale tempo di vita viene generalmente negoziato in fase di scambio di chiavi tra i due hosts; identifica l ammontare di traffico protetto da una determinata chiave e pertanto deve essere gestito con le dovute cautele per evitare di subire attacchi al sistema per uso permanente della stessa chiave crittografica Modalità Trasporto e Tunnel In [1] si descrivono due modalità per applicare la protezione IPsec a ogni pacchetto. In modalità trasporto (non utilizzata solitamente tra secure gateway) viene aggiunto l header ESP (si veda la Figura 2.5) o AH (si veda la Figura 2.7) tra l header IP e l header del protocollo di trasporto. In modalità tunnel invece il 25

27 2. IPsec ESP Tunnel AH Tunnel AH Trasporto ESP Tasporto LOCAL AREA LOCAL AREA GATEWAY SECURE HOST GATEWAY SECURE HOST INTERNET NETWORK NETWORK LOCAL AREA LOCAL AREA NETWORK NETWORK INTERNET HOST SECURE GATEWAY HOST SECURE GATEWAY LOCAL AREA LOCAL AREA NETWORK NETWORK INTERNET HOST SECURE GATEWAY HOST SECURE GATEWAY LOCAL AREA LOCAL AREA NETWORK NETWORK INTERNET HOST SECURE GATEWAY HOST SECURE GATEWAY Figura 2.3: Modalità Tunnel e Trasporto per AH e ESP, combinazioni possibili. 26

28 2. IPsec pacchetto originale viene incapsulato in un nuovo pacchetto IP e l header AH o ESP viene inserito tra i due header IP. Le SA, inoltre, possono essere combinate tra loro, sia nel caso i punti terminali delle SA siano gli stessi, sia nel caso siano diversi (SA nesting) : si potrebbe per esempio avere una coppia di SA in modalità trasporto tra i due host ed una coppia di SA in modalità tunnel tra i gateway che stanno tra i due host. In Figura 2.3 sono mostrati i livelli di combinazione ed associazione tra SA, AH e ESP Security Policy Database (SPD) Un sistema che implementa IPsec mantiene un SPD per ciascuna interfaccia sulla quale IPsec è attivo. Tale SPD è suddiviso in due sezioni, una per il traffico in ingresso (SPD inbound) e una per il traffico in uscita (SPD outbound), e contiene un elenco ordinato di politiche di sicurezza in base alle quali ogni pacchetto IP viene elaborato. Ogni politica del SPD è suddivisa in due parti: una parte regola e una parte azione. La parte regola è codificata mediante uno o più selettori e individua il tipo di traffico da trattare secondo le modalità indicate dalla parte azione. Per ogni selettore, nel caso la regola indichi l uso di IPsec, vi è inoltre un indicazione del valore che questo deve assumere all interno del SAD (si veda la sezione 2.2.5). La parte azione specifica se il pacchetto che ha soddisfatto la parte regola debba essere scartato,lasciato passare in chiaro, o elaborato tramite IPsec. In questo ultimo caso viene anche specificato in che modo il pacchetto debba essere elaborato, indicando i protocolli e gli algoritmi da utilizzare, e viene mantenuto un puntatore alla lista di SA attive negoziate a partire da questa politica. I selettori mediante i quali è possibile esprimere una regola del security policy database includono campi dell header IP e dei protocolli di livello superiore assieme ad altri elementi. Segue una lista di selettori previsti da [1]: Indirizzo IP di destinazione: 27

29 2. IPsec può trattarsi di un singolo indirizzo IP, di un intervallo, di indirizzi (estremi inclusi), di un indirizzo IP e una maschera di sottorete o di un indirizzo generico (wildcard). In caso di modalità tunnel tale indirizzo IP è quello presente nell header IP interno. I campi presenti nell header IP esterno non fanno parte dei selettori. Indirizzo IP Sorgente: Può trattarsi di un singolo indirizzo IP, di un intervallo di indirizzi (estremi inclusi), di un indirizzo IP e una maschera di sottorete o di un indirizzo generico (wildcard). Valgono le stesse considerazioni per il selettore precedente nel caso di modalità tunnel. Nome: UserID dell utente, nome del sistema espresso come FQDN (Fully Qualified Domain Name), X.500 DN (Distinguished Name), X.500 GN (General Name) o di un valore generico. Tale selettore può essere utilizzato soltanto congiuntamente ad un protocollo di scambio delle chiavi, poichè non esiste alcun modo per immettere tale valore all interno di un header IP. Livello di sensibilità dei dati: Viene utilizzato per i sistemi MLS (Multi Level Security). Può assumere i valori: unclassified, confidential, secret, top secret o un valore generico. Protocollo di trasporto: Ottenuto dal campo IPv4 protocol o IPv6 next header. Può essere un singolo protocollo o una wildcard. Porta sorgente e destinazione: Può essere una singola porta TCP o UDP o una wildcard. 28

30 2. IPsec Security Association Database (SAD) Un sistema che implementa IPsec mantiene un SAD per ogni interfaccia sulla quale IPsec è attivo. Il SAD è diviso in due sezioni: una sezione contiene le SA relative al traffico in uscita e una sezione quelle relative al traffico in ingresso. Ogni SA presente nel SAD è suddivisa in tre parti: Chiave di identificazione: Costituita dalla tripla <indirizzo IP di destinazione, SPI, protocollo>; viene utilizzata per individuare univocamente la SA all interno del SAD. Selettori: Contiene una copia dei selettori della politica (presente nel SPD), che ha portato a negoziare tale SA. Per ogni selettore espresso nel SPD, è possibile includere il valore che questo assume nel SPD oppure quello che assume nel pacchetto che ha portato alla negoziazione della SA. Materiale specifico SA: Contiene le chiavi, gli algoritmi negoziati e tutto il materiale necessario per l elaborazione di questa SA (dimensione della finestra, anti-replay, tempo di vita, etc.) Il protocollo ESP Il protocollo Encapsulating Security Payload fornisce i servizi di riservatezza, autenticazione, integrità e protezione contro gli attacchi replay. E possibile utilizzare solo il servizio di riservatezza oppure solo il servizio di autenticazione e integrità (e il servizio anti-replay se selezionato), oppure è possibile utilizzare tutti i servizi insieme. ESP aggiunge sia un header che un trailer questo perchè incapsula tutti i dati che protegge. L autenticazione offerta da ESP, a differenza di quella di AH, non copre l header IP esterno. 29

31 2. IPsec Figura 2.4: Header ESP. Il formato di ESP è illustrato in Figura 2.4, segue una breve descrizione dei campi che lo compongono [3]: Security Parameters Index: Contiene il security parameters index della SA utilizzata Sequence Number: Contiene il numero di sequenza del pacchetto per una certa SA. Analogo ad AH Payload Data: Contiene il payload del pacchetto IP (se in modalità trasporto) o l intero pacchetto IP (in caso di modalità tunnel). Tale campo è cifrato se si utilizza il servizio di riservatezza. Nel caso l algoritmo di cifratura richieda un vettore di inizializzazione (IV Initialization Vector) questo è inserito all inizio del payload. Padding: Contiene il padding (variabile byte). Può essere incluso nel pacchetto 30

32 2. IPsec perchè l algoritmo di cifratura richiede che il testo in chiaro sia un multiplo di una certa dimensione oppure per allineare correttamente i campi successivi o ancora per limitare gli effetti di un analisi del traffico basata sulla dimensione dei pacchetti. Pad Length: Contiene la lunghezza del padding. Next Header: Contiene il codice indentificativo del protocollo che segue ESP, per esempio TCP o UDP. Authentication Data: Contiene il valore per il controllo dell integrità (ICV Integrity Check Value) calcolato sull intero pacchetto ESP privo del campo Authentication Data. Il campo è di lunghezza variabile e dipende dalla specifica funzione utilizzata per calcolare tale valore. Nel caso il servizio di autenticazione e integrità non sia attivo, questo campo viene omesso. La posizione dell header e del trailer di ESP, sia in modalità tunnel che trasporto è mostrata in Figura 2.5. Figura 2.5: Header e Trailer EPS per crittografia ed autenticazione dei pacchetti IP 31

33 2. IPsec Figura 2.6: Header AH Il protocollo AH Il protocollo Authentication Header fornisce i servizi di autenticazione, integrità e protezione contro gli attacchi replay. AH autentica, l header AH stesso e l intero pacchetto IP, a eccezione dei campi variabili che, essendo modificabili dai nodi intermedi, non possono essere autenticati. Per IPv4 vengono considerati variabili i campi: type of service, flags, fragment offset, time to leave, header checksum più alcune opzioni il cui elenco completo si trova in [4]. Per IPv6, invece i campi variabili sono: class, flow label, hop limit e tutte le opzioni marcate come modificabili dai nodi intermedi. Si osservi che, in caso di modalità tunnel, viene autenticato sia il pacchetto IP interno che l header IP esterno utilizzato per l incapsulamento. La posizione dell header AH all interno del pacchetto IP è mostrata in Figura 2.7 sia per la modalità trasporto che per quella tunnel. L header AH è illustrato in Figura 2.6, segue una breve descrizione dei campi che lo compongono: Next Header: Contiene il codice indentificativo del protocollo che segue AH (per esempio TCP o ESP) Payload Length: Contiene la lunghezza del solo header AH, in parole di 32 bit, meno 2 32

34 2. IPsec Reserved: Riservato per usi futuri (deve essere impostato a zero) Security Parameters Index: Contiene il security parameters index della SA utilizzata Sequence Number: Contiene il numero di sequenza del pacchetto per una certa SA, ed è utilizzato per prevenire gli attacchi replay. Quando viene stabilita una SA ogni punto terminale inizializza questo contatore a zero e prima di trasmettere un pacchetto lo incrementa (il primo sequence number vale pertanto 1). Se il servizio anti-replay è attivo il mittente non deve consentire che tale campo superi il valore tornando a zero. Il ricevitore gestisce il servizio anti-replay mediante un meccanismo a finestra Authentication Data: Contiene il valore per il controllo dell integrità (ICV, Integrity Check Value). Tale campo ha lunghezza variabile ma deve comunque essere un multiplo di 32 bit. Poichè l header AH deve avere una lunghezza multipla di 32 bit per IPv4 e di 64 bit per IPv6 è possibile inserire un padding. 2.3 I protocolli IKE e ISAKMP Per quanto riguarda la gestione delle chiavi lo standard è attualmente costituito dall Internet Key Exchange versione 1 (IKEv1,[5]). Altre proposte sono in fase di studio come il Kerberized Internet Negoziation of Keys (KINK, [6]) che propone una soluzione per sistemi centralizzati, l Host Identity Protocol (HIP, [7]) una proposta innovativa che tra le altre cose propone un protocollo di scambio delle chiavi nel caso di comunicazione end-to-end, e l Internet Key Exchange versione 2 (IKEv2, [8]) protocollo designato come successore dell attuale standard. Per quanto riguarda l interfaccia tra il protocollo di scambio delle chiavi e il SAD 33

35 2. IPsec Figura 2.7: Autenticazione del pacchetto IP tramite AH. una proposta in tale ambito è costituita dalla PF_KEYv2 [9] che permette ad una applicazione che si sia registrata di interagire con il SAD. L Internet Key Exchange è un protocollo basato sul framework Internet Security Association and Key Management Protocol (ISAKMP, [10]). ISAKMP definisce il formato dei pacchetti e gli scambi per la gestione (creazione, modifica, cancellazione) delle security association e la generazione delle chiavi indipendentemente dalle tecniche crittografiche utilizzate (tipo di chiavi, algoritmi di cifratura, algoritmi di autenticazione, etc.). Il preciso contenuto e il significato di ciascun pacchetto ISAKMP dipendono dal dominio di interpretazione (Domain of Interpretation - DOI) che in tal caso corrisponde al dominio IPsec [11]. L Internet Key Exchange definisce due fasi: nella phase_1 i due nodi si autenticano e negoziano una security association per proteggere la fase successiva. Durante la phase_2, che avviene sotto la protezione della prima, possono essere negoziate molteplici SA per altri protocolli (AH, ESP ed IPcomp). La SA stabilita durante la phase_1, detta ISAKMP SA o IKE SA, è bidirezionale a differenza delle IPsec SA e rappresenta parte dello stato del protocollo, pertanto non viene inserita nel SAD. 34

36 2. IPsec Oltre a definire due fasi, IKE definisce anche due modalità e due scambi aggiuntivi per la corretta gestione delle security association. Durante la phase_1 IKE utilizza l identity protect exchange e l aggressive exchange messi a disposizione da ISAKMP chiamandoli rispettivamente Main Mode e Aggressive Mode. Per lo scambio di phase_2 viene introdotto il Quick Mode. Gli altri due scambi utilizzati (non trattati in questa tesi) sono l informational exchange (presente in ISAKMP) utilizzato per comunicare condizioni di errore e informazioni sullo stato delle SA e lo scambio new group mode che permette a due peer IKE di negoziare l uso di un nuovo gruppo Diffie-Hellman. IKE utilizza UDP (User Datagram Protocol) per il trasporto dei propri messaggi. Lo IANA (Internet Assigned Number Authority) ha assegnato a tale protocollo la porta UDP IKE phase_1 La composizione dei messaggi durante uno scambio di phase_1 varia in base al meccanismo di autenticazione utilizzato. Vengono messi a disposizione quattro modalità di autenticazione dei peer IKE: tramite segreto condiviso, tramite una coppia di chiavi pubbliche per la cifratura in due varianti e infine tramite una coppia di chiavi pubbliche per la firma. A ognuna di queste modalità corrisponde una variante del Main Mode e una dell Aggressive Mode, si hanno, pertanto, otto possibili combinazione di scambi di phase_1. L autenticazione durante la phase_1 fa riferimento all autenticazione dell identità degli hosts e non è da confondere con l autenticazione dell origine dei dati che invece viene offerta da AH e ESP. Il Main Mode è costituito da sei messaggi. Nei primi due vengono negoziati i parametri della IKE SA, nei due messaggi successivi viene effettuato lo scambio Diffie-Hellman per la negoziazione delle chiavi crittografiche. Nel caso di autenticazione tramite una coppia di chiavi per la cifratura (nelle due varianti) vengono comunicate anche le due identità (cifrate), infine negli ultimi due messaggi si trasmettono le identità e la prova di essere in possesso del segreto collegato all i- 35

37 2. IPsec dentità comunicata. Per il Main Mode nel caso di autenticazione mediante segreto condiviso (si veda la Figura 2.8). Nel primo messaggio l iniziatore comunica il proprio cookie nell header ISAKMP (HDR) e la propria proposta per la IKE SA (payload SA), il risponditore replica inserendo nell header ISAKMP il proprio cookie e selezionando una delle proposte fatte dall iniziatore per la IKE SA (payload SA). Nel terzo messaggio l iniziatore invia il valore DH (payload KE) insieme ad un nonce (payload Ni) cioè un valore pseudocasuale utilizzato, tra le altre cose, per la generazione del materiale crittografico. Il risponditore replica in maniera del tutto simmetrica con il proprio valore DH (payload KE) ed un nonce (payload Nr). A questo punto i due interlocutori dispongono di tutte le informazioni necessarie per la generazione del materiale crittografico relativo alla IKE SA, la negoziazione continua pertanto sotto la protezione di tale materiale. Nel quinto messaggio l iniziatore comunica la propria identità (payload IDii) e dimostra di essere a conoscenza del segreto condiviso relativo all identità IDii (payload HASH I), il risponditore, in maniera analoga replica comunicando la propria identità (payload IDir) e la prova di conoscere il segreto associato a tale identità (payload HASH R). La coppia di cookie presente nell header generico ISAKMP viene usato come identificatore univoco di una phase_1. L Aggressive Mode utilizza invece tre messaggi per autenticare le parti, scambiare le chiavi e negoziare la IKE SA al costo di non proteggere le identità e di garantire una minor flessibilità (mostrati in Figura 2.8). Mentre nel primo messaggio del Main Mode, infatti, l iniziatore può comunicare tutti i gruppi Diffie-Hellman supportati in ordine di preferenza e il risponditore sceglierne uno; nell Aggressive Mode l iniziatore deve scegliere un unico gruppo Diffie-Hellman. Nel caso il risponditore non supporti tale gruppo, l handshake dovrà essere terminato e riavviato. Si osservi, inoltre, che poichè dopo l invio del primo messaggio non è stata ancora stabilita una chiave di sessione l iniziatore non può essere sicuro che il ri- 36

38 2. IPsec Figura 2.8: IKE phase_1: Scambio messaggi in modalità Main Mode (sx) e Aggressive Mode (dx) [12]. fiuto del gruppo DH arrivi dal risponditore legittimo (DoS). Durante l Aggressive Mode tutti i messaggi sono inviati in chiaro IKE phase_2 Sotto la protezione di una IKE SA i due interlocutori possono procedere con la negoziazionedi una IPsec SA attraverso un Quick Mode. I punti terminali di tale SA risultano essere gli stessi della phase_1. Non è possibile, attualmente, negoziare IPsec SA i cui punti terminali differiscano da quelli della IKE SA sotto la quale vengono negoziate. Con riferimento alla Figura 2.9, nel primo messaggio l iniziatore invia le proprie proposte per la IPsec SA (payload SA) e un nonce (payload Ni) inoltre può includere anche i payload IDci e IDcr contenenti informazioni relative al traffico 37

39 2. IPsec Figura 2.9: IKE phase_2: Scambio di messaggi in modalità Quick Mode [12]. che si intende proteggere ed il payload KE nel caso si desideri la Pefect Forward Secrecy, l intero messaggio viene autenticato dal payload HASH(1). Nel secondo messaggio il risponditore seleziona una proposta tra quelle fatte dall iniziatore (payload SA), invia il proprio nonce (payload Nr) e include i payload KE e IDcx nel caso l iniziatore li abbia inseriti. L intero messaggio è autenticato mediante il payload HASH(2). L iniziatore risponde con un messaggio di conferma contenente un paylaod HASH(3). Una tale negoziazione ha come effetto quella di stabilire due SA, una per ogni direzione. In un singolo Quick Mode è anche possibile negoziare più SA contemporaneamente inserendo payload SA multipli all interno del primo e del secondo messaggio. L effetto finale di una negoziazione di SA multiple è quello di generare 2 n SA dove n è il numero di payload SA inclusi nel Quick Mode. 38

40 2. IPsec 2.4 Implementazioni di IPsec IPsec può essere implementato in diversi modi: implementazione nativa o Bump In The Code (BITC): richiede l accesso al codice di IP ed è applicabile sia al caso di singoli host che nel caso di secure gateway. implementazione Bump In The Stack (BITS): in questo caso IPsec viene implementato tra IP e i driver di rete. Poichè non richiede l accesso al codice di IP un tale approccio risulta particolarmente utile in caso di sistemi legacy. Viene tipicamente utilizzato negli host. implementazione Bump In The Wire (BITW): in questo caso IPsec viene implementato in un dispositivo esterno in genere dotato di un proprio indirizzo IP. Viene solitamente utilizzato in sistemi militari e in alcuni sistemi di tipo commerciale. 2.5 Gestione ed elaborazione del traffico IPsec Come precedentemente accennato, IPsec distingue tra datagrammi in uscita dal sistema (ovvero diretti verso il livello data-link) e datagrammi in ingresso al sistema (ovvero provenienti dal livello data-link). Per il traffico outbound l elaborazione avviene immediatamente dopo aver effettuato il routing del pacchetto e quindi aver selezionato l interfaccia di uscita, mentre per il traffico inbound il routing avviene successivamente. In una visione a sottostrati del livello IP il sottolivello di routing si trova sopra a quello IPsec Traffico Inbound Per il traffico in ingresso al sistema bisogna innanzitutto ricomporre il datagramma IP nel caso sia stato frammentato. L interfaccia di provenienza del pacchetto seleziona quali database utilizzare per l elaborazione. I campi <indirizzo IP 39

41 2. IPsec Figura 2.10: Elaborazione pacchetti IPsec: Inbound [13] di destinazione, SPI, protocollo> vengono utilizzati come chiave di ricerca della SA all interno del SAD. Se non viene identificata alcuna SA il pacchetto viene scartato, in caso contrario elaborato. Questa fase include anche il confronto dei selettori del pacchetto con quelli presenti nella SA. Nel caso il datagramma sia autentico ma i selettori nel SAD non vengano soddisfatti, il datagramma viene scartato. Si controlla infine di aver applicato l elaborazione necessaria. Tale controllo può essere effettuato o mediante un puntatore dalla SA verso la politica del SPD che ha reso necessaria la sua negoziazione (backpointer) o consultando il SPD e verificando che il puntatore presente nella politica che viene soddisfatta punti proprio alla SA applicata. Il realtivo diagramma di flusso è mostrato in Figura

42 2. IPsec Figura 2.11: Elaborazione pacchetti IPsec: Outbound [13] Traffico outbound Per quanto riguarda il traffico outbound, il routing seleziona l interfaccia di uscita del pacchetto e conseguentemente i database (SPD e SAD) da utilizzare durante l elaborazione (il diagramma di flusso è mostrato in Figura 2.11). Il datagramma viene confrontato contro l SPD alla ricerca di una politica applicabile. Il database viene percorso dalla prima regola fino all ultima e non appena viene trovata una politica la cui parte regola venga soddisfatta viene eseguita la corrispondente parte azione. Nel caso non venga soddisfatta alcuna regola, il datagramma 41

43 2. IPsec Figura 2.12: Elaborazione IPsec in dattaglio: sequenza di operazioni. viene semplicemente scartato. Se si individua una politica adatta viene eseguita la parte azione corrispondente (scartare, inviare in chiaro o applicare IPsec). Se la politica richiede l applicazione di IPsec viene consultato il puntatore associato alla politica di sicurezza che può puntare a nessuna, una o più SA. Nel caso di nessuna SA viene invocato il demone di scambio delle chiavi se presente, al fine di negoziare la security association e tutto il materiale crittografico necessario. Se tale entità non è attiva sul sistema il datagramma viene scartato, in caso contrario, a negoziazione avvenuta, la SA viene posta nel SAD, collegata alla politica del SPD e l elaborazione applicata. Quando la SA individuata è unica non vi sono ambiguità, l elaborazione viene eseguita e il pacchetto viene passato al livello inferiore, mentre nel caso le SA siano multiple è necessario un modo per identificare quale utilizzare. A tal fine il datagramma viene confrontato con i selettori che sono presenti nella SA (sezione selettori). Individuata la security association il datagramma viene elaborato, in caso opposto viene invocato il demone di scambio delle chiavi Elaborazione IPsec dei pacchetti Si focalizza adesso l attenzione sull elaborazione dei pacchetti IPsec per il traffico outbound, antecedente il loro invio allo strato data-link. L interno del blocco Elaborazione IPsec in Figura 2.11 è decomponibile nella azioni espresse in Figura Una volta definita la corretta SA per il determinato pacchetto in analisi, si conosce quale elaborazione è richiesta per proteggere i dati e come dovranno essere, 42

44 2. IPsec Figura 2.13: Mappatura del datagramma IP all interno del protocollo ESP [14]. pertanto, composti l header ed il trailer, p.e. nel caso di ESP, da aggiungere al pacchetto (si veda la Figura 2.13). Le operazioni richieste dal blocco Context Management di Figura 2.12, possono essere elecante di seguito: 1. Estrazione del SPI ed aggiornamento del SequenceNumber nell header ESP; controllo del sequence number rollover (si veda la Figura 2.14). 2. Aggiornamento del contatore IPsec per la data SA (conteggio del numero di pacchetti inviati da quando è stata stabilita una SA, numbero di bytes, time). 43

45 2. IPsec 3. Controllo se l SA ha superato i limiti imposti dal SA LifeTime. In tal caso intraprendere delle azioni per bloccare gli ulteriori pacchetti e provare a ristabilire un nuovo insieme di chiavi per questa SA. 4. Se è usata la crittografia, si deve generare un Initialization Vector (IV) per l algoritmo crittografico (DES, 3DES, AES). 5. Se si usa la modalità Tunnel Mode, gestire i bits del Type of service (TOS) in funzione della politica associata alla data SA. In alcuni casi tali bits sono copiati dall header IP, in altri casi vengono rigenerati nuovamente. 6. Nel caso di modalità Trasport Mode, il campo field nell header IP deve essere aggiornato indicando il nuovo protocollo, sia ESP o AH. 7. Dato che si deve aggiungere l header ed il trailer bisogna aggiornare il campo length dell header IP. Inoltre, avendo modificato l header IP originale, bisogna ricalcolare il checksum. 8. Lo standard IPsec, richiede per ESP, che la lunghezza finale del pacchetto sia multipla di 32 bits, pertanto, bisogna calcolare ed inserire un extra padding nel trailer ESP. In alcuni casi, in aggiunta al precedente, un ulteriore padding è inserito per raccordarsi alla dimensione minima dei blocchi richiesta dall algoritmo crittografico (si veda la Figura 2.15). 9. Infine IPsec permette l aggiunta di un numero casuale di bits di padding per nascondere la reale lunghezza del pacchetto e proteggerne ulteriormente il contenuto. A questo punto, se il pacchetto deve seguire il protocollo ESP, è pronto per la crittografia e l autenticazione. Viceversa, se il pacchetto segue le regole di AH, è necessario mascherare qualsiasi campo variabile prima di autenticare il pacchetto (per maggiori dettagli sui campi si rimanda alla sezione 2.2.7). Dopo di ciò, il pacchetto è pronto per essere crittato, autenticato o entrambi, dipende dal modo d uso. In ESP solo una porzione del pacchetto viene crittata, e una larga 44

46 2. IPsec extractspi evspiinserted: calculatesequencenumber extractantireplay extractsequencenumberfromsa [else]/overflow=true: [anti_replay]: [else]: evseqnumextracted: rollcounter create_newsa [seqnumber<boundseqnum]: evcounterrolled: evnotfinished/espprotocol.gen(new evsequencenumberoverflow());: incrementsequencenumber evsnincremented: concatsn2headeresp evsnadded2headeresp: Figura 2.14: Diagramma UML degli Stati per la creazione dell Header ESP. fetta viene autenticata (dettagli alla sezione 2.2.6). In AH, l intero pacchetto è autenticato (si veda sezione 2.2.7). Il processo esposto è schematizzato tramite un diagramma UML degli stati in Figura 2.16, in cui si è supposta una modalità Tunnel per IPsec con uso di ESP per crittografia e autenticazione. Al termine del processo, il pacchetto IP è cresciuto in dimensione dovuto all aggiunta dell header ESP/AH e del trailer, pertanto, l operazione susseguente è la frammentazione. La frammentazione è un processo necessario dato che IP impone una dimensione massima dei pacchetti che possono essere accettati lungo ogni canale di comunicazione (MTU). In alternativa o in supporto alla frammentazione si può operare un IPcomp del pacchetti [2] dato che i livelli sottostanti (data-link) non sono in grado di effettuare un frazionamento adeguato degli IP a causa della crittografia. Si noti come alcune delle operazioni descritte e raffigurate in 2.16, potrebbero efficientemente essere eseguite in parallelo su dispositivi hardware dedicati. 2.6 IPSec in azione Le reti private virtuali (VPN) IPsec si presta per essere usato da molte applicazioni; fornisce, infatti, servizi a livello di rete e pertanto è del tutto trasparente ai livelli superiori. Attualmente 45

47 2. IPsec putpadding wait startesptrailer: checkalgorithmcontent evcodealgo: extractpaddingfromalgorithm evcodingselected: countlengthofusefuldata evpaddingdone: InsertPadLength evdefaultcoding: evcodingselected: evcountingdone: evpadlengthinserted: applydefaultpadding extractminsize putnextheader computepaddinglength evminsizeextracted: evpadlencomputed: [else]/diff=0: [else]: [defaultcoding]/i=1: computepaddingbytes [lendata<minsize]: evdiffcomputed: encryptionusepadding applyalgorithmcoding applydefaultcoding evdiffcountedenc: insertpadding checkforalignement evalgocodingapplied: evadded2vector: [startpadding=false]: evdiffcountedal: [i<padlength]/i++: [ese] / i=1 [else]/startpadding=false: addpadding [else]/startpadding=true: [randomcoding]/i=1: applyrandomcoding applyzerocoding [diff=0]: notaddpadding evadded2vectorran: [i<padlength]/i++: evadedd2vector: [i<padlength]/i++: [else]/startpadding=false: [else]/startpadding=false: Figura 2.15: Diagramma UML degli stati per la creazione del Trailer ESP. IPsec costituisce uno dei più efficaci mezzi per costruire le reti private virtuali. Le reti private virtuali (VPN, Virtual Private Networks), permettono di collegare tra loro delle reti locali tramite l infrastruttura Internet, garantendo però sicurezza (riservatezza, integrità... ) al traffico che viaggia sulla rete esterna. Utilizzando IPsec questo è possibile: è sufficiente inserire nelle reti locali dei secure gateway attraverso i quali far passare tutto il traffico diretto alle altre reti, e creare dei tunnel IPsec tra i secure gateway. In questo modo il traffico diretto da una rete all altra viaggia su Internet ma è protetto dal tunnel IPsec, il tutto senza che gli host, né tantomeno le applicazioni, debbano preoccuparsene. Si ha così, virtualmente, un unica rete privata che sfrutta l infrastruttura della rete pubblica. Un esempio di questa architettura è illustrato in Figura Le VPN sono un caso tipico in cui si può avere la sovrapposizione di vari livelli di IPsec. Si supponga che il tunnel tra i secure gateway utilizzi ESP con cifratura e integrità: allora tutto il traffico che fluisce tra di essi verrà cifrato e autenticato. In qualche caso si potrebbe però volere anche sicurezza end-to-end, e impostare IPsec tra due host appartenenti a reti diverse, per esempio utilizzando ancora ESP. 46

48 2. IPsec insertoriginalippacket evextractpayload evpayloadextracted: putpayload payloadinserted: computeesptrailer evesptrailercomputed: concatesptrailer evesptrailerinserted: encryption concatnewipheader evencryptiondone: evnewipheaderinserted/packet_finished=tre;before_new_header=false;: [itsnewipheader.evnewipheaderdone()]: evsequencenumberoverflow: putheaderesp extractauthalgo evheaderespcomputed: computenewipheader [before_new_header=true]: putipheader evskipdone: skipauthentication headerespinserted: concatheaderesp evconcatdone/before_new_header=true;packet_finished=false;: concatauthfield evauthdone: authenticationesp evskippingdone/before_new_header=true;packet_finished=false;: [auth_algorithm="null"]: [auth_algorithm!="null"]: Figura 2.16: Diagramma UML degli stati per l elaborazione IPsec in modalità Tunnel. Allora tutto il traffico tra questi due host verrebbe elaborato da IPsec sia sugli host, dove verrebbe cifrato/decifrato una volta, sia sui gateway, dove sarebbe cifrato/decifrato un altra volta. In questo caso si ha quindi una sovrapposizione di SA, con end-point diversi. Con riferimento alla Figura 2.17, vediamo cosa succede quando un host vuole comunicare con altro host appartenente ad una rete differente. Un host sulla prima rete (ad esempio con lindirizzo ) che vuole comunicare con un host sulla seconda (ad esempio ) si limiterà ad inviare il relativo pacchetto IP senza alcun particolare accorgimento. Tale pacchetto arriverà al secure gateway della prima rete, che si accorgerà che è destinato alla seconda: il gateway cifrerà quindi il pacchetto e lo incapsulerà in nuovo pacchetto IP, che avrà come mittente il suo indirizzo pubblico (x.y.z.w in figura) e come destinazione l indirizzo pubblico del secondo gateway (a.b.c.d). Tale pacchetto viaggerà normalmente su Internet, ma chi lo intercettasse vedrebbe solamente che è in corso una comunicazione IPsec tra i due gateway, mentre non conoscerebbe né i contenuti della comunicazione, né il protocollo utilizzato (a livello trasporto e applicazione), né il mittente e il destinatario reali della comunicazione (l intero pacchetto IP originale è inviato cifrato). Quando il pacchetto arriverà al secondo gateway, questo ne controllerà l autenticità e l integrità e decifrerà la porzione cifrata ricostruendo così il pacchetto originale, che inoltrerà poi verso la destinazio- 47

49 2. IPsec Figura 2.17: La rete privata virtuale con IPsec [13]. ne. L host sulla seconda rete riceverà quindi il pacchetto così come è stato inviato dal mittente originale: gli host sulle due reti possono dunque comunicare tra loro senza conoscere alcun dettaglio riguardo al tunnel IPsec (di cui possono anche ignorare l esistenza). Si ha così, virtualmente, un unica rete privata che sfrutta l infrastruttura della rete pubblica, dato che il tunnel IPsec appare alle macchine sulle due reti locali come un unico link virtuale La rete Road Warrior Il road warrior si può vedere come un caso degenere della VPN, in cui da una parte si ha un singolo host anziché una rete: un esempio tipico è quello in cui una persona vuole accedere alla rete aziendale trovandosi all esterno, per esempio a casa propria oppure in viaggio, tramite una connessione sicura, in modo da essere autenticato e da proteggere le informazioni in transito. La particolarità del road warrior rispetto alla VPN è che in questo caso in genere l host esterno ha un indirizzo IP dinamico e quindi non noto a priori, al contrario di quanto avviene con i secure gateway che hanno di solito un indirizzo IP statico e noto in fase di configurazione. 48

50 Capitolo 3 Stato dell arte 3.1 Introduzione Performance e sicurezza sono le caratteristiche sempre più richieste alla rete globale. Avere comunicazioni che siano al tempo stesso sicure e veloci richiede security processor sempre più efficaci. Gli utenti, dall altra parte, non vogliono solo sicurezza e velocità, chiedono anche convenienza in termini di rapporto costo/efficienza. La combinazione di network processor e security processor dedicati è la soluzione ad elevato rapporto costo-efficacia rispetto ad avere un singolo (o, probabilmente, multipli) general-purpose processor. Un semplice network processor (NP), in uno scenario in cui la velocità delle rete sia piuttosto bassa, è in grado di sobbarcarsi il lavoro extra richiesto dalla crittografia. Viceversa, ad elevate velocità, il processo di crittaggio non può essere eseguito solo a livello software; un acceleratore hardware è, pertanto, richiesto. Una soluzione è data da un security processor dedicato, da affiancare al NP o direttamente alla CPU del sistema, in base allo scenario d uso. I security processor, o acceleratori crittografici hardware, non hanno tutti le medesime caratteristiche. Numerose sono le alternative offerte dal mercato. Un analisi comparativa non è così ovvia come ad esempio quella che si avrebbe confrontando i soli algoritmi crittografici. 49

51 3. Stato dell arte In questo capitolo vengono presentati gli acceleratori hardware. Una descrizione generale dell architettura e delle funzionalità di tali dispositivi ottenuta attraverso un lavoro di ricerca condotto in ambito commerciale. La rassegna presentata nelle sessioni successive, è stata necessariamente filtrata per concentrarsi sulle problematiche inerenti il lavoro di tesi. Tra tutti gli acceleratori hardware in commercio, l attenzione è posta su architetture che andranno a costituire soluzioni di supporto, come schede PCI, o come processori crittografici da installare in sistemi più complessi. I dati raccolti sono stati tratti dai siti internet delle aziende, ragione per cui in alcuni casi sono tecnicamente poco dettagliati. Tra la multitudine di aziende si sono selezionate le maggiori produttrici nel settore, costantemente aggiornate e considerate promotrici di innovazione. 3.2 Broadcom I processori Broadcom [15] si basano su una architettura proprietaria e scalabile per ottenere il massimo delle performance dagli algoritmi crittografici usati nelle VPN, con una velocità di processamento compresa tra pochi Megabits al secondo a multi-gibabits al secondo. Le tipoligie di processori per la sicurezza si suddividono in due macro categorie, differenziati in base al tipo di protocollo che implementano. Si hanno acceleratori per IPsec o per SSL. Per il tema trattato in questa tesi, rilevante è la famiglia di prodotti per IPsec identificati dal codice: BCM58xx. Vediamo nei dettagli. La soluzione BCM5841 (la cui foto è in Figura 3.1) è l ultima proposta dalla Broadcom. Parametri chiave della nuova versione riguardano elevata flessiblità di throughput al fine di addattarsi ad ogni scenario di rete. E disponibile in quattro versioni, 600 Mbps, 1.2 Gbps, 2.4 Gbps e 4.8 Gbps, rispettivamente. Le caratteristiche principale dichiarate sono riassumubili in: 50

52 3. Stato dell arte Figura 3.1: Processore Broadcom 5841 Performance e modalità operativa: 4.8 Gbps di throughput modalità AES-CBC e AES-CTR supporto completo per AH e ESP Interfaccia di comunicazione veloce e flessibile POS-PHY livello 3 interfaccia FIFO Supporto per un numero illimitato di SAs via in-band keying Bassi consumi di potenza, 0.18µm, con 1.8 V di livello operativo 51

53 3. Stato dell arte Figura 3.2: Applicazioni VPN che usano il Broadcom Corrent Figura 3.3: Corrent CR7110, schema a blocchi Attualmente la corrent [16] produce una serie di chip per la sicurezza appartenenti alla famiglia dei CR7xxx. Punta di diamante della famiglia, in ambito IPsec è il processore CR7110 il cui schema a blocchi è mostrato in Figura 3.3. Caratteristiche tecniche del CR7110 sono riassumibili in: Processore IPsec ad elevate performance: 1 Gbps anche con dimensione dei pacchetti piccola Full-duplex POS-phy 3 Streaming Interface a 104 MHz 52

54 3. Stato dell arte On-chip Modulo-Exponentiation 512, 768, 1024, 1536, 2048 dimensione dei blocchi di bit supportata RSA a 1024 bit (exponent, base, modulus) con oltre 625 chiavi al secondo in modalità CRT Oltre 500 connessioni/sec IKE Main Mode Interfaccia di comunicazione 32/64-bit, 33/66 MHz PCI Interfaccia Dual 64-bit, 100 MHz ECC SDRAM (DDR) per immagazzinamento delle chiavi e Security Associations su memorie esterne Supporto per oltre 1M di Security Associations simultanee in modalità tunnel. Algoritmi crittografici supportati: ARC4, DES, 3DES, and AES Algoritmi autenticazione supportati: HMAC-MD5 e SHA-1 IPsec Packet Processing Engine (PPE) on-chip: Header parsing Security Associations lookup Header e trailer manipulation Back-channel ICMP source lookup Generatore di numeri casuali conforme allo standard FIPS-140-2: True digital 3-grade non-deterministic. Un esempio di uso del chip CR7110 all interno di una scheda PCI è in Figura 3.4. Si noti la presenza del NP e del posizionamento Off-line del chip. 53

55 3. Stato dell arte Figura 3.4: Esempio di uso del chip CR7110 all interno di una scheda PCI 3.4 Hifn Figura 3.5: Hifn HIPP III 8350 Security Processor I processori crittografici offerti dalla Hifn [17] costituiscono la serie 8xxx. In questa sede si esaminerà l HIPP III 8350, gioiello della casa costruttrice con 4 Gbps di throughput. L 8350 fornisce una soluzione completa, per l elaborazione in-line, atta ad ottimizzare le performance di IPsec e IKE, combinando elaborazione delle politiche inbound e outbound, SA loohup, SA context handling e manipolazione dei pacchetti tutto in un singolo chip mostrato in Figura 3.5. Caratteristiche del modello 8350 sono: 54

56 3. Stato dell arte Figura 3.6: Diagramma a blocchi del chip Hifn HIPP III 8350 Single-core, soluzione a basso costo: 4 Gbps IPsec performance 1 Million Pachetti al second, back-to-back SA variation Scalabile con altri chip per per applicazioni che supportino porte ad 1 Gbps Elaborazione in-line (si veda la Figura 3.7): Protocollo IPsec e algoritmi crittografici In-line col flusso di dati Ottimizzato per modalità site-to-site IPSec VPN Supporto On-chip per l elaborazione richiesta da IKE Soluzione completa per IPsec e IKE che facilita l implementazione di sistemi basati su IPsec 55

57 3. Stato dell arte Figura 3.7: Esempio di uso di Hifn HIPP III 8350 in una scheda PCI. Ottimizzato per modalità site-to-site con: 512 on-chip policy entries Supporto per oltre 200 SAs on-chip Oltre 256K SAs attraverso immagazzinamento off-chip in SDRAM Supporto completo per l intero protocollo IPSec : Tunnel, transport modes, ESP eah AES (CBC & CTR), DES/3DES, SHA-1, MD5, AES-XCBC Specifiche:.13µ process, 324 LBGA (19mm square) Consumo di potenza inferiore a 1.75W 56

58 3. Stato dell arte 3.5 IBM Figura 3.8: IBM 4753 Cryptographic Coprocessor La soluzione proposta da IBM [18] per accelerare i processi crittografici si basa principalmente su architetture PCI da includere all interno dei server, fornendo, come valore aggiunto, anche una protezione fisica dell acceleratore hardware conforme allo standard FIPS PUB L acceleratore hardware dell IBM è il modello Il prodotto è mostrato in Figura 3.8 mentre il suo schema a blocchi, ad alto livello, è in Figura L acceleratore hardware 4753 è costituito dal chip IBM UltraCypher Engine il quale è in grado di eseguire gli algoritmi crittografici richiesti da IPsec (si veda la Figura 3.9). Riassumendo le funzionalità del 4753 possiamo dire che: Il core del modulo è una CPU 486 con sistema operativo proprio real time. Throughput di 188Mbit/s con DES in modo CBC con blocchi di 4 Mb Supporto per DES, DES3, RSA (up to 2048-bit modulus), DSA, SHA-1, MD5, MD2, SSL3 57

59 3. Stato dell arte 3.6 Motorola/FreeScale Figura 3.9: IBM 4753 Module La casa produttrice Motorola, ha istituito un azienda, la FreeScale Semiconductor [19], alla quale ha affidato la produzione dei chip per la sicurezza. La famiglia dei processori per la sicurezza prende il nome di S1 Family il cui MPC190 è il prodotto d eccellenza. Il processore MPC190 è ottimizzato per eseguire efficentemente tutti gli algoritmi associati con IPsec, IKE, WTLS/WAP e SSL/TLS; è l unico processore sul mercato in grado di accelerare anche gli algoritmi matematici delle Elliptic Curve, i quali sono particolamente importanti per la sicurezza delle comunicazioni 58

60 3. Stato dell arte Figura 3.10: Schema a blocchi dell IBM 4758 Cryptographic Coprocessor wireless. Tecnicamente il MPC190 ha le seguenti caratteristiche: 6 unità per l esecuzione di chiavi publiche: RSA, ECC, Diffie-Hellman 3 unità per l autenticazione ognuna in grado di eseguire: MD-4, MD-5, SHA-1 3 unità DES e 3DES 1 unità ARC4 1 unità per il generatore di numeri casuali 32bit address/64 bit data, 66MHz, PCI 2.2 compliant External Bus Interface, con logica Master/Slave l 9 Crypto-Channels, con supporto per multicommand descriptor chains 1.8v supply, 3.3v I/O, 252MAPBGA Performance con IKE: 59

61 3. Stato dell arte Figura 3.11: Diagramma a blocchi del MPC bit Diffie-Hellman connessioni al secondo 155 bit ECC connessioni al secondo Performance Crittografia 1 : 3DES-HMAC-SHA Gbps DES 1.13 Gbps 3DES.68 Gbps MD5.97 Gbps Esegue crittografia/autenticazione in singolo passo 1 Le stime sono state raccolte tenendo conto delle seguenti operazioni: lettura dalla memorie dei data/key/context; elaborazione interna in MPC190; scrittura dei data/context nella memoria. Lettura e scrittura avvengono tramite interfaccia PCI. 60

62 3. Stato dell arte 3.7 Sun Figura 3.12: Sun Crypto Acceleretor 4000 board Anche la Sun [20] contribuisce coi proprio prodotti al mercato degli acceleratori hardware con il suo Sun Crypto Accelerator 4000 board (in Figura 3.12) per le reti Ethernet Gigabit, che supporta sia IPsec che SSL. Tra le altre caratteristiche troviamo: Session establishment rate: oltre 4300 operazioni al secondo Bulk encryption rate: oltre 800 Mbps Compatibile con RSA a 2048-bit Velocizza di oltre 10 volte il processo di crittaggio 3DES Progettato per rispettare lo standard FIPS Level 3 Immagazzinamento delle chiavi private e loro gestione in memoria sicura Riconfigurazione dimanica sui server Sun 61

63 3. Stato dell arte Protocolli di sicurezza supportati: IPsec per IPv4 e IPv6, includo IKE SSLv2, SSLv3, TLSv1 Algoritmi crittografici ottimizzati: ESP (DES, 3DES) crittografia; ESP (SHA1, MD5) autenticazione; AH (SHA1, MD5) autenticazione Configurabile sia come in-line (esegue DES, 3DES, SHA1, MD5) che offline (esegue solo per DES e 3DES, il resto in software) Consumi di potenza stimati intorno a V e V Infine, l acceleratore crittografico della Sun è disponibile in due versioni, una per le reti via cavo, e l altra per le reti in fibra ottica. 62

64 Capitolo 4 Approccio metodologico al design degli acceleratori hardware 4.1 Introduzione Per comprendere la struttura e l utilità degli acceleratori hardware è necessario considerare diversi aspetti: come sono connessi con il sistema? Come sono fatti? Quali sono i modi d uso? Quanto lavoro svolgono e come? Dalla ricerca condotta nel mercato degli acceleratori sono sorte differenti architetture con svariate funzionalità, andando da semplici chip a complicati processori comprensivi di memorie interne e chip ausiliari. Di seguito vengono descritti gli acceleratori hardware attraverso differenti livelli di analisi per offrire una visione macroscopica del sistema acceleratore, che sia il più possibile teorica e si distacchi da una specifica realizzazione in commercio. L approccio metodologico innovativo proposto per il design degli acceleratori è condotto ad alto livello e comprende l osservazione dell acceleratore hardware da tre punti di vista differenti: Panoramica esterna 63

65 4. Approccio metodologico al design degli acceleratori hardware Struttura interna Visione d uso Nei paragrafi successivi si forniscono maggiori dettagli circa l analisi svolta a partire dallo stato dell arte. Per ogni sezione verrano presentati gli aspetti tecnici adottabili in fase di design di un acceleratore hardware, seguiti da relativi commenti. Infine, sono proposte delle metodologie di valutazione di un acceleratore crittografico hardware. Si tratta di un criterio ad uso pratico suggerito da [21], e dello standard ufficiale di certificazione FIPS PUB 140-1, della NIST (National Institute of Standards and Technology [22]), di cui si darà solo dei brevi cenni. 4.2 Metodologia di design per l acceleratore Panoramica esterna Si vuole mostrare l acceleratore come visto dall esterno. L osservazione è posta su due aspetti in particolare: il posizionamento dell acceleratore sia riferito al sistema utilizzatore che anche rispetto al flusso di dati; e su quale sia l interfaccia fisica di comunicazione tra acceleratore e sistema Design generale e posizionamento del modulo Un acceleratore hardaware è un dispositivo dotato di porte di ingresso e di uscita per i dati e le istruzioni di controllo. Alcuni acceleratori hanno canali dedicati per ogni flusso, distinguendo quello funzionale da quello di controllo (si veda la Figura 4.1). Inoltre, si può ancora suddividere il flusso dati in diversi input facenti capo a pacchetti, chiavi crittografiche, security associations, etc.; analogamente le istruzioni di controllo possono dar vita a ingressi separati per istruzioni di inizializzazione, management, esecuzione, reset, etc.; invece, solitamente l output è costituito da un unica uscita dipendente da come è realizzato l acceleratore hardware, e 64

66 4. Approccio metodologico al design degli acceleratori hardware Input Acc Output Pacchetti dati Chiavi crittografiche Security Associations (SA) Control Inizializzazione Management Esecuzione Reset (Dipende dall implementazione) Pacchetto Criptato Figura 4.1: Il modulo Acceleratore (ACC) quale ruolo svolge all interno del processo di protezione dei dati.una tipica uscita dell acceleratore hardware è il pacchetto crittato, comprensivo di header. E immediato chiedersi dove si installa l acceleratore hardware e come interagisce con il sistema ospitante (host). Il modulo è collegabile all host in modi differenti. Le possibili connessioni fanno riferimento alla presenza o meno di un NP nell host, ed all architettura stessa dell acceleratore hardware. In particolare, si distinguono due tipologie di connessione con l host che prendono il nome di: Fabric Side Connection (FSC) Network Side Connection (NSC) rispettivamente, alla connessione diretta con l host, o con il NP 1. Il posizionamento all interno del sistema deve inoltre tenere conto di come l acceleratore hardware è distribuito rispetto al flusso dei dati, rappresentato tipicamente da pacchetti. Le definizioni che si danno in questo ambito contraddistinguono due tipologie di acceleratori hardware [21, 23]. 1 Per termine connessione si intende il posizionamento dell acceleratore hardware all interno del sistema, facendo riferimento a chi controlla e fornisce dati all acceleratore hardware. 65

67 4. Approccio metodologico al design degli acceleratori hardware PHY MAC ACC Fabric Proc (FP) Shared Resource Figura 4.2: Fabric Side Connection Inline In-line al flusso di dati Off-line al flusso di dati (o anche Look-aside Mode) Le alternative possibili per l installazione di un acceleratore hardware sono mostrate nelle Figure 4.2, 4.3, 4.4, 4.5. La linea tratteggiata, visibile in ogni architettura, delimita l area in cui i dati vengono elaborati applicando il protocollo di sicurezza. Il flusso di dati è inteso in ingresso dalla rete tramite l interfaccia di livello fisico PHY_MAC. Le porte di ingresso/uscita di ogni modulo, acceleratore o processore, sono raffigurate tramite blocchi rettangolari per evidenziare la necessità di un opportuna interfaccia di interconnessione tra i moduli. Nel caso di posizionamento Fabric Side, si osservi la presenza del blocco Shared Resource il quale identifica le risorse di sistema condivise dai moduli, come, p.e., la memoria del sistema host. L uso delle risorse condivise è prerogativa dei sistemi Fabric Side in quanto, l acceleratore hardware, in questi casi, è un chip supplementare da aggiungere al sistema. Nelle Network Side Connection le risorse condivise sono assenti in quanto tipicamente accluse all interno del NP; in questi casi, l acceleratore hardware è progettato insieme al NP e, solitamente, gli viene delegato un compito specifico, p.e., la crittografia dei dati. 66

68 4. Approccio metodologico al design degli acceleratori hardware PHY MAC ACC Fabric Proc (FP) Shared Resource Figura 4.3: Fabric Side Look-aside Mode (Off-line) PHY MAC ACC NP Fabric Side Figura 4.4: Network Side Connection In-line Tipologie di posizionamento, pro e contro Nello schema In-line tutti i pacchetti provenienti dall esterno, p.e. da una porta di rete, attraversano comunque l acceleratore hardware, al quale spetta il compito di individuare se devono essere processati al suo interno o lasciati passare oltre. Nel secondo caso, modalità Off-line, i pacchetti ricevuti sulla porta di rete, sono ridiretti al dispositivo hardware solo se ne è richiesta la protezione dei dati. Ovviamente adottare una soluzione In-line offre il vantaggio di poter processare i pacchetti crifrati immediatamente al loro arrivo, evitando che passino per un pre-processing dal NP e velocizzando di conseguenza il processo nel suo 67

69 4. Approccio metodologico al design degli acceleratori hardware PHY MAC ACC NP Fabric Side Figura 4.5: Network Side Connection Look-aside Mode (Off-Line) complesso. Dall altro lato, si intusce che una soluzione In-line richiede un design congiunto sia del NP che dell acceleratore hardware o, nel migliore dei casi, la possibilità di introdurre sistemi ponte per l interfacciamento dei due processori. Bridges che inevitabilmente appesantiscono il data path con possibile degrado delle prestazioni complessive. L acceleratore hardware, dal canto suo, per poter supportare l intero processamento dei pacchetti, dovrebbe poter disporre di parecchi moduli supplementari che esplitino le farie funzioni richieste dal protocollo IPsec: analisi dell header, autenticazione, crittaggio, etc.. Si conclude che, sebbene l In-line processing rappresenti la scelta consigliabile, è anche quella che richiede ingenti risorse spese per la progettazione del sistema, l interconnessione, e la realizzazione di complessi chip. L Off-line processing lascia aperta la possibilità di avere un acceleratore hardware fisicamente situato su un altra scheda, o su chip facilmente installabile sull esistente struttura. Lo svantaggio di un architettura simile, in molti casi, è connesso con il bus di comunicazione tra NP e acceleratore hardware, il quale risulta essere un fattore limitante per le prestazioni. Per tale motivo, spesso si utilizza una struttura con chip Off-line in sistemi tipicamente Fabric Side, delegando all acceleratore hardware il semplice compito di crittaggio/decrittaggio e lasciando la 68

70 4. Approccio metodologico al design degli acceleratori hardware restante parte di IPsec al FP. In questo modo si riduce il traffico transitante sul bus ma si accresse quello per istruzioni di controllo e gestione da/per l acceleratore hardware, inoltre, aumenta il carico di lavoro svolto dal FP nel protocollo di sicurezza. La flessibilità di installazione e gestione dell acceleratore hardware, controllato via software dal FP (tipicamente general-purpose), rappresenta un buon punto di forza a vantaggio della soluzione Off-line, anche se può essere considerata una scelta di design di comodo, in cui non si decentra il processo di sicurezza dei dati, ma lo si migliora a pezzi, con il FP sovraccaricato del lavoro restante. Le considerazioni esposte sulla tipologia di posizionamento del acceleratore hardware rispetto al flusso di dati valgono, con i dovuti adattamenti, sia per architetture NSC che FSC. Si può, infatti, osservare che l architettura Fabric Side, è simile alla Network Side, con la differenza che il sistema, in questo caso, non possiede un NP, pertanto il compito di processare i pacchetti viene affidato al general-purpose fabric processor (FP). L acceleratore hardware, di conseguenza, è un modulo progettato, in toto, per installarsi all interno del host, p.e., come scheda PCI apposita. Network Side Connection prevede, invece, che l acceleratore hardware sia inteso come chip supplementare all interno del design del NP Interfaccia fisica di comunicazione Per completare il quadro tecnico sulla panoramica esterna, vengono fornite informazioni circa il tipo di interfaccia di comunicazione usata dall acceleratore hardware [24, 25, 26]. Le alternative in commercio coprono quasi tutto l insieme di tecnologie utilizzabili in pratica. Di seguito è stilato un elenco delle soluzioni adottabili e comunemente in uso, distinte per tipologia di dato a cui fanno riferimento (si veda la Tabella 4.1). Per maggiori dettagli si rimanda alla letteratura specifica [27]. L importanza dell interfaccia di comunicazione è fondamentale. L acceleratore hardware necessita di un continuo flusso di dati ed istruzione da e per il processore dell host (NP o FP). Spesso il canale di comunicazione rappresenta un 69

71 4. Approccio metodologico al design degli acceleratori hardware DATA I/F CONTROL I/F 8xx or 82xx local bus Streaming bus 10/100 Base T PCI 32/64 bit 33/66 Mhz PL3 ARM 32 bit PL4 PCI-X 64 bit 100 MHz Hyper Transport GbE Tabella 4.1: Interfacce di comunicazione per un generico acceleratore hardware fattore limitante per le prestazioni del sistema. L obiettivo nell uso o nella progettazione delle interfacce è quello sia di aumentarne la capacità, in termini di banda di trasmissione, sia di ridurre il numero di interazioni tra acceleratore hardware e host. Solitamente, dispositivi progettati per ottenere elevate performance utilizzano, tipicamente, due interfacce, una per il flusso di dati da crittare/decrittare, e l altra per scopi di puro controllo. L architettura ad una singola interfaccia è tipicamente usata in scenari in cui la gestione delle applicazioni e dei dati è comunque decentralizzata sull host. Resta, comunque preferibile, separare fisicamente i due flussi, dati ed istruzioni, al fine di evitare processi concorrenti sul canale di comunicazione, anche dovuti, p.e., ad altre risorse di sistema che condividono il canale stesso. Per rendersi conto che il canale di comunicazione rappresenta un collo di bottoglia delle performance, si pensi al fatto che le interfacce tipicamente usate in commercio prevedono l uso del PCI e PCI-X. In teoria la banda disponibile per un PCI (66MHz, 64 bit ) è di 4.2 Gbps, anche se, in pratica, si stima essere di circa 1.2 Gbps in entrata ed uscita dal chip. Se, inoltre, il bus è condiviso le prestazioni non possono che peggiorare [21]. 70

72 4. Approccio metodologico al design degli acceleratori hardware Struttura Interna Una volta inquadrato il chip all interno dell host, si deve progettare il chip specificando i componenti del modulo e quali funzioni l acceleratore hardware deve essere in grado di svolgere. La domanda alla quale si tenterà di rispondere in questa sezione è: Come è fatto l acceleratore hardware al suo interno?. La comprensione dell architettura interna dell acceleratore hardware è legata ad IPsec, ovvero quanto lavoro richiesto dal protocollo è svolto dall acceleratore hardware e quanto invece rimane al processore dell host. Il livello di implementazione, e la profondità dei dettagli, del protocollo IPsec determinano la complessità dell acceleratore hardware. Prima, quindi, di rispondere alla domanda sul Com è? ci si deve chiedere Cosa deve svolgere? l acceleratore hardware del protocollo IPsec Design dell architettura, approccio multi-livello Come descritto nel capitolo 2 dedicato ad IPsec, il protocollo risulta essere complesso e prevede parecchie fasi, fra loro, spesso, distinte nettamente (p.e., scambio delle chiavi, autenticazione, crittografia). Questa modularità si riflette nelle scelte di design della struttura interna di un acceleratore hardware. Volendo schematizzare il problema del design, si conviene che i fattori da tenere in considerazione sono: Livello di implementazione di IPsec (STACK) Livello di implementazione funzionalità applicative (APPLICATION) Livello di complessità del chip (CORE) Il livello STACK Il primo livello, STACK, si riferisce al protocollo IPsec nelle sue specifiche. Dallo STACK IPsec le operazioni che si possono estrarre, in ambito crittografico, e che generalmente offrono un buon partizionamento hardware/software sono di seguito elencate: 71

73 4. Approccio metodologico al design degli acceleratori hardware Algoritmi di scambio chiavi: RSA, etc. Algoritmi di autenticazione: HMAC-SHA-1, HMAC-MD5, etc. Algoritmo di compressione: IPComp Algoritmi crittografici: DES, 3DES, AES, etc. Il processing dei pacchetti inteso come elaborazione degli header (e trailer, nel caso ESP) non è stato incluso nell elenco menzionato, in quanto non direttamente connesso con operazioni crittografiche 2. Gli algoritmo sopra elencate trovano parecchie realizzazioni in pratica ed in letteratura [28]. Inoltre le implementazioni di IPsec suggerite da [1] sono: IPsec nativo con IP Bump-in-the-stack (BITS) Bump-in-the-wire (BITW) Per maggiori spiegazioni, si riveda il capitolo 2 su IPsec Il livello APPLICATION Con il termine APPLICATION si vuole, invece, identificare l insieme di funzionalità svolte da un acceleratore hardware. In [25] si fa riferimento a cinque strati. Ogni strato rappresenta un insieme di funzioni adibite alla sicurezza. Lo strato 0 è il riferimento. Gli strati classificano un acceleratore hardware in base a quanto lavoro/funzionalità, del protocollo di sicurezza, esso svolge. Per intenderci, nello strato 0 troviamo un acceleratore hardware nullo, ovvero, tutte le funzionalità per la sicurezza si trovano nell host. Si riporta l elenco degli strati, con una breve descrizione delle funzionalità ad essi connesse, per maggiori dettagli si veda [25]: 2 Analogamente per l interrogazione dei database SAD e SPD, considerata un operazione a livello application 72

74 4. Approccio metodologico al design degli acceleratori hardware STRATO 0 : Zero Tutte le funzionalità applicative si trovano nell host. L acceleratore può però eseguire operazioni puntuali dello stack IPsec, come, p.e., la crittografia. STRATO 1 : Private Key L acceleratore hardware implementa le funzioni di gestione delle chiavi private. STRATO 2 : Session Key Le funzioni inerenti le chiavi private/pubbliche e le gestione della sessione sono spostate dall host all acceleratore hardware. STRATO 3 : Metadata anche le funzionalità connesse con l elaborazione crittografica sono passate all acceleratore hardware STRATO 4 : Command Verification A questo strato, l acceleratore hardware offre servizi supplementari alla sicurezza come, p.e., la conferma, da parte dell utente, e quindi la verifica dei comandi inviati dall host all acceleratore hardware. STRATO 5 : App-level Functionality L acceleratore hardware possiede sistemi per l input e output, e meccanismi per la memorizzazione dei dati. Lo strato 5 rappresenta l estremo superiore di un acceleratore hardware, in cui è praticamente simile ad un general-purpose, anche se dedicato al solo protocollo di sicurezza Il livello CORE Infine, con CORE si classificano gli acceleratore hardware in base all architettura fisica che li compone. Un acceleratore hardware può essere costituito da [29]: single core multi core 73

75 4. Approccio metodologico al design degli acceleratori hardware multi core, standalone 3 La prima soluzione è quella più semplice, e solitamente si riferisce ad ASIC progettati col solo compito di svolgere, p.e., l algoritmo crittografico AES. Per la seconda e terza soluzione si parla di acceleratori hardware costituiti da parecchi moduli interni ognuno specializzato in un processo ed interconnessi tra loro per svolgere parecchie funzioni, p.e., come la gestione del protocollo di scambio delle chiavi. Gli acceleratori hardware in commercio sono tipicamente di questo tipo. Ovviamente l acceleratore hardware può avere al suo interno delle risorse ausiliarie, come, ad esempio, memorie protette, oppure far riferimento alle risorse dell host stesso Rappresentazione grafica La metodologia di approccio al design interno di un acceleratore crittografico hardware, esposta precedentemente, è anche raffigurabile graficamente con un diagramma tridimensionale (mostrato in Figura 4.6) in cui il livello di sicurezza, protezione e complessità di design del sistema cresce con gli assi. Nelle ordinate troviamo la classificazione in base agli strati, quindi a livello applicazione (APPLICATION). Sulle ascisse è rappresentato lo stack IPsec (STACK) attraverso le macro fasi in cui il protocollo si svolge, ordinate in termini temporali di esecuzione, prendendo come riferimento il traffico in entrata (per il traffico in uscita le operazioni sono le stesse ma eseguite con diverso ordine, si veda il capitolo 2 su IPsec). La terza dimensione (CORE) identifica la classe di appartenenza dell acceleratore crittografico in base al numero di core costituenti l architettura. Per ragioni grafiche la terza dimensione è stata raffigurata come espansione di aree; nessun significato è da associare ai limiti delle regioni. In questo modo lo spazio delle scelte per il design di un acceleratore è mappato in uno spazio tridimensionale che tenga conto dei livelli descritti in precedenza. Procedere secondo la crescita degli assi equivale a realizzare ac- 3 Standalone indica che il dispositivo è costituito da un modulo unico a se stante, separata dal resto del sistema ed incluso interamente all interno di un box protettivo anti intrusione. 74

76 4. Approccio metodologico al design degli acceleratori hardware Strato App level Command Verification Metadata Session Key Private Key single core Multiple core Standalone t APPLICATION CORE Crittografia Compressione Autenticazione Chiavi STACK Figura 4.6: Spazio di design interno di un acceleratore hardware celeratori hardware sempre più specializzati ed autosufficienti, con conseguente crescita della complessità progettuale ed architetturale, nonchè delle dimensioni e consumo di potenza del dispositivo Selezione di un design Sorge spontaneo chiedersi come combinare i livelli di design in Figura 4.6 ai fini della progettazione di un acceleratore hardware. Non esiste un modo univoco di prendere una decisione progettuale; esiste, invece, qualche vincolo che costringe ad intraprendere una strada piuttosto che un altra. Per fare un esempio, si pensi di voler realizzare un modulo che implementi solo l algoritmo crittografico AES [28]; sembra opportuno quindi sviluppare l acceleratore hardware a singolo core, tipicamente un ASIC o FPGA; apparterrà allo strato 0 ed elaborerà crittograficamente il pacchetto protetto da IPsec, nessun 75

77 4. Approccio metodologico al design degli acceleratori hardware altra operazione del protocollo sarà svolta dal dispositivo. In ambito militare, invece, dove sono richiesti alti livelli di sicurezza, sembra opportuno selezionare un acceleratore hardware che sia multicore e standalone, in modo da includere una certa protezione anche fisica del dispositivo e permetterne il posizionamento anche al di fuori dell host stesso. Un acceleratore hardware di questo tipo deve potere gestire autonomamente l intero protocollo IPsec e pertanto dovrà essere di tipo strato 4 e salire nello stack fino a comprenderlo interamente. Una tale implementazione di IPsec è, solitamente, di tipo bump-in-the-wire (BITW). Sviluppare un acceleratore hardware, quindi, significa selezionare un punto nello spazio di design in Figura 4.6 ed implementare il necessario in hardware. Ogni scelta dovrà tenere in considerazione il contesto entro cui l acceleratore hardware dovrà compiere il suo dovere. In generale i vantaggi di muoversi dallo strato 0 agli strati superiori, e rendere l acceleratore hardware, al tempo stesso, completo, accrescendone la capacità di gestire lo stack IPsec, sono ovviamente legati alle prestazioni. Un acceleratore hardware progettato in questo modo, è particolarmente efficiente poichè altamente specializzato ed ottimizzato al solo scopo di ottenere il massimo dal protocollo di sicurezza. Dalla parte opposta, ci si rende facilmente conto che realizzare un acceleratore hardware complesso, richiede parecchi sforzi di design ed alti costi di sviluppo. Semplificare l acceleratore hardware sembrerebbe la soluzione a miglior rapporto costi/benefici, ma si deve tenere in considerazione che il protocollo IPsec risulta particolarmente complesso sia nella sua architettura che nelle regole. Di conseguenza, un acceleratore hardware semplice, magari single core, sarà affiancato ad un host al quale spetterà la fetta più grande di IPsec. In un sistema del genere l interfaccia di comunicazione tra host ed acceleratore hardware diventerebbe il vero problema a livello prestazionale a causa delle numerose interazioni di controllo e gestione tra le due parti, allo scambio dei dati, al ritorno dei risultati, etc. La sfida consiste, quindi, nel partizionare ottimamente lo stack IPsec tra ac- 76

78 4. Approccio metodologico al design degli acceleratori hardware Figura 4.7: Partizionamento HW/SW dello stack IPsec in funzione del posizionamento: In-line, Off-line[30]. celeratore hardware ed host, ottimizzando il processo di comunicazione sia dal punto di vista fisico, con interfacce più efficienti e a banda più ampia, sia facendo attenzione alla politica di gestione di IPsec inteso come applicazione distribuita e concorrente fra i processori dedicati e general-purpose. La tabella in Figura 4.7 descrive un modo in cui potrebbe avvenire il partizionamento HW/SW dello stack IPsec. Se si vuole puntare all ottimizzazione del protocollo IPsec, si deve anche tenere in considerazione lo scopo per il quale IPsec è stato progettato. IPsec è un protocollo statefulness utilizzato in ambienti in cui sono richieste sessioni, di lunga durata, in cui il volume di dati scambiati è enorme. Al contrario, lo scambio delle chiavi, p.e., tra i gateway avviene solo in fase iniziale e in numero limitato rispetto alla quantità di sessioni aperte tra gli hosts delle due reti (poche chiavi per 77