Tesi di Laurea - DRESD · POLITECNICO DI MILANO aacoltFdi Ingegneria Dipartimento di Elettronica e Informazione REALIZZAZIONE DI UN'ARCHITETTURA DI CIFRATURA SIMMETRICA AES SU FPGA

POLITECNICO DI MILANO

Facolt�a di Ingegneria

Dipartimento di Elettronica e Informazione

REALIZZAZIONE DI UN'ARCHITETTURA

DI CIFRATURA SIMMETRICA

AES SU FPGA

Relatore: Prof. Fabrizio FERRANDI

Correlatore: Ing. Marco Domenico SANTAMBROGIO

Tesi di Laurea di:

Alain VAILATI

Matr. 654434

Anno Accademico 2003/2004

Tesi di Laurea

Alain Vailati

Ottobre 2004

POSSESSO

Io so che nulla mi appartiene al mondo

fuorch�e il pensiero, utto imperturbato

che vuol sgorgare dall'anima mia,

e ogni istante giocondo

in cui benigno un fato

di goder mi concede dal profondo

Goethe.

Indice

Indice 1

Introduzione 2

1 Introduzione alla crittogra�a 6

1.1 Cos'�e la crittogra�a . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Classi�cazioni dei cifrari . . . . . . . . . . . . . . . . . . . . . 8

1.2.1 Cifrari con chiave simmetrica e asimmetrica . . . . . . 8

1.2.2 Cifrari a blocco e a usso . . . . . . . . . . . . . . . . . 9

1.3 Le diverse funzioni della crittogra�a . . . . . . . . . . . . . . . 9

1.4 Utilizzi della Crittogra�a . . . . . . . . . . . . . . . . . . . . . 10

1.5 L'AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5.1 De�nizioni . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.5.2 L'algoritmo . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Gli strumenti e la metodologia 19

2.1 L'FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.1 Cos'�e una FPGA . . . . . . . . . . . . . . . . . . . . . 20

2.1.2 Perch�e un' FPGA . . . . . . . . . . . . . . . . . . . . . 21

2.1.3 Struttura di una FPGA: Virtex II Pro . . . . . . . . . 22

2.2 VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.1 Entit�a e processi . . . . . . . . . . . . . . . . . . . . . 24

2.3 Software e strumenti . . . . . . . . . . . . . . . . . . . . . . . 25

2.3.1 ISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

INDICE 1

2.3.2 Modelsim . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3.3 EDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4 La Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3 Implementazione 36

3.1 Traduzione dell'algoritmo in codice VHDL . . . . . . . . . . . 36

3.1.1 La libreria util . . . . . . . . . . . . . . . . . . . . . . . 37

3.1.2 Il KeyExpander . . . . . . . . . . . . . . . . . . . . . . 38

3.1.3 Il Cipher . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2 Adattamento per FPGA . . . . . . . . . . . . . . . . . . . . . 41

3.2.1 L'architettura . . . . . . . . . . . . . . . . . . . . . . . 42

3.2.2 L'IP Core Kver . . . . . . . . . . . . . . . . . . . . . . 42

3.2.3 Interfacciamento con bus opb . . . . . . . . . . . . . . 44

3.2.4 Sintesi con Project Navigator . . . . . . . . . . . . . . 46

3.2.5 I Driver e il �le System.c . . . . . . . . . . . . . . . . . 48

4 Test e conclusioni 50

4.1 Veri�ca del codice VHDL . . . . . . . . . . . . . . . . . . . . . 50

4.2 Prove su FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.1 Generare il bitstream . . . . . . . . . . . . . . . . . . . 52

4.2.2 Download del BitStream . . . . . . . . . . . . . . . . . 53

4.3 Risultati sperimentali . . . . . . . . . . . . . . . . . . . . . . . 54

4.3.1 Tempistiche . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3.2 Consumo delle risorse . . . . . . . . . . . . . . . . . . . 55

4.4 Conclusione e possibili sviluppi futuri . . . . . . . . . . . . . . 56

Legenda 58

Bibliogra�a 63

Introduzione

La scrittura di messaggi segreti �e antica, forse, quanto la comunicazione tra

gli uomini. La tecnica di rendere inintelligibile un messaggio �e detta crit-

togra�a e l'atto si dice criptare. Criptare �e una parola che viene dal greco

cryptos -nascosto- e infatti, la sua funzione �e nascondere il signi�cato di un

messaggio; si hanno traccia di applicazioni di crittogra�a (in special modo

sulle comunicazioni) risalenti persino agli antichi egizi: infatti nelle societ�a

primitive qualunque tipo di scrittura era di per s�e magico e segreto. Storica-

mente l'utilizzo della crittogra�a �e stato proprio di diversi gruppi di persone:

i militari, i corpi diplomatici, i diaristi e gli amanti. I militari hanno sicura-

mente giocato il ruolo pi�u importante perch�e la crittogra�a applicata a scopi

bellici ha rappresentato per molti secoli un'arma decisiva nelle mani di chi

sapeva come usarla. La Scitala Lacedemonica �e un antico esempio di un siste-

ma per cifrare messaggi tramite l'utilizzo di un bastone cilindrico (secondo

gli scritti di Plutarco, in uso dai tempi di Licurgo, IX sec a. C.), sicuramente

si tratta di uno dei primi sistemi crittogra�ci con tecnica di trasposizione.

Figura 1: La Scitala Lacedemonica

La tecnica consiste nell'avvolgere un bastone con una striscia di carta

Introduzione 3

e scrivere il messaggio dall'alto verso il basso, �nito di scrivere si svolge il

nastro con un messaggio di�cilmente interpretabile senza un bastone della

stessa circonferenza dell'originale.

Un altro storico e famoso impiego della crittogra�a si ritrova nell'epo-

ca dell'Impero Romano, con la tecnica di trasposizione inventata da Giulio

Cesare. Essa consisteva nella sostituzione di ogni lettera dell'alfabeto con la

terza successiva nell'ordine. Nel Medioevo poi, Gabriele Lavinde scrisse il

primo manuale (1379) a riguardo, conservato ancora in Vaticano. Successive

applicazioni si ebbero in Francia all'epoca del cardinale Richelieu con Anto-

nio Rossignol e soprattutto in Italia con L. B. Alberti, G. B. Porta, G. B.

Bellaso, G. Cardano. All'inizio del secolo durante la prima guerra mondiale il

generale Luigi Sacco, dell'esercito italiano, scrisse il famoso Nozioni di critto-

gra�a (1925). Il periodo d'oro della crittologia per�o �e certamente quello della

seconda guerra mondiale quando Alan Turing, il padre dell'informatica teori-

ca, insieme al gruppo di ricerca del Bletchley Park formalizz�o la matematica

necessaria per uno studio sistematico dei cifrari. In seguito Claude Shan-

non, ideatore della moderna teoria dell'informazione, pubblic�o nel 1949 un

articolo rimasto nella storia Communication theory of secrecy systems. Alla

seconda guerra mondiale si deve la nascita d'Enigma la pi�u famosa macchina

crittogra�ca, usata dall'esercito tedesco.

Figura 2: La macchina Enigma

Introduzione 4

In questo periodo, infatti, tutte le comunicazioni avvenivano via radio, un

canale, com'�e ovvio, facile da individuare ed ascoltare da parte di chiunque

disponesse di un ricevitore. Per rendere sicure le comunicazioni, i tedeschi

crittavano i messaggi con Enigma uno strumento che, solo dall'esterno, so-

miglia vagamente ad una macchina da scrivere. In realt�a all'interno contiene,

a seconda del modello, tre o quattro rotori e una serie di spinotti elettrici.

La sostituzione del messaggio con uno criptato �e sempre diversa se cambia lo

stato iniziale della macchina, quindi per decifrare un messaggio �e necessario

avere Enigma e conoscere lo stato iniziale della macchina usata per criptarlo,

oppure servirsi d'enormi macchine, chiamate appunto Colossi ( che sono gli

antenati dei moderni calcolatori) come fece Turing. Da venti anni a questa

parte si �e veri�cata l'esplosione del fenomeno internet e la velocissima evo-

luzione dei computer, in questi anni per criptare messaggi ci si a�dava ad

algoritmi implementati su software come programmi ed eseguiti su computer.

In questo periodo con l'aumento della mole di dati da crittografare, la cre-

scente complessit�a dei calcoli e l'elevata velocit�a richiesta rendono necessario

un ulteriore salto di qualit�a nell'elaborazione. Tale salto pu�o essere ottenuto

eliminando dalla catena di elaborazione dei messaggi, il sistema operativo

e il generico computer con processore generico. La programmazione di una

FPGA pu�o essere una soluzione veloce ed economica al problema, questo �e

ci�o che si �e fatto e che si spiegher�a in questo documento.

Il presente lavoro di tesi �e principalmente organizzato in quattro parti.

Il primo capitolo introduce la crittogra�a come scienza e potente strumento

di comunicazione, fornendo inizialmente un breve glossario dei termini speci-

�ci, spiegando i principi teorici della crittogra�a e le diverse forme sviluppate,

mostrando le principali tecniche di crittogra�a oggi usate e approfondendo

particolarmente quelle riguardanti l'AES. In�ne s�e presenta il supporto sul

quale �e stato implementato l'algoritmo ovvero il chip FPGA. Del supporto

si d�a una descrizione delle componenti e del funzionamento e si presentano i

tool adottati per programmarla.

Introduzione 5

Nel secondo capitolo si spiega la metodologia che si �e seguita per lo svolgi-

mento del lavoro descrivendola passo per passo speci�cando i tool utilizzati

e motivando le scelte attuate.

Il terzo capitolo mostra il processo di analisi del documento di speci�ca

che �e stato fatto evidenziandone le interpretazioni e le decisioni di imple-

mentazione prese in questa fase del lavoro. In�ne si presentano i risultati

sperimentali e i possibili sviluppi futuri.

Nel quarto capitolo si spiegano le modalit�a di test e i risultati sperimentali

della prova sul chip,si traggono le conclusioni sul lavoro svolto e si ipotizzano

possibili sviluppi del lavoro.

Capitolo 1

Introduzione alla crittogra�a

In questo capitolo si presenta una panoramica del mondo della crittogra�a

mostrandone gli aspetti salienti per questo progetto. Si o�rir�a una breve

de�nizione dei termini, si mostrer�a uno schema tipico di funzionamento di

una comunicazione criptata e in�ne si mostreranno due standard: l'SSL e

l'AES. Il primo �e un protocollo mentre l'altro �e lo standard di crittogra�a

pi�u recente ed �e il caso di studio di questo lavoro.

1.1 Cos'�e la crittogra�a

Quando si parla di crittogra�a, ci si riferisce a quella scienza che fornisce uno

strumento adatto a mantenere segrete tutte quelle informazioni che non si vo-

gliono divulgare pubblicamente in maniera tale che la possibilit�a di accedervi

sia data soltanto ad uno o ad un ristretto numero di persone autorizzate. Lo

scenario tipico in cui si usa la crittogra�a consta di due attori e di diverse

parti: il mittente A e il destinatario B, un messaggio Pt, una chiave di ci-

fratura Kc e una di decifratura Kd, un cifrario C e un crittogramma Ct che

interagiscono come in Figura 1.1 L'operazione tramite la quale si nascondono

le informazioni �e chiamata cifratura oppure crittazione, ed �e e�ettuata tra-

mite un apposito algoritmo chiamato cifrario; l'informazione o il messaggio

da cifrare �e noto come testo chiaro (plaintext) che, insieme alla chiave detta

1.1 Cos'�e la crittogra�a 7

Figura 1.1: Scenario

chiave del cifrario viene convertito da testo chiaro a testo cifrato o critto-

gramma (ciphertext). Con decrittazione invece, si intende la conversione da

testo cifrato a testo chiaro, anch'essa sfrutta la chiave del cifrario. L'ambi-

to nel quale sono e�ettuate le operazioni di crittazione e di decrittazione �e

chiamato crittosistema. La pratica del rivelare ci�o che la crittogra�a tenta di

nascondere �e detta crittoanalisi ed �e un campo che, si pu�o dire, si sviluppi

pari passo con la crittogra�a per molteplici scopi: perfezionare l'algoritmo

di crittogra�a, rompere sistemi di crittogra�a, che signi�ca avere accesso al

signi�cato dei messaggi crittati senza disporre di una chiave. L'obbiettivo

principale della crittogra�a �e la realizzazione del cifrario perfetto, ossia un

sistema nel quale dal crittogramma �e impossibile trarre informazioni sul testo

in chiaro. Il teorema di Shennon a�erma l'esistenza e anche la scarsa prati-

cabilit�a del cifrario perfetto, che, infatti, �e stato in alcuni casi realizzato e

impiegato con dispendio di ingenti risorse. Un esempio �e il cifrario chiamato

One-time pad: esso cifra il testo in chiaro con una chiave ottenuta da una

sorgente modellata con un processo stocastico binario, il cifrario fa lo xor bit

a bit della chiave, di cui ogni bit �e usato una sola volta, e il testo. Percui nel

solito caso tipico si possono vedere i due attori che si incontrano e si scam-

biano una chiave, essi potranno poi comunicare con messaggi crittati �ntanto

1.2 Classi�cazioni dei cifrari 8

che la chiave non si esaurisce, dopodiche dovranno scambiarsene una nuova .

1.2 Classi�cazioni dei cifrari

Un primo criterio di classi�cazione pu�o essere attuato in base al tipo di

chiave utilizzata dall'algoritmo. Esistono, infatti, sostanzialmente due sistemi

diversi: i sistemi a chiave asimmetrica e i sistemi a chiave simmetrica. Un

secondo importante criterio di classi�cazione consiste nel suddividere i cifrari

in due categorie: cifrari a blocchi e cifrari a usso.

1.2.1 Cifrari con chiave simmetrica e asimmetrica

I sistemi a chiave asimmetrica hanno due chiavi che vengono generate insie-

me e sono strettamente collegate: una, detta pubblica, che viene distribuita

a tutte le possibili entit�a interessate alla comunicazione sicura, mentre l'altra

chiave, detta privata, �e nota solo ad un'entit�a. Il legame fra le due chiavi

consiste nel fatto che il messaggio viene crittato con una chiave e pu�o es-

sere decifrato solo con l'altra chiave, legame questo che da origine a diversi

scenari, possibilit�a di comunicazioni e funzioni diverse come si spiega nel pa-

ragrafo sulle diverse funzioni della crittogra�a. Il secondo sistema �e detto a

chiave simmetrica perch�e appunto le due chiavi, per crittare e decrittare il

crittogramma, sono uguali. Questo sistema �e solitamente molto pi�u veloce,

semplice e leggero di quello a chiave asimmetrica ed �e usato per comunicazioni

lunghe e che necessitano di quelle caratteristiche, ad esempio le trasmissio-

ni sicure via web, pi�u avanti approfondite. Una delle debolezze principali di

questo sistema �e che entrambi gli attori devono avere la stessa chiave e se non

possono scambiarla di persona devono in qualche modo spedirsela aumentan-

do cos�� i rischi di intercettazione, il metodo �e di crittare la chiave simmetrica

con una chiave asimmetrica come fa Secure Socket Layer, SSL, un protocollo

per trasmissioni sicure pi�u avanti mostrato.

1.3 Le diverse funzioni della crittogra�a 9

1.2.2 Cifrari a blocco e a usso

Un cifrario a blocchi cifra il testo in chiaro in blocco o comunque suddividen-

dolo di blocchi di dimensione prede�nita ed elaborandoli sequenzialmente.

Dall'altra parte il cifrario a usso lavora su un usso di dati, di solito di

singoli bit per volta e, appena arrivato il bit, il cifrario restituisce subito il

bit criptato senza attendere l'arrivo di altri bit o blocchi di bit. Inoltre, un

cifrario a blocchi con lo stesso testo in chiaro e con la stessa chiave restituisce

sempre lo stesso crittogramma, mentre con un sistema a usso l'uscita dipen-

de anche dalla storia pregressa del cifrario. Un cifrario pu�o operare in diversi

modi per quanto riguarda il procedimento col quale testo in chiaro, chiave e

cifrario interagiscono l'un l'altro. Il metodo chiamato Electronic Codebook ,

ECB, rappresenta la via pi�u semplice e diretta per un cifrario a blocchi: una

volta �ssata la chiave, il sistema critter�a sempre lo stesso blocco alla stessa

maniera, sistema questo, che pu�o essere immaginato come una tabella a dop-

pia entrata chiave/blocco. Mentre l'implementazione pu�o essere molto veloce,

questo sistema consuma moltissima memoria dato che �e necessaria una cella

della tabella per ogni coppia chiave-blocco possibile. La controparte del ECB

�e il Cipher Block Chaining , CBC, metodo nel quale i nuovi crittogrammi

dipendono dagli stati precedenti dell'algoritmo e dalle sue precedenti uscite.

Tra ECB e CBC, Ciphertext Feedback , CFB, rappresenta una metodologia

per far funzionare cifratori a blocchi come cifratori a usso: i valori in uscita

da un crittosistema sono serializzati come in un cifrario a usso, ma l'uscita

dipende oltre che dalla chiave e dal testo in chiaro attuale, anche dal crit-

togramma precedente che viene messo in Xor bit a bit con il testo in chiaro

[1].

1.3 Le diverse funzioni della crittogra�a

Finora si �e parlato della crittogra�a come sistema per proteggere la privacy

di una comunicazione, in realt�a l'ingegno umano ha sfruttato questo mezzo

per diverse altre applicazioni per rendere una comunicazione sicura anche

1.4 Utilizzi della Crittogra�a 10

ad altri livelli che sono: l'identi�cazione, l'autenticazione, l'integrit�a dei dati,

autenticit�a e il non ripudio. Queste funzioni sono per lo pi�u ottenibili per

mezzo della crittogra�a a chiave asimmetrica che permette la realizzazione

della cosiddetta �rma digitale. La �rma digitale consiste nel crittare con

la propria chiave segreta, alcuni dati personali che potrebbero essere nome,

cognome, codice �scale e chiave pubblica; questa �rma quindi �e decifrabile

solo con la chiave pubblica relativa che deve corrispondere con quell'inserita

all'interno tra i dati, in questa maniera si �e certi dell'autenticit�a della �rma.

Se poi si inserisce la �rma all'interno di un documento e si cripta si ottiene

l'autenticit�a, ma non l'integrit�a. Per avere l'integrit�a di un messaggio crittato

bisogna aggiungere alla �rma il digest del messaggio, il digest �e una funzione

di estrazione dal messaggio di un blocco di dati solitamente delle dimensioni

inferiori ai 150 bit per mezzo del quale sia impossibile risalire al messaggio

originale ma allo stesso tempo sia impossibile da modi�care per alterare

il messaggio. In Figura 1.2 si vede un esempio di trasmissione sicura con

l'utilizzo della �rma digitale e del digest ottenuto tramite hash function.

Come si vede con questa tecnica si ottengono tutte le funzionalit�a desiderate

eccetto che per il non ripudio da parte del destinatario, non si pu�o, infatti,

garantire che il ricevente abbia letto il messaggio.

1.4 Utilizzi della Crittogra�a

Dopo aver descritto il funzionamento e le potenzialit�a delle tecniche di crit-

togra�a se ne vuole mostrare una famosa e importante implementazione nel

mondo delle comunicazioni via web, mondo in cui questa scienza �e massic-

ciamente impiegata. Questa non pu�o che essere il protocollo Secure Socket

Layer, SSL, esistente in svariate versioni e utilizzato per moltissime applica-

zioni. SSL �e uno dei protocolli pi�u di�usi nelle comunicazioni sicure, propo-

sto dalla Netscape Communication Corporation garantisce la con�denzialit�a

e l'a�dabilit�a delle comunicazioni su Internet proteggendole da intrusioni,

modi�che o falsi�cazioni. Lo scenario che si considera �e quello di un utente

1.4 Utilizzi della Crittogra�a 11

Figura 1.2: Trasmissione sicura

U che deve accedere a dei servizi in tutta sicurezza da un sistema S. Uti-

lizzando SSL si garantir�a la con�denzialit�a della comunicazione grazie ad

un sistema di cifratura ibrido tra una cifratura a chiave simmetrica e uno a

chiave asimmetrica. Questo sistema prevede, infatti, che per concordare la

chiave simmetrica per la comunicazione, si ricorda che la cifratura con chiave

simmetrica �e di solito pi�u veloce, si utilizzi un sistema di cifratura a chiave

asimmetrica col quale si cifrare la chiave simmetrica da scambiare tra le due

identit�a, il tutto �e eseguito tramite un processo chiamato Handshake, che �e

un suo sotto protocollo. Questo sotto protocollo prevede che le due parti in

gioco, una volta accertato che una delle due desidera una connessione SSL,

si scambino i rispettivi certi�cati con lo scopo di autenticarsi e i propri ci-

frari e chiavi supportate allo scopo di accordarsi sull'algoritmo simmetrico

da utilizzare per la comunicazione. Questo procedimento conseguentemente

esclude ogni possibilit�a di falsi�cazione o comunque di intrusione indesiderata

nella comunicazione, anche nel caso pessimo del man in the middle. Secondo

1.5 L'AES 12

requisito fondamentale di una comunicazione sicura �e l'autenticit�a, caratte-

ristica che SSL garantisce ricorrendo all'utilizzo di certi�cati e di un cifrario

asimmetrico. SSL �e un protocollo che si situa tra un protocollo di traspor-

to come il TCP/IP ed un protocollo applicativo come HTTP mantenendo,

per�o, indipendenza da questi livelli cosi' da aumentarne la portabilit�a e riu-

tilizzabilit�a. Non sono mancate in ogni caso integrazioni fra questi protocolli

come nel caso del Hyper Text Transfert Protocol Secure ,HTTPS, utilizzato

da numerosi web server sicuri.

1.5 L'AES

L'acronimo AES signi�ca Advanced Encryption Standard ed �e il nome che

il NIST ,National Institution of Standards and Technology, il 26 Novembre

2001 ha scelto per il nuovo standard di crittogra�a di dati. Prima di questa

data, lo standard u�ciale Americano era, sin dal 1977, il Data Encryption

Standard ,DES. Questo protocollo di crittogra�a col passare degli anni ha

iniziato a mostrare diverse vulnerabilit�a tanto che negli ultimi anni le mac-

chine del NIST erano in grado di decifrare un crittogramma in un secondo. A

causa di queste diverse debolezze riscontrate, �no alla �ne degli anni 90, ne

furono realizzate diverse varianti come il Triple-DES ma ormai continuare a

fare modi�che non era piu' su�ciente. F�u cos�� che fu indetto il concorso vinto

dall'algoritmo originalmente chiamato Rijndael. Il nome Rijndael �e composto

di parti dei cognomi degli autori ,RIJ e DAE, Joan Daemen e Vincent Rij-

men . Il progetto di Rijndael �e stato fortemente in uenzato dal block cipher

Square, �e altamente sicuro ed ha subito un'estensiva crittoanalisi: �no al No-

vembre 2002 non sono stati riscontrati punti deboli. Lo standard prevede la

possibilit�a di crittare blocchi di dati da 128 bit per mezzo di chiavi da 128,

192 o 256 bit con una procedura algoritmica facilmente implementabile sia

via software che via hardware. Non si intende, in questa sede descrivere det-

tagliatamente il funzionamento dell'algoritmo AES, per quello si rimanda al

documento u�ciale �ps [10], ma darne una descrizione generale, indicandone

1.5 L'AES 13

le modalit�a con le quali si �e scelto di implementarlo.

1.5.1 De�nizioni

Prima di addentrarsi nella descrizione delle procedure si elencano i termini

maggiormente usati e i loro signi�cati:

Strutture Dati

Bit: un valore binario che pu�o assumere i valori 0 e 1.

Byte: un gruppo di 8 bit che �e trattato come una singola entit�a o come un

vettore di 8 bit individuali.

Parola: gruppo di 32 bit che �e trattato come una singola entit�a o come un

array di 4 byte.

Array: una collezione enumerata di entit�a con caratteristiche simili. Blocco:

sequenza di bit che pu�o rappresentare input, output, Stato o Round Key. La

lunghezza della sequenza �e rappresentata dal numero di bit che contiene. I

blocchi possono anche essere interpretati come array di byte.

Variabili dell'algoritmo AES

Chiave di cifratura: chiave segreta che �e utilizzata dalla funzione Key Ex-

pansion per generare un insieme di Round Key; pu�o essere rappresentata

come una matrice quadrata di byte, con 4 righe e 4 colonne.

Stato: risultato intermedio della cifratura che pu�o essere rappresentato come

una matrice quadrata di byte, con 4 righe e 4 colonne.

Round Key: valori derivati dalla chiave di cifratura usando la funzione Key

Expansion. Sono applicate allo Stato nella cifratura e nella cifratura inversa.

Dati originali: dati che sono in ingresso al processo di cifratura o sono usciti

dal processo di cifratura inversa.

Dati cifrati: dati che sono usciti dal processo di cifratura o sono in ingresso

al processo di cifratura inversa.

S-box: tabella di sostituzione non lineare usata in molte trasformazioni di

sostituzione di byte.

1.5 L'AES 14

Funzioni e costanti

AddRoundKey (): trasformazione nella cifratura e nella cifratura inversa in

cui una Round Key viene aggiunta allo Stato usando un'operazione di XOR

MixColumns (): trasformazione nella cifratura che prende tutte le colonne

dello Stato e mischia il loro contenuto (indipendentemente l'una dall'altra)

per produrre nuove colonne.

RotWord (): funzione usata nella funzione Key Expansion che prende una

parola di 4 byte e fa una permutazione ciclica.

ShiftRows (): trasformazione nella cifratura che elabora lo stato spostando

ciclicamente le ultime 3 righe dello Stato di o�set di�erenti.

SubBytes (): trasformazione nella cifratura che elabora lo Stato usando una

tabella (S-box) non lineare per la sostituzione dei byte, che opera indipen-

dentemente in ognuno dei byte dello stato.

SubWord (): funzione usata nella funzione Key Expansion che prende in

ingresso una parola di 4 byte e applica la S-box a ognuno dei 4 byte per

produrre una parola in uscita.

Rcon: la matrice di round word costanti.

XOR: operazione di OR esclusivo.

�: operazione di OR esclusivo.

: moltiplicazione di due polinomi (ognuno di grado minore di 4) modulo

x4+1.

�: moltiplicazione su un campo �nito.

Altre de�nizioni

AES: Advanced Encryption Standard.

Rijndael: algoritmo di crittogra�a su cui si basa l'Advanced Encryption

Standard, AES.

Trasformazione A�ne: una trasformazione che consiste in una moltipli-

cazione per una matrice seguita dalla somma di un vettore.

1.5 L'AES 15

1.5.2 L'algoritmo

La procedura consta di due parti: l'espansione della chiave e il blocco cifra-

tore. L'espansione della chiave crea, dato in ingresso un blocco di 128 bit,

chiave, un blocco 44 parole da 32 bit che all'interno dell'algoritmo costitui-

scono la chiave espansa indispensabile per il processo di criptazione. Il blocco

cifratore a partire dalla chiave espansa e dal blocco di dati da cifrare, suc-

cessivamente chiamato come stato, restituendone il blocco cifrato. Sotto si

pu�o vedere in pseudo codice la procedura di espansione. Nk, Nb e Nr va-

Figura 1.3: Pseudo codice del KeyExpander

riano a seconda della chiave che si utilizza, in questo ambito per�o Nk e Nb

saranno uguali a 4 e Nr varr�a 10. Come si pu�o capire dalla Figura 1.3 la

procedura copia la chiave nelle prime quattro righe della chiave espansa e

riempie le restanti quaranta righe facendo sostituzioni mediante la funzione

SubWord,Rcon e xor con le righe precedenti.

La funzione SubWord �e una funzione di sostituzione di parole da 32 bit

1.5 L'AES 16

mediante la tabella SBOX ,Figura 1.4, i cui valori nelle celle sono calcola-

bili mediante un procedimento speci�cato sempre nel �ps-197. La RotWord

Figura 1.4: S-Box per la funzione SubWord

consiste in una rotazione delle posizioni dei byte all'interno della parola da

32 bit traslandoli in questa maniera: se la parola la rappresentiamo come

[a0,a1,a2,a3] la funzione restituisce [a1,a2,a3, a0]. Rcon invece �e un array di

costanti dove Rcon[i] �e dato da [xi-1, 00,00,00] e xi-1 �e una potenza di x (02

nel campo GF(28) ).

La parte �nale dell'algoritmo �e chiamata Cipher: un procedimento che prende

in ingresso il blocco da 128 bit da codi�care e il registro con la chiave espansa

dal Keyexpander e restituisce il blocco criptato. Uno schema in pseudo codice

lo si pu�o vedere in Figura 1.5. In questo schema compaiono 4 funzioni nuove:

AddRoundKey, SubBytes, ShiftRows e MixColumns.

La prima �e una semplice funzione di Xor bit a bit di una riga della chiave

espansa con 32bit dello stato.

SubBytes �e una funzione di sostituzione dal funzionamento simile a quello

della funzione di SubWord ma operante su parole di 8 bit; se rappresentiamo

lo stato come una tabella di 16 elementi di 8, la funzione si pu�o rappresentare

come in Figura 1.6.

1.5 L'AES 17

Figura 1.5: Blocco cifratore Cipher

La funzione ShiftRows ruota le righe dello stato dipendentemente dall'or-

Figura 1.6: Funzione SubBytes

dine della riga: nessuna rotazione per la riga 0, una rotazione di uno per la

riga 1, 2 per la 2 e una rotazione di tre posti per la terza.

MixColumns invece lavora sulle colonne dello stato e calcola lo stato di

uscita applicando, ad ogni colonna la moltiplicazione matriciale come in Fi-

gura 1.7, nella quale la moltiplicazione �e la moltiplicazione nel campo GF(28),

Galosi Field e la somma �e uno xor bit a bit.

1.5 L'AES 18

Figura 1.7: Moltiplicazione per mixcolumns

Capitolo 2

Gli strumenti e la metodologia

La realizzazione dell'architettura di cifratura ha implicato la scelta del si-

stema da utilizzare e l'impiego di diversi software di sviluppo secondo una

precisa metodologia.

Scopo di questo capitolo �e presentare l'architettura di riferimento per l'im-

plementazione di questo speci�co caso, gli strumenti utilizzati e mostrare la

metodologia adottata. Per quanto riguarda l'architettura, si dar�a una breve

descrizione della sua struttura e del suo funzionamento oltre che motivarne

l'impiego. Degli strumenti utilizzati, che sono ISE, Modelsim e EDK, si de-

scriveranno le funzionalit�a generiche dando particolare attenzione a quelle

pi�u utilizzate. Si presenter�a inoltre anche il linguaggio di descrizione hard-

ware adottato, VHDL, e in�ne grazie alla metodologia si dar�a una descrizione

delle fasi seguite durante il lavoro.

2.1 L'FPGA

L'architettura di riferimento impiegata, ovvero l'FPGA, �e un ritrovato tecno-

logico piuttosto recente, la conoscenza della sua esistenza �e circoscritta agli

ambiti specializzati nei sistemi embedded, quindi, nei paragra� che seguono

si cercer�a di fare chiarezza su cosa sia, come funzioni e sui suoi impieghi.

2.1 L'FPGA 20

2.1.1 Cos'�e una FPGA

La Field-Programmable Gate Array , FPGA, �e un tipo di dispositivo ri-

programmabile direttamente dall'utente e, come suggerisce il nome, esso �e

costituito da banchi di componenti logici collegabili tra loro dinamicamente.

I banchi e le connessioni logiche variano da chip a chip ma sostanzialmente

Figura 2.1: L'FPGA Virtex

sono di due tipologie ciascuna: ci sono banchi di componenti complessi, con

semplicit�a di uso ma di scarsa e�cienza, e banchi di componenti semplici,

pi�u di�cili da utilizzare ma molto pi�u e�cienti perch�e permettono di curare

i dettagli dell'implementazione. Per quanto riguarda le connessioni, la FPGA

dispone di connessioni brevi e veloci e di connessioni pi�u lente ma pi�u lun-

ghe che, attraversando tutto il dispositivo, possono quindi essere condivise

da pi�u parti dell'architettura e farle comunicare. Il risultato di un integrato

cosi' realizzato �e un compromesso sotto molti aspetti. Bisogna sapere infatti,

che nel campo dei circuiti integrati vi �e una vasta scelta: in questo campo si

trovano ASIC, MPGA, PLD ed in�ne FPGA che, date le sue caratteristiche

si crea uno spazio di mercato sempre pi�u consistente. Le Application Speci�c

Integrated Circuit, ASIC, sono dei chip personalizzati in base alle necessit�a

del costruttore dell'apparato su cui �e montato e progettati per svolgere una

determinata applicazione. Questa personalizzazione avviene per�o interamen-

2.1 L'FPGA 21

te in fase produzione e ha conseguentemente alti costi e tempi per le fasi

di progettazione e prototipazione. Inoltre, una volta prodotto non �e pi�u mo-

di�cabile, ne consegue uno strumento decisamente poco essibile e pratico

per i piccoli produttori e specialmente per degli studenti. Tra i dispositivi

riprogrammabili si trovano MPGA FPGA e PLD. La Mask Programmable

Array , MPGA, �e il dispositivo pi�u grande e veloce. La MPGA consiste in

una base di transistor gi�a impostati in fase di produzione secondo le esi-

genze dell'utente a cui poi resta il compito di collegarli secondo le necessit�a

pre-programmate che vincolano anche eventuali cambiamenti di struttura; il

risultato �e un chip piuttosto costoso e non molto essibile sempre a causa del

processo di produzione dal quale bisogna passare. Le Programmable Logic

Device , PLD, sono invece i dispositivi pi�u piccoli e meno costosi ma anche

con meno potenzialit�a; di solito sono ROM, ad esempio E2PROM , PAL,

PLA e altre simili. La FPGA si colloca per granularit�a di personalizzazione

e quantit�a di risorse disponibili nel mezzo fra le tre ma anche per i costi.

Quest'ultima e�ettivamente, costa poco per produzioni in piccola scala e la

fase di prototipazione �e pi�u veloce e semplice.

2.1.2 Perch�e un' FPGA

La scelta di una piattaforma, che sia software, ASIC o FPGA, �e guidata da

diversi aspetti, come prestazioni in termini di velocit�a di elaborazione, costi e

essibilit�a. Gli svantaggi nel servirsi di una piattaforma hardware come ASIC

sono da trovarsi negli elevati costi e tempi di prototipazione, la scarsa essibi-

lit�a del sistema e nelle mancanze nelle esecuzioni di operazioni matematiche

come moltiplicazione divisione che hanno costi elevati di realizzazione.

Dall'altra parte il software si presenta come antitesi caratteriale dell'hard-

ware, infatti, tra le sue caratteristiche si ha un'elevata essibilit�a, portabilit�a

su diverse piattaforme e possibilit�a di rapidi aggiornamenti. I suoi punti a

sfavore non sono per�o pochi. Primo fra tutti, un algoritmo implementato via

software non so�re solo delle debolezze dovute alla sua struttura ma anche

quelle ereditate dal sistema operativo in oltre le sue prestazioni sono deci-

2.1 L'FPGA 22

samente inferiori a quelle hardware. La soluzione a questi problemi c'�e ed

�e a portata di mano: un'architettura basata su un hardware ricon�gurabile,

come per esempio un FPGA. Dato che gli algoritmi crittogra�ci sono in con-

tinua evoluzione, dall'89 ad oggi ci sono state pi�u di dieci veri�che sul DES

e TripleDES e il passaggio all'AES, l'alta essibilit�a �e quasi indispensabile:

facilit�a di aggiornamenti e possibilit�a di spostare sui driver alcune funzioni

troppo pesanti per lo hardware rende questa soluzione ottimale. La scelta �e

stata poi guidata anche dalle necessit�a didattiche: era infatti impossibile per

uno studente, realizzare con i pochi mezzi a disposizione un chip su ASIC

visto i costi elevati quando con una scheda Avnet gi�a presente nel laboratorio

Micro si possono fare tutte le prove che si desidera in tempi brevissimi.

2.1.3 Struttura di una FPGA: Virtex II Pro

Come si �e precedentemente accennato una FPGA �e un chip riprogrammabile

dall'utente composto da banchi di logica connesse in maniera non de�nitiva

ma modi�cabile a piacimento. Le soluzioni tecniche adottate per ottenere

questi obiettivi sono diverse, in particolare la Xilinx ha sviluppato uno dei

dispositivi FPGA pi�u prestanti e vendute al mondo: la Virtex II Pro. Questa

�e costituita da migliaia di Blocchi Logici Con�gurabili , CLB, che possono

essere liberamente interconnessi tra loro. Questi Blocchi Logici nel caso del

chip Xilinx sono logiche combinatorie a quattro ingressi e una uscita detti:

Look Up Table, LUT, costituiti da una SRAM. All'uscita di questi LUT sono

presenti due FLIP-FLOP allo scopo di memorizzare l'uscita del sistema com-

binatorio. I vari LUT sono poi interconnessi tra loro da canali di connessione

che, nel caso del dispositivo in esame, sono disposti a matrice come si pu�o

vedere in Figura 2.2 Sia la programmazione delle LUT che quella delle matri-

ci di interconnessione, avviene tramite celle di memoria volatile che possono

essere con�gurate a piacere, tipicamente all'accensione, ma anche a run-time.

2.2 VHDL 23

Figura 2.2: Esempio di FPGA: le connessioni

2.2 VHDL

Per la descrizione dello hardware esistono due diversi tipi linguaggi di pro-

grammazione:

1. Linguaggi di programmazione gi�a esistenti estesi nelle funzionalit�a e

sintassi per permettere di descrivere anche oggetti hardware, questo �e

il caso di Hardware-C de�nito nell'ambito dell'Universit�a di Stanford,

ed �e il linguaggio SystemC.

2. Linguaggi costruiti ex novo, speci�ci per la descrizione di architetture

ma comunque con strutture simili a quelle dei linguaggi di programma-

zione comuni, allo scopo di sempli�carne l'uso per chi gi�a programma

in altri ambiti. Questo �e il caso dei linguaggi di Hardware De�nition,

HD, come il Veri Hight Speed Integrated Circuit, VHSIC, Hardware

Description Language, VHDL, e Verilog.

Il linguaggio scelto per descrivere l'architettura implementata �e il VHDL '93

per motivi didattici, essendo stato materia di studio per il corso di Reti Lo-

giche A, e per l'ampio utilizzo che se ne fa praticamente in tutta Europa

per la progettazione hardware che lo porta a essere uno standard de facto in

materia.

Il VHDL �e nato, inizialmente, come progetto del ministero della difesa ame-

2.2 VHDL 24

ricano ed �e diventato standard pubblico nel 1987 tramite l'IEEE, passando

attraverso diversi aggiornamenti �e arrivato all'ultima versione il VHDL '93.

Come in ADA, in VHDL si �e adottata la �loso�a specify and body che impli-

ca la distinzione ed esplicitazione dell'interfaccia e corpo di un componente.

Questa divisione �e molto utile nel momento in cui si desideri realizzare diverse

implementazioni di uno stesso componente, magari con diverse prestazioni,

struttura o logica utilizzata, perch�e infatti VHDL �e uno strumento molto

potente che permette di realizzare un oggetto in moltissimi modi e approc-

ci diversi. La caratteristica principale di questo linguaggio, che permette di

a�rontare problemi con logiche diverse, �e la possibilit�a di scegliere il livello

di astrazione dello hardware. �E infatti possibile descrivere i componenti in

due maniere diverse: una, la pi�u ostica forse e pi�u impegnativa in termini di

codice da scrivere, �e la cosiddetta architetturale l'altra, pi�u semplice per un

programmatore e anche pi�u naturale, �e la comportamentale, behavioural. La

prima consiste nel descrivere il componente nella sua struttura logica, de-

scrivendo quindi le connessioni fra le porte logiche, gli ingressi e le uscite, il

usso di lavoro fra le varie parti avviene in parallelo. La seconda invece per-

mette una descrizione molto simile alla programmazione imperativa, quindi,

avremo i costrutti tipici di questo stile come i cicli for e while, l'if then else e

molti altri, il usso di esecuzione, ovviamente, all'interno di queste strutture,

sar�a di tipo sequenziale.

2.2.1 Entit�a e processi

Circoscrivere e dividere questi due stili profondamente diversi �e indispensa-

bile. Infatti, sono previsti due ambiti diversi per il loro utilizzo. L'ambito di

utilizzo previsto per lo stile architetturale �e quello delle entit�a mentre per

scrivere codice di tipo comportamentale bisogna servirsi dei processi.

Entit�a e processi non sono allo stesso livello nella programmazione ma piut-

tosto la prima contiene la seconda che pu�o anche non venir utilizzata. In

altre parole, per descrivere un componente bisogna de�nirne un'entit�a e la

sua interfaccia: l'interfaccia speci�ca il nome del componente e le sue porte

2.3 Software e strumenti 25

di ingresso e uscita all'interno dell'entit�a, si scrive il codice descrittivo in stile

architetturale inserendo se necessario, uno o pi�u process, che saranno eseguiti

parallelamente, all'interno dei quali si usa lo stile comportamentale.

2.3 Software e strumenti

Per sviluppare l' IP Core e curarne il codice, compilarlo, sintetizzarlo e in�ne

usarlo per poter programmare la scheda si sono utilizzati tre software: ISE

con ProjectNavigator, ModelSim e la Enbedded Development Kit EDK con

Xilinx Plataform Studio che verranno presentati in questo paragrafo.

2.3.1 ISE

Il primo strumento presentato �e stato anche il primo ad essere utilizzato:

Integrated Software Environment ISE, �e un software sviluppato da Xilinx

con la collaborazione della Mentor Graphics per l'interfaccia gra�ca Project

Navigator. ISE �e un'ambiente di sviluppo per progetti di architetture per

FPGA; anch'esso contiene un editor di testi e una serie di strumenti utili per

lo sviluppo del progetto in tutte le sue fasi a partire dal VHDL o Verilog

per �nire con il codice sintetizzato e adatto ad essere portato su EDK. Le

principali funzionalit�a o�erte da ISE sono accessibili direttamente da Project

Navigator nel riquadro D visibile in Figura 2.3 e sono organizzate in cinque

gruppi: Design Entry Utilities, User Constraints, Synthesize-XST, Implement

Design, Generate Programming File. Tramite User Constraints l'utente ha la

possibilit�a di imporre vincoli, in termine di tempi e spazi utilizzati su chip e di

collegare al IP Core dei pin �sici della scheda per poter, ad esempio, utilizzare

dei led. Il gruppo Synthesize, invece, contiene il compilatore per controllare

la sintassi del codice ed il comando per sintetizzare il codice, operazione

indispensabile per la trasposizione del lavoro su un dispositivo FPGA. Sotto

Implement Design si trovano tutte gli strumenti dediti alla �nale traduzione

del codice sintetizzato e mappatura su chip, per alcuni di questi procedimenti

si d�a la possibilit�a di farli fare manualmente all'utente. In�ne,nell'ultima fase


Figura 2.3: Interfaccia gra�ca di Project Navigator

di lavoro, �e assistito dai programmi del gruppo Generate Programming File,

qui si crea il bitstream e tramite Impact si e�ettua il download del bitstream

sul chip. Questi ultimi due gruppi non sono per�o stati utilizzati, a questi

si sono preferiti gli strumenti forniti con EDK per motivi di comodit�a e

maggior supporto nella gestione dell'architettura embedded come si vedr�a tra

due paragra�. Grazie all'interfaccia gra�ca si pu�o avere sempre sottocchio la

struttura del progetto nella �nestra Sources in Project, riquadro A, come si

pu�o vedere in Figura 2.3. Il suo uso �e semplice: si inizia creando un progetto

dal men�u File New project e da qui si scelgono: locazione del progetto, �le

sorgenti e tutte le impostazioni riguardanti il tipo di chip utilizzato perch�e in

questa fase sono subito importanti i dettagli tecnici del mezzo per permettere

la sintesi e le ottimizzazioni. Nel caso ci sia bisogno di apportare modi�che al

codice nel riquadro B, si pu�o visulizzare e modi�care con l'editor incorporato

il codice, mentre nella �nestra bianca in basso,riquadro C, si pu�o notare la


consolle con tutto lo spazio dedito a comunicare i messaggi restituiti dai

compilatori. L'utilizzo di questo software, che in pratica fa le stesse cose che

fanno alcuni strumenti di EDK, �e motivato dalla sua comodit�a. A di�erenza

di EDK, che come si vedr�a nei prossimi paragra� non lo permette, in questo

ambiente �e possibile controllare la correttezza e sintetizzabilit�a del codice in

breve tempo, con il comando compile, ed �e possibile sintetizzare il codice un

in un secondo tempo, inoltre si possono sintetizzare anche singole parti e non

tutto l'IP Core, cos�� da ridurre i tempi nel caso si riscontrino problemi in una

parte del lavoro.

2.3.2 Modelsim

Modelsim �e un'ambiente di sviluppo per codice VHDL e Verilog sviluppato

dalla Mentor Graphics e supportato dalla Xilinx per sviluppare codice per le

sue FPGA. Questo ambiente integra svariati strumenti tra i quali si segnalano

oltre al compilatore: un editor di testo per modi�care il codice, un workspace

per la gestione delle librerie dei progetti, un prompt di comandi per integrare

e completare i comandi selezionabili tramite l'interfaccia gra�ca visibile in

Figura 2.4Inoltre attraverso il men�u tools �e possibile accedere a tutta una

serie di funzionalit�a indispensabili per testare il codice tra i quali:

� Data ow: che consente di visualizzare gra�camente il dispositivo mo-

strando in modo schematico le porte d'ingresso e d'uscita. Il Data ow

pu�o essere molto utile per far maggior chiarezza sulla struttura del no-

stro componente, ed �e possibile veri�care se sono stati commessi even-

tuali errori nel de�nire le porte.

� Wave: consente di visualizzare un area gra�ca sulla quale sono ripor-

tati un asse Y per rappresentare i vari segnali (I/O) del dispositivo e

un asse temporale X.L'utility wave risulta fondamentale per il nostro

scopo, in quanto permette di visualizzare le forme d'onda associate ai


Figura 2.4: Interfaccia gra�ca di Modelsim

vari segnali nel corso dell'esecuzione della simulazione.

� Signal: permette di visualizzare tutti i segnali in ingresso e in uscita

dal dispositivo; da qui �e possibile impostare un valore ben de�nito per

ciascuno di essi.

Il lavoro sotto Modelsim viene organizzato all'interno di un progetto facil-

mente generabile con una procedura automatizzata che permette di crearlo

secondo le proprie esigenze, potendo scegliere ubicazione, linguaggio adotta-

to, VHDL o Verilog sono i linguaggi supportati, e permette di aggiungere

nuovi �le o �le gi�a esistenti in qualit�a di testbench o di architettura. Questi

progetti contengono tutte le informazioni riguardanti il lavoro e la sessione

di lavoro, sono organizzati in una directory che contiene, quindi, i �le con i


sorgenti, la working library, metadati riguardanti la sessione, le librerie locali

ed eventuale documentazione.

Le principali funzionalit�a utilizzate sono la compilazione e la simulazione.

Per compilare �e su�ciente selezionare il �le del progetto che si desidera com-

pilare e clickare sull'icona compile, si avvier�a il processo di compilazione e i

risultati saranno comunicati dalla �nestra di prompt. Per simulare, invece,

bisogna selezionare simulate dal men�u a tendina Simulate in alto come si

vede in Figura 2.5

Figura 2.5: Men�u di simulazione

2.3.3 EDK

Embedded development kit ,EDK) �e l'ultimo strumento presentato. Come

suggerisce il nome, EDK �e una raccolta di applicazioni indispensabili per

la realizzazione di software e descrizione hardware per un sistema embed-

ded. Tramite EDK infatti si possono creare e modi�care i �le Microproces-

sor Hardware Speci�cation, MHS, ed Microprocessor Software Speci�cation,

MSS, �le utilizzati dai tool; si possono inoltre personalizzare le librerie, i dri-

ver e i gestori di interrupt. Tra le sue molteplici funzionalit�a, EDK annovera

la possibilit�a di aggiungere e modi�care core e i relativi parametri, aggiun-

gere bus e segnali di connessione per la generazione di un MHS �le e anche


MSS, supporta tutta una serie di strumenti di sviluppo successivamente elen-

cati, dispone di un editor che permette di visualizzare il lavoro e modi�carlo

sotto forma di diagrammi a blocchi ed ha un completo sistema di gestione

del progetto come si pu�o vedere in Figura 2.6 che mostra l'interfaccia gra�ca

dell'ambiente di sviluppo.

Figura 2.6: Interfaccia gra�ca di EDK

Come si vede in Figura 2.6 il piano di lavoro �e diviso in quattro parti: in alto

sviluppata per tutta la larghezza sono presenti i men�u a tendina dai quali

si accede a tutte le opzioni e funzinalit�a di EDK. Sotto i men�u a tendina si

trovano i bottoni di accesso rapido ai tool principali in seguito mostrati oltre

ai classici bottoni per il salvataggio e apertura di progetti. In Figura 2.6 lo

spazio �e diviso in tre grandi riquadri dall'aspetto familiare a quelli di Project

Navigator, infatti la casa realizzatrice dell'interfaccia gra�ca �e la medesima


per entrambe le applicazioni. Nel riquadro A, sulla sinistra, tramite click sul-

le linguette in alto, �e possibile accedere a diverse schermate. Nella sezione

System, si ha una visione d'insieme del progetto e di tutti i sui �le cos�� da

poterli aprire e visualizzare sul riquadro grigio sulla destra. Con Application

di accede alle opzioni dei tool utilizzati come per esempio quelli di compila-

zione e al �le System.c che contiene i comandi eseguiti dal processore. Con

Options invece si gestiscono alcuni parametri di compilazione. In�ne, tramite

Symbols si accede al men�u di tutti i componenti disponibili in libreria per

aggiungerli a un progetto.

Tutto il progetto �e accessibile quindi, dal men�u System rappresentato in

Figura 2.7, le prime voci, precedute da un'incona a forma di chip, sono i

componenti presenti in tutta l'architettura e sempre clickandoci sopra si ac-

cede a un men�u con la voce propriet�a in cui si possono vedere e modi�care

i principali parametri. Sotto la voce projectFiles ci sono i �le di sistema che

sono MHS, che descrive l'hardware presente nel progetto sotto forma di elen-

co con nomi e valori di bus, MSS che de�nisce le interfacce dei componenti,

PBD che �e una descrizione stile CAD del progetto e che sar�a successivamente

descritta.

I principali tool supportati e ai quali si �e prima accennato sono:

� Library Generator , LibGen, per la personalizzazione delle librerie, dri-

vers e gestori di interrupt. Partendo dai �le .mdd, che contengono l'e-

lenco delle librerie necessarie alla compilazione dei driver e la locazione

di questi ultimi, compila i driver seguendo le indicazioni contenute nel

�le make�le per ogni singolo core presente nel sistema dedicato.

� Compilatori GNU per compilare, assemblare e linkare i programmi.

� Compile Program Sources, tramite il compilatore GNU GCC compi-

la i �le del sistema, tipicamente chiamati System0.c, System1.c Sy-

stem[numero processori presenti].c, generando il �le executable.elf.


Figura 2.7: Men�u System di EDK

� Plataform Generator, PlatGen, richiamato col bottone generate netli-

st, genera una gerarchia di netlist NGC che fa capo a un �le NGD,

Native Generic Database, ci�o signi�ca che ogni core presente nel �le

MHS e quindi nel sistema viene sintetizzato, quindi si ottengono �le

che contengono elenchi di componenti, porte logiche e interconnessioni

adeguatamente collegate tra loro.

� Generate BitStream: richiama il programma XFlow con le opzioni con-

tenute nei �le fast runtime.opt e bitgen.ut che si trovano nella cartella

etc del progetto. A sua volta XFlow richiama gli strumenti di imple-

mentazione di ISE che generano il bitstream.

2.4 La Metodologia 33

� Update Bitstream, questo comando invoca il programma bitinit, in que-

sto stadio si ha che la parte hardware e la parte software del lavoro si

fondono a formare una unica entit�a sotto forma di �le download.bit

pronta a essere copiata sul chip tramite il programma IMPACT o tra-

mite il programma situato in etc/download.cmd richiamato dal tasto

Download.

� Simulation Model Generator , SimGen, genera il modello hardware per

la simulazione e i �le di compilazione per il sistema, cos�� da permettere

la simulazione dell'intero sistema in ambiente modelsim.

In�ne particolare attenzione meritano due strumenti per comodit�a e utilit�a:

l'editor CAD per l'architettura e il wizard per importare IP Core.

Per attivare l'editor CAD �e su�ciente fare doppio click sul �le .pbd prima

descritto nel riquadro A, per far comparire nel riquadro B il disegno sche-

matizzato dell'architettura che si sta realizzando. Da questo schema facendo

doppio click si puo' accedere a sommario delle caratteristiche di ogni compo-

nente come lo spazio di indirizzi, gli eventuali parametri, le porte utilizzate

ed eventuali gestori di interrupt. Inoltre usando gli strumenti, comparsi in-

sieme al CAD nel men�u in alto, si possono disegnare altre reti o aggiungere

altri componenti.

Il wizard per importare IP Core �e particolarmente utile dal momento che in

pochi passi guida l'utente all'inserimento di un nuovo core sgravando l'utente

del compito di indicare le porte di ingresso e uscita di dover copiare a mano

i �le nelle cartelle adatte e di molti altri compiti ora divenuti automatici e

quindi meno soggetti a errori.

2.4 La Metodologia

In questa sezione si spiega il modus operandi seguito per svolgere il progetto,

cos�� da permettere un usso di lavoro ordinato, e�ciente e veloce.


Comprensione del Problema

Il primo passo seguito �e stato quello di comprendere al meglio le speci�che del

problema: capire che cosa si deve realizzare, studiando il documento del NIST

riguardante l'AES, e come realizzarlo, cercando di sempli�carlo dividendolo

in subproblemi da sviluppare singolarmente nelle fasi successive.

Creazione delle entit�a e funzioni in VHDL

Una volta identi�cati i subproblemi si �e scelto quali implementare come entit�a

e quali come funzioni all'interno di un package. Si sono realizzate tutte le

interfacce e, dopo un'attenta analisi, si sono creati i tipi principali di segnali

coi quali far comunicare e funzionare queste interfacce, segnali che avrebbero

in uenzato tutto il lavoro dall'inizio alla �ne.

Implementazione

Successivamente si �e passati alla fase implementativa: tranne poche eccezioni,

per la maggior parte delle entit�a si �e scelto di implementarle in VHDL usando

i process. Ci�o signi�ca che si �e scelto di scrivere in stile behavioral, e lo si �e

fatto per motivi di comodit�a e per la semplicit�a col quale un informatico pu�o

imparare questo stile. Per le funzioni all'interno del package invece non c'�e

stata scelta dato che la sintassi VHDL prevede solo costrutti behavioral per

la descrizione di queste ultime.

Veri�ca

Ogni funzione ed entit�a �e stata testata inserendola in un apposita architettura

nel quale si controllavano i valori restituiti dell'entit�a/funzione a seconda

dell'ingresso forzato dall'autore. I valori utilizzati erano solitamente quelli

forniti nel documento del NIST e di cui si conoscono gi�a i risultati relativi

generati dalla coppia valore-processo.

Sintesi

La sintesi si �e fatta una volta veri�cato il funzionamento dell'intero sistema

tramite Project Navigator e la si avvia con il comando Synthesize. Questa

operazione ha triplice funzionalit�a:

1. Controlla la presenza di eventuali errori nel codice mediante il compi-

latore incorporato.


2. Controlla l'assenza di strutture VHDL non supportate dai dispositivi

FPGA e con le quali quindi l'IP Core non pu�o essere descritto.

3. Sintetizza, misura le prestazioni e le risorse occupate dal core permet-

tendo di veri�care quindi la possibilit�a di inserire il core all'interno di

una determinata archittura.

Adattamento per FPGA

L'adattamento del codice ad una architettura sincrona �e un'operazione in-

dispensabile per poter portare il codice scritto come archittura autonoma

all'interno di una architettura pi�u grande con un clock, pi�u bus e un pro-

cessore. Per questa operazione bisogna ridisegnare le interfaccie delle entit�a

a�nch�e siano compatibili col bus di sistema. Inoltre, per far da tramite tra

il software della scheda e la IP Core progettata, bisogna scrivere dei driver e

il �le sistem0.c.

Veri�ca �nale e test

Per testare il lavoro di trasporto su FPGA prima accennato, si utilizza sempre

modelsim per il codice e una volta appurato il suo funzionamento si possono

testare i driver e il sistem.c su scheda provando a programmarla.

Capitolo 3

Implementazione

In questo capitolo si esporrer�a tutto il procedimento di implementazione del

progetto, evidenziandone i passi principali, le di�colt�a incontrate e le scelte

prese. Nell' esporre questo processo si seguir�a l'ordine temporale col quale

sono stati a�rontati. Si inizier�a dunque con la descrizione dell'architettura

in VHDL analizzando il codice suddiviso secondo il criterio di funzionalit�a e

anche di modularit�a col quale era stato inizialmente concepito.

3.1 Traduzione dell'algoritmo in codice VHDL

Il primo passo per codi�care tutto l'algoritmo �e stato quello di dividere il

lavoro in diverse parti pi�u semplici da codi�care, da testare e soprattutto da

poter riutilizzare o aggiornare. La scelta �e stata quella di creare una libreria

o package poi chiamata util che si sarebbe sviluppata con codice e relativo te-

sting, parallelamente a quello di due architetture separate: il keyexpander e il

cipher sviluppati necessariamente in ordine di apparizione e testati separate-

mente Per scrivere il codice dell'algoritmo si sono utilizzate soluzioni diverse

a seconda del problema incontrato; il risultato �nale sono stati comunque

due �le: il motivo di questo passaggio dalle 2 architetture pi�u package ad una

architettura pi�u libreria �e dovuta ad una scelta di semplicit�a e di maggiore

velocit�a. L' implementazione che comportava il completamento del keyexpan-

3.1 Traduzione dell'algoritmo in codice VHDL 37

der con la parte relativa al cipher, infatti, risparmia la creazione di una terza

architettura necessaria per far comunicare una architettura keyexpander e il

cipher. L'architettura, presente nel �le algo.vhd �e nominata cipher mentre

per il package, si veda il �le util. In linea di massima si �e preferito scrivere il

codice VHDL attenendosi allo stile di programmazione imperativa, sfruttan-

do quindi i process con le sue costruzioni tipiche con cicli for e while e l'uso

delle funzioni implementate nel package util.

3.1.1 La libreria util

La libreria util �e divisibile idealmente in due parti: una parte in cui si di-

chiarano tipi e costanti e una in cui si de�niscono le funzioni. Nella prima si

trovano due livelli di tipi: Type e Subtype, ovvero tipo e sottotipo; i sottotipi

sono bit4, bit8 e word, che sono raggruppamenti di segnali in half-byte, byte

e word utili per la costruzione degli altri tipi e ottenuti come std logic vector

di lunghezze diverse. Al secondo livello dichiarati come TYPE si trovano se-

gnali composti dai SubType essi sono:

� Stato type: che rappresenta lo stato della computazione, qui imple-

mentato come un array di 16 bit8.

� key type: un array di 16 std logic vector da 8 bit che �e utilizzato per

variabili che conterranno la chiave.

� reg w: un array di 44 word che contiene la chiave espansa.

Successivamente si trovano i tipi con type, sbox type e div type: sono

vettori di interi utilizzati successivamente per dichiarare costanti pi�u avanti

descritte. Dopo la dichiarazione dei tipi, si trovano quindi le costanti indi-

spensabili per risolvere semplicemente funzioni che richiederebbero complesse


e costose operazioni matematiche, facendo semplicemente delle lookup su ta-

belle. La prima, con type, la si usa nella dichiarazione del vettore di costanti

Rcon, la seconda, sbox type, per la costante S box mentre la terza, Div type,

la si usa per ottenere l'operazione mod.

Nella seconda ideale parte della libreria sono presenti le funzioni: Rotword,

Sostituisci, Sostituisci 4. La funzione Rotword implementa l'omonima fun-

zione speci�cata dallo standard: molto semplicemente prende in ingresso una

parola da 32 bit composta idealmente da 4 byte: a, b, c, d e d�a in uscita una

parola da 32 con i byte nell'ordine b, c, d, a scomponendo l'input in 4 va-

riabili da 1 byte e ricomponendolo in uscita nell'ordine desiderato servendosi

dell'operatore di concatenamento. La funzione Sostituisci 4 implementa la

funzione AES chiamata SuBWord e applica ad ogni singolo byte della parola

da 32 bit di ingresso la seguente istruzione:

TO UNSIGNED(SBOX(To INTEGER(unsigned(input(31 downto 24)))), 8)

che prende un gruppo di 8 bit lo trasforma in un numero intero che viene

usato come indice del vettore di costanti SBOX, ottenendo cosi' la sostitu-

zione da tabella desiderata, ma in forma di intero. Per restituire un vettore

di std logic vector si �e la funzione to unsigned al quale poi si applica un cast

a std logic vector. La stessa cosa viene fatta da Sostituisci, ma su un solo

byte.

3.1.2 Il KeyExpander

L'algoritmo �e codi�cato sul �le CodAlgo.vhd in maniera molto simile allo

pseudo codice dato dal �ps-197 e presente in questo documento in Figura

1.3. L'entit�a si presenta come un'archittura con tre porte: key e clock come

segnali di ingresso ed s come segnale di uscita contenente la chiave espansa.

Subito dal codice si pu�o notare che si �e preferito istanziare delle variabili di

appoggio alla computazione piuttosto che dei segnali per la loro continuit�a di

aggiornamento pi�u semplice e familiare ad un programmatore per la gestione,


Figura 3.1: Immagine RTL dell'archittettura

tra queste variabili si segnala la variabile w che contiene la chiave espansa

�no alla �ne del procedimento. Una volta testata la funzionalit�a del codice,

con la metodologia indicata nel capitolo sul testing, per esigenze di sviluppi

futuri del lavoro come periferica per FPGA, si �e provato a sintetizzare questa

parte di lavoro con Project Navigator e si �e constatato, come si spiega meglio

nel capitolo Sintetisi con Project Navigator, che era necessario un passaggio

della forma del codice con for ad una forma con macchine a stati, forma

che ovviamente �e rimasta anche per la codi�ca successiva del cipher. Nella

macchina a stati rappresentata in Figura 3.2 i cicli for sono stati trasfomati in

stati ai quali, mediante l'utilizzo di contatori per determinare la terminazione

del loop, ci si ritorna ciclicamente �no all'esaurimento del numero di iterazioni

predeterminato e il conseguente passaggio a un altro stato. In cod2 si nota

che all'interno dello stato '0' si trova un ciclo col quale si copia la chiave nelle

prime quattro celle del registro della chiave espansa. Al termine del ciclo, ip,

che �e il contatore delle iterazioni, viene incrementato di 4 e lo stato prossimo

statop passa a uno, nel successivo fronte di clock anche lo stato passer�a a uno,

grazie al processo controlla che si occupa appunto di aggiornare lo stato ad

ogni fronte. Nello stato uno invece si esegue del codice equivalente al secondo

ciclo for che si vede in Figura n.1, sempre con l'ausilio del segnale ip che una


Figura 3.2: Schema della macchina a stati

volta superato il valore 43 provocher�a il passaggio allo stato 2, stato in cui

termina il calcolo e si assegna alla porta di uscita s il valore contenuto in w.

3.1.3 Il Cipher

Come precedentemente esposto, si �e preferito scrivere il cipher come com-

pletamento del codice scritto per il keyexpander, aggiungendo altri stati a

quelli gi�a precedenti. Per prima cosa si �e modi�cata l'interfaccia dell'entit�a:

ora ha come porte di input la chiave, il blocco da cifrare e il segnale di clock;

in uscita invece ha un output di tipo stato type che �e il blocco cifrato. In

questa fase sono state aggiunte nuove funzioni alla libreria del progetto, util.

La prima �e AddRoundKey, descritta nell'introduzione all'AES, �e stata qui

implementata facendo uno xor tra lo stato in input e celle del registro di

chiave espansa determinata dal round, ovvero dal numero di iterazioni di

calcolo gi�a svolte. La funzione ShiftRows �e stata ottenuta assegnando diret-

tamente a ogni singola cella dello stato attuale la cella dello stato successivo

3.2 Adattamento per FPGA 41

che si pu�o determinare guardando la Figura 3.3 La funzione SubBytes scorre

Figura 3.3: funzione shiftRows

tutto l'array dello stato e per ogni cella applica la funzione Sostituisci. In

ultimo la Mix Columns �e stata implementata con l'ausilio di altre 3 funzioni:

la LoShift, che fa lo shift a sinistra di un bit per un bit8, creata pur sapendo

dell'esistenza della funzione ssh che non si �e riuscita ad utilizzare. La funzione

xtime02 ottenuta facendo uno shitf a sinistra con LoShift e uno xor con la

parola 1b condizionato dal valore del primo bit della parola di ingresso alla

funzione. L'ultima funzione utilizzata �e stata xtime03 che fa uno xor tra la

parola in ingresso e il risultato della xtime02 sempre sulla parola d'ingresso.

Tornando alla codi�ca dello pseudo codice si inizia con una modi�ca allo

stato '2': non c'�e pi�u l'assegnazione verso la porta d'uscita, visto che �e stata

eliminata, ma si applica il primo AddRoundKey e si passa allo stato 3. Il

terzo stato si esegue 10 volte come il ciclo for in Figura 1.3 e infatti, ciclo e

stato eseguono la stessa serie di operazioni che una volta terminati portano

allo stato 4 e da li' al 5 con l'assegnazione del valore contenuto nella variabile

temporanea al segnale di uscita.

3.2 Adattamento per FPGA

In questa sezione si a�ronta il problema di portare il codice �n qui realizzato

in un'architettura pi�u grande funzionante su FPGA e tutti i relativi problemi


di interfacciamento con il bus dell'architettura e gestione di interrupt.

3.2.1 L'architettura

L'architettura utilizzata, mostrata in Figura 3.4 , �e basata sul un processore

Microblaze connesso a diversi bus che gli permettono di raggiungere diversi

altri componenti tra cui un modulo di debug, un opb gpio, un opb uartlite

e l'IP Core Kver la cui istanza �e qui chiamata kver 1 e, come suggeriscono

i primi due nomi, tutte e tre questi componenti sono connessi via On-chip

Peripheral Bus, OPB. Il processore Microblaze �e un soft core dedicato, con un

set ridotto di istruzioni a 32 bit, Reduced Instruction Set Computer, RISC,

ottimizzato per l'implementazione su FPGA Xilinx. Tra le caratteristiche di

questo processore ci sono i data bus a 32-bit conformi alla speci�ca IBM per

il bus OPB che, come abbiamo detto, �e il bus principalmente utilizzato in

questo lavoro. Questo bus �e parte della architettura CoreConnect progettata

da IBM, ed si tratta di un bus sincrono generico, ideato per una semplice

connessione di dispositivi onchip. La Opb gpio viene utilizzata semplicemente

per l'accensione di un led mentre la Uartlite viene usata per comunicare

via HyperTerminal eventuali messaggi durante l'esecuzione del programma

eseguito dal processore.

3.2.2 L'IP Core Kver

Il nome Kver deriva da un susseguirsi di vicende di sviluppo, prove, test, ri-

scrittura e rinominazioni tipiche di questi lavori; comunque K sta per KeyEx-

pander mentre ver �e l'abbreviazione di versione; il nome per�o �e rimasto que-

sto nonostante la funzionalit�a si sia decisamente modi�cata. Come abbiamo

detto l'IP Core �e tutto il dispositivo e per funzionare ha bisogno di diversi

altri elementi. Per avere un quadro d'insieme si mostra un'immagine della

gerarchia delle cartelle che lo contengono. Questo IP Core �e quindi frutto del

lavoro �n qui fatto, lavoro che �e stato riorganizzato nello schema in Figura


Figura 3.4: Architettura

3.5. Il codice VHDL si trova sotto la cartella hdl, li si trovano due �le ora: il

kver core.vhd contiene appunto il core comprensivo di libreria util, keyexpan-

der/chiper con l'aggiunta di nuovi processi che saranno spiegati pi�u avanti.

I �le sotto data sono �le necessari nella gestione da parte di EDK della IP

Core e contengono i settaggi della stessa come l'indirizzo di base, locazione

dei driver, porte, bus a cui �e collegata e altre simili. In source si trovano i

�le dei driver, sono due: uno contiene il driver vero e proprio ed �e un �le .c,

l'altro �e un �le di header .h il funzionamento di entrambi sar�a mostrato nel

paragrafo 3.2.5. In�ne il �le make�le �e un �le di script con le indicazioni per

i compilatori.


Figura 3.5: Gerarchia dell'IP Core

3.2.3 Interfacciamento con bus opb

In questa fase l'obiettivo �e inserire il codice �n qui realizzato nell'interfaccia

che poi comunicher�a con il bus opb. A tale scopo si utilizza la periferica Pse-

lect. Tale core, utilizzato anche in altri core della libreria di IP Core della

Xilinx come opb timer e opb uartlite, ha come compito quello di selezionare

la periferica, dal nome peripheral select, ovvero abilitarla e renderla attiva;

in particolare esso alza il segnale CS, per fornire alla periferica una sorta di

enable grazie al quale essa risulta sensibile ad eventuali dati provenienti dal

bus o viceversa. Il segnale CS viene attivato nel momento in cui lo spazio

di indirizzamento del bus utilizzato coincide con lo spazio di indirizzamento


Figura 3.6: Interfacciamento al bus

assegnato alla periferica. Al processo Calc del �le cod3, sono stati a�ancati

due processi: read from registers e write to registers per la lettura e scrit-

tura sui registri per la comunicazione del core con l'esterno. In opb kver si

dichiarano le interfacce e si uniscono tramite portmap la periferica di pselect

e il core creato, inoltre si sviluppa il processo di latch indispensabile per l'i/o

della periferica. All'interno di ver module �e presente il core vero e proprio.

Per far fronte alla necessit�a di interfacciamento il codice �e stato notevolmente

modi�cato a partire dall'interfaccia dell'architettura. Essa non presenta pi�u

le porte di tipo key type e stato type per l'input e output bens�� una porta

read data e write data che insieme alla porta di interrupt saranno fonda-

mentali per la comunicazione da e verso l'esterno con un processo pi�u avanti

descritto. Dopo la descrizione delle varie porte inizia la descrizione dell'ar-

chitettura con i segnali interni per far funzionare i process che seguono. Il

primo process che si vede �e il process Calc che �e praticamente lo stesso codice

derivante dal lavoro con Project Navigator con una modi�ca: il processo di

espansione della chiave non parte �ntanto che la variabile key ready, di tipo

intero non varr�a zero. Quindi il process inizia dallo stato 5 e rimane li' �nch�e

la key ready non verr�a modi�cata a zero con conseguente modi�ca dello stato

prossimo, statop. Questa variazione era necessaria perch�e, ovviamente, biso-

gna aspettare che la chiave sia presente in qualche registro della periferica,


Figura 3.7: Interfaccia di pselect

prima che si inizi a fare calcoli su di essa e sul blocco di input. Della copia

del plaintext e della chiave da utilizzare sui registri, se ne occupa il processo

Write to register e lo fa nel seguente modo: a fronte di un evento di clock

con livello alto, segnale di enable alto e RD NWR basso a seconda dell'o�set

dell'indirizzo, memorizza il dato sul registro indirizzato, ogni registro viene

copiato con la stessa procedura con eccezione dell'ultimo che alza il segnale

key ready e f�a partire il processo Calc. Via driver si garantir�a che l'address

0C, ovvero quello che alza key ready, sar�a inviato per ultimo cosi' che tutta

la chiave e plain text sar�a sicuramente copiata sui registri e il processo di

espansione della chiave potr�a partire facendo calcoli su dati utili. Una volta

elaborato il crittogramma Calc salva il risultato sul registro output e alza

il segnale di interrupt reg intr diretto al driver che richieder�a quindi la di-

sponibilit�a della soluzione su registri mediante la funzione read to register.

Quest'ultima funzione a seconda dell'o�set dell'indirizzo rende disponibile

sul registro reg data una corrispondente riga del registro output.

3.2.4 Sintesi con Project Navigator

Questa fase consiste nella compilazione e nella sintesi del codice tramite Pro-

ject Navigator per renderlo eseguibile su una FPGA che impone restrizioni


sulla sintassi VHDL e sulle dimensioni dell'architettura: il fatto �e che all'inizio

VHDL non f�u ideato come possibile passaggio di progettazione in prospettiva

di una sintesi e molti suoi costrutti non sono supportati da questi processi.

Tuttavia per quanto riguarda la sintassi non si sono riscontrati problemi,

come si nota dal codice del �le cod3 ed util nei quali infatti non sono presenti

cicli while o altri operatori non consentiti, per cui la compilazione ha avuto

successo al primo tentativo. Nella fase di sintesi, invece, si sono trovate delle

di�colt�a dovute alla procedura di elaborazione, da parte del software, dei

cicli for. La procedura per la sintesi dei for prevede che tutte le strutture,

necessarie per completare un ciclo for, vengano ripetute tante volte quante

sono le iterazioni per un utilizzo in parallelo, con un notevole assorbimento

di risorse in termini di slice. In particolare ci�o succedeva al codice del �le

codAlgo, spiegato precedentemente, in quanto �e basato sostanzialmente su

un ciclo ripetuto 40 volte, all'interno del quale si costruiscono 4 tabelle da

256 numeri interi che portava puntualmente a utilizzare pi�u del 390% del-

le risorse. Tale problema �e stato risolto ristrutturando l'architettura come

una macchina a stati; ricorrendo infatti a questa tecnica, il sintetizzatore

non ripete pi�u le strutture ma, anzi, riconosce e identi�ca l'algoritmo come

macchina a stati e ottimizza la netlist per tale struttura come si vede dall'e-

stratto di un report di sintesi dell'IP Core in Figura 3.8. Questo sistema che

Figura 3.8: Riconoscimento della macchina a stati

oltre ad essere molto costoso in termini di spazio �e anche inutile agli scopi

dell'algoritmo che attende comunque sempre la computazione del ciclo prece-

dente. La prima macchina a stati sviluppata, osservabile nel �le cod2 consta

di 2 stati, che altro non sono che i 2 cicli for precedenti riscritti in maniera


diversa, tali da essere meglio sintetizzati, e da un altro processo che gestisce

l'aggiornamento del segnale rappresentante lo stato per il passaggio da uno

stato all'altro. Lo stato della macchina �e rappresentata da un segnale di tipo

intero chiamato stato. Questo segnale �e inizializzato a zero cosi' che, quando

inizia la computazione, si entra subito nella prima parte di codice nella quale

si copia la chiave nel registro. Una volta �nita questa fase il segnale di stato

si porta al valore di uno che porter�a l'esecuzione alla seconda parte. Una

volta terminata lo stato della macchina passa a 2 in cui si copia il contenuto

della variabile w nel segnale di uscita s. Inoltre, nel tentativo di diminuire le

risorse impiegate, si �e realizzato l'operazione di divisione per 4 utilizzando

una tabella monodimensionale al cui interno sono inseriti i risultati della di-

visione dell'indice del array per 4, cosi' che un accesso per lookup al vettore

fornisce il risultato della divisione. Il risultato della sintesi sar�a poi punto di

partenza per l'analisi per le prestazione nel capitolo sui risultati sperimentali

3.2.5 I Driver e il �le System.c

I Driver e il �le System.c hanno la funzione di permettere al processore Micro-

Blaze di utilizzare la IP Core in tutte le sue parti: dalle funzioni di scrittura

sui registri per l'ingresso e uscita alla gestione degli interrupt. Per adesso si

�e scelto di scrivere driver di basso livello infatti li si pu�o trovare sotto src

con nome kver I a indicare che sono di livello 0, in pratica sono de�niti nel

�le .h e sfruttano la libreria Xio.h e le funzioni Xio Out32 e Xio In32. Ar-

rivati a questo punto �e necessario, se non indispensabile, dare uno sguardo

complessivo al funzionamento di tutto il meccanismo �n'ora creato, soprat-

tutto per scrivere il �le System.c. Nel �le kver module i tre processi pi�u

interessanti sono: Calc che fa i calcoli di espansione della chiave secondo l'al-

goritmo Rijndael; Read from registers che a seconda dell'indirizzo mandato

rende disponibile sulla porta reg data una sola parola della chiave espan-

sa e il processo write to register che copia, a seconda sempre dell'indirizzo

passato, il dato presente sulla porta Write data sul registro di key relativo.

Quello che deve fare System.c �e di coordinare queste operazioni: quindi per


prima cosa invia tramite la funzione kver mWriteReg, all'o�set dato dalla

costante de�nita in libreria KEY0/1/2/3, un intero unsigned che sarebbe la

prima/seconda/terza/quarta parte di chiave. Una volta consegnato l'ultimo

bit della chiave, si alza una specie di interrupt interno alla periferica: il segna-

le key ready di cui sopra si �e parlato, esso causa l'inizio dell'elaborazione che,

a sua volta, una volta terminata, alza l'interrupt alzando il segnale reg intr

a signi�care che il risultato �e disponibile. All'interno del System.c quindi si

trova una funzione per gestire gli interrupt che kver interrupt hundler. Per

gestire gli interrupt non f�a altro che controllare se il registro con l'interrupt �e

settato alto e nel caso fa partire una routine. La routine consiste nel copiare

i registri con il testo cifrato disponibile sugli o�set BLOCK0, BLOCK1 ecc...

In�ne abbassa il segnale di interrupt.

Capitolo 4

Test e conclusioni

In questo capitolo si espongono le metodologie di veri�ca del funzionamento

dell'IP Core in tutte le fasi di sviluppo secondo l'ordine col quale sono state

eseguite. Si mostrar�a prima il test del codice VHDL e successivamente i passi

seguiti per provare l'IP Core sul chip. In�ne si tireranno le somme del lavoro

�n qui eseguito e si prospetteranno i possibili sviluppi futuri.

4.1 Veri�ca del codice VHDL

Il test del codice �e stato e�ettuato in diversi modi a seconda del problema

a�rontato. Questa sezione serve a mostrare come si �e eseguito il testing di

tutto il codice VHDL nelle varie versioni e parti. Partendo dalla fase iniziale

col testing delle singole funzioni arrivando alla prova �nale di tutto l'IP Core

nel complesso. Ogni funzione, quindi, e' stata testata singolarmente richia-

mandola, in una generico testbench in Figura 4.1 con dati presi dalle tabelle

presenti nel documento �ps-197. I risultati si sono ottenuti simulando l'ar-

chitettura mediante Modelsim e osservando i valori di res1 e res2 sul monitor

dei segnali o della memoria presenti in nel medesimo programma. Per testare

invece nella totalita' il codice del cipher, si e' utilizzata una architettura,

testcipher.vhd, che al suo interno crea un istanza del cipher, gli passa una

chiave in ingresso e ne registra l'uscita su un altro registro. Il confronto dei

4.1 Veri�ca del codice VHDL 51

Figura 4.1: Architettura per il test

dati �e stato attuato poi a mano con dati sicuramente corretti, forniti dal do-

cumento �ps-197, che in una tabella fornisce chiave e relativa chiave espansa

calcolata.

La chiave data e': 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c

La chiave espansa la si puo' leggere a pagina 52 del documento �ps-197 [10]

nell'ultima colonna.

Anche per il testing del cipher si e' usata un'architettura simile ma con in-

gressi ovviamente diversi. Questa volta quindi i dati sono la chiave e il blocco

in ingresso e in uscita si ottiene un altro blocco di tipo stato type che poi �e

il crittogramma.

Si e' provato con i dati:

4.2 Prove su FPGA 52

Plain Text = 32 43 f6 a8 88 5a 30 8d 31 31 98 a2 e0 37 07 34

Cipher Key = 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c

Che hanno dato in uscita

Output : 39 25 84 1d 02 dc 09 fb dc 11 85 97 19 6a 0b 32

Plain text: 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee �

Key: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f

Output : 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a

Anch'esso con esito positivo.

4.2 Prove su FPGA

In questo sottocapitolo si presenta la fase in cui, una volta veri�cato il funzio-

namento del codice, si prova a programmare il chip. Strumenti fondamentali

per questa parte sono EDK con il generatore di bitstream, l'inizializzatore di

bram e il programmatore, download bitstream.

4.2.1 Generare il bitstream

Arrivati a questo punto, ci si trova con l'IP Core gi�a sintetizzato con Project

Navigator e inserito nella gerarchia corretta, a questo punto si ripete l'ope-

razione di sintesi con il programma di EDK. Bisogna, infatti, essere stati

abbondanti con le risorse inutilizzate segnalate dalla sintesi di ProjectNa-

vigator nel riassunto Resource Report di cui si pu�o vedere un esempio in

Figura 4.2. Gi�a un utilizzo del 90 % segnalato da quest'ultimo su qualsiasi

valore, quale qu�o essere Number of Slices o Number of 4 input LUTs, e con

la sintesi con EDK si avr�a un sovrautilizzo, overmap, delle risorse, da ci�o,

l'indicazione di stare sotto il 90%, questo comportamento �e dovuto ai diversi

parametri che i due compilatori possono avere. Una volta e�ettuata la sintesi

con Generate Netlist si ha il responso de�nitivo, se non ci sono errori si pu�o

generare il bitstream col comando apposito.

4.2 Prove su FPGA 53

Figura 4.2: Resource Report sotto Project Navigator

4.2.2 Download del BitStream

La programmazzione vera e propria del chip avviene ora: una volta resettata

tutta la scheda, per fare ci�o �e su�ciente staccare e riattaccare l'alimentazione,

si pu�o dare il comando ad EDK di e�ettuare il download del bitstream. Si

copier�a quindi il bitstream in memoria e si programmer�a la scheda tutto in

automatico. Prima per�o di partire con il download si deve aprire una sessione

di telnet sulla porta COM impostata alla velocit�a di 19,200bit per secondo.

Una volta completato il download del bitstream la periferica inizier�a subito a

Figura 4.3: Icona del comando Download

svolgere le sue funzioni secondo le direzioni del processore e del �le System0.c,

eventuali output si possono vedere dalla sessione di telnet.

4.3 Risultati sperimentali 54

4.3 Risultati sperimentali

Dalla sintesi e generazione del bitstream si ottengono diverse informazio-

ni sulle tempistiche e sulle risorse utilizzate che verranno in questa sede

esaminate.

4.3.1 Tempistiche

Il sommario sui risultati dei tempi, visibile in Figura 4.4 indica l'assenza di

errori, 190130 possibili percorsi del core e 11949 connessioni fra i vari banchi

logici. Indica inoltre che il periodo minimo di clock col quale �e �sicamente

possibile far girare la periferica �e di 17, 788ns corrispondenti a una frequenza

massima di 56,218MHz. Mediante Modelsim in�ne mediante la simulazione

Figura 4.4: Sommario delle tempistiche

del core si �e misurato il tempo di crittazione di un blocco di 128, andando a

cercare dopo quanto tempo si ottenessero i risultati. Il tempo misurato �e di

1,41 microsecondi che rapportati al blocco di dati da 128 bit indicano una

velocit�a di:128bit

1;41microsec= 91; 4 Megabit

s

4.3 Risultati sperimentali 55

4.3.2 Consumo delle risorse

Le risorse utilizzate da questa IP Core sono calcolate in quantit�a di LUT,

Slice, Flip Flop e Latch utilizzate sul totale. Dalla Figura 4.6 si vede che

non sono state utilizzate tutte le risorse disponibili rispetto alla dimensione

Figura 4.5: Sommario delle risorse di kver

totale della scheda ma una buona parte. In e�etti il consumo di risorse non

�e, facendo un confronto con i dati sul consumo di risorse da parte della sola

IP Core Kver, ai limiti della capacit�a del chip ma, nei calcoli bisogna inserire

anche il consumo di risorse degli altri IP Core per svolgere funzioni collaterali

quali, ad esempio, quelle di input-output.

Figura 4.6: Sommario delle risorse di tutto il sistema

4.4 Conclusione e possibili sviluppi futuri 56

4.4 Conclusione e possibili sviluppi futuri

Un lavoro simile �e stato fatto in un elaborato di tesi in cui si �e svolta un'imple-

mentazione AES a 512 bit, i risultati sperimentali segnalati in questo hanno

mostrato una velocit�a di criptazione pi�u alta [14]. Questa di�erenza delle

velocit�a �e dovuto ad una di�erenza essenziale della realizzazione: mentre in

quel lavoro la parte relativa al KeyExpansion �e stata realizzata via software,

in questo lavoro di tesi invece, ci si �e concentrati sull'obiettivo di realizza-

re l'intero procedimento di crittogra�a via hardware. I risultati sono stati:

un'allungamento del path e conseguentemente un peggioramento delle pre-

stazioni.

L'utilizzo di risorse da parte del IP Core Kver �e, come si realizza dai paragra-

� precedenti, quasi totale. Questa situazione rende di�cile eventuali lavori

futuri di espansione del progetto come la realizzazione della logica per la de-

crittazione o per la crittazione di blocchi di dati pi�u grandi. Per fronteggiare

questo problema si possono attuare diversi miglioramenti al codice VHDL e

alla struttura generica del IP Core.

Per prima cosa si pu�o riscrivere il codice VHDL dell'algoritmo utilizzando

un descrizione pi�u a basso livello cos�� da ottimizzare la sintesi del medesimo.

Un'altro risparmio delle risorse lo si pu�o ottenere sfruttando il processo-

re PPC gi�a presente sulla FPGA risparmiando cos�� lo spazio occupato dal

softcore Microblaze. In�ne �e possibile diminuire ancora le risorse utilizzate

spostando eventualmente la funzione di espansione della chiave, spiegata nel

paragrafo 3.1.2, dall'originale descrizione VHDL e quindi hardware a una im-

plementazione software all'interno del System0.c come fatto nel lavoro citato

precendentemente [14]. La perdita di performance �e sicura, ma contenuta.

Questa soluzione sarebbe ottima per sessioni di crittogra�a di grandi quan-

tit�a di dati con la stessa chiave, dato che la procedura di espansione della

chiave, che fa da collo di bottiglia del sistema, verrebbe eseguita una sola vol-

ta all'inizio della sessione di crittogra�a. Oppure in maniera diametralmente

opposta si possono aumentare le prestazioni del dispositivo aumentando il

parallelismo dell'architettura, a scapito, questo, dello spazio lasciato libero

4.4 Conclusione e possibili sviluppi futuri 57

per altre applicazioni. Un tale parallelismo pu�o essere inserito nell'architet-

tura all'interno della procedura di espasione della chiave: dopo ogni ciclo di

espansione si potrebbero rendere disponibili le quattro chiavi che non sareb-

bero poi pi�u modi�cate dalla procedura cos�� da portare avanti il processo

di crittazione. Tale modi�ca velocizzerebbe, in particolare, quelle sessioni di

crittogra�a nelle quali si cambia spesso chiave di crittazione.

Legenda

AES: Advanced Encryption Standard

ASIC: Application Speci�c Integrated Circuit

BRAM: Block RAM

CBC: Cipher Block Chaining

CFB: Ciphertext Feedback

CLB: Con�gurable Logic Block

DES: Data Encryption Standard

DLMB: Data Local Memory Bus

ECB: Electronic Codebook

EDK: Embedded Development Kit

EEPROM: Electrically Erasable Programmable Read Only Memory

EPROM: Erasable Programmable Read Only Memory

FPGA: Field Programmable Gate Arrays (array logico (ri)programmabile

a campi)

GF: Galois Field

GPIO: General Purpose Input/Output

Legenda 59

HDL: Hardware Description Language

I/O: Input/Output

IDEA: International Data Encryption Algorithm

IP: Intellectual Properties

IPIC: Intellectual Properties InterConnect

IPIF: Intellectual Properties InterFace

LB: Logic Block

LMB: Local Memory Bus

LUT: Look-Up Table

MB: MicroBlaze

MDD: Microprocessor Driver Speci�cation �le

MHS: Microprocessor Hardware Speci�cation �le

MPD: Microprocessor Peripheral Description �le

MPGA: Mask Programmable Logic Array

MSS: Microprocessor Software Speci�cation �le

NGD: Native Generic Database

NIST: National Institution of Standards and Technology

OPB: On-chip Peripheral Bus

PAL: Programmable Array Logic

PAO: Peripheral Analyze Order �le

PAR: Place And Route

Legenda 60

PLA: Programmable Logic Array

PLB: Processor Local Bus

PLD: Programmable Logic Device

PPC: Power PC

Pselect: Peripheral select

RAM: Random Access Memory

ROM: Read Only Memory

RSA: Algoritmo di di crittogra�a

SRAM: Static Random Access Memory

SSL: Secure Socket Layer

VHDL: Very high speed integrated circuit Hardware Description Language

Ringraziamenti

Con questo lavoro si concludono tre anni di fatiche, sacri�ci e a volte delusio-

ni, ma soprattutto gioie e soddisfazioni che non ho provato solo io, ma anche

tutte le persone che mi sono state vicino e mi vogliono bene.

Appro�tto di queste poche righe per ringraziarle di cuore.

Un grazie alla Mamma, che non poteva che essere la prima, perch�e per prima

sempre presente, sollecita verso i miei bisogni e paziente con le mie "sclerate"

in casa dei periodi pi�u stressanti. Al Babbo, mai estroverso nell'esprimere i

suoi sentimenti ma sempre pronto a spronarmi nello studio e le cui rare parole

di elogio, sono state musica per le mie orecchie e carica di energia per la mia

mente. A Sarah che, nonostante la giovane et�a, si �e sforzata di comprendere

le mie necessit�a e i miei brutti periodi, sopportandomi. Dulcis in fundo, la

nonnina: paziente e gentile che, con le sue preghiere a Padre Pio, mi soste-

neva sempre prima di una prova di esame.

Voglio ringraziare il prof. Ferrandi che gentilmente mi ha dato la possibi-

lit�a di svolgere questa tesi e che si �e sempre dimostrato disponibile e gentile.

Grazie al Mega Correlatore Santambrogio che nel periodo durante il quale

abbiamo lavorato insieme mi ha insegnato tanto e tanto aiutato.

In�ne voglio ringraziare tutti gli amici del Micro che mi hanno aiutato nelle

varie fasi del lavoro (l'ordine �e un p�o casuale e un p�o secondo l'ordine con

cui gli ho incontrati): Stefano, Diego, Alessandro, Mattia, Massimo, Fabio

ed Edo. Ed in�ne un grazie a tutti gli amici del corso di studi che mi hanno

Legenda 62

allietato le gionate al Politecnico.

Bibliogra�a

[1] Paolo Ferragina e Fabrizio Luccio, "Crittogra�a: principi, algoritmi

e applicazioni", .

[2] Franco Fummi, Maria Giovanna Sami, Cristina Silvano, "Progetta-

zione Digitale", .

[3] Alessandro Mele, Francesca Malcotti, "De�nizione e utilizzo dei

DRIVER in EDK", .

[4] Massimo Ratti, Fabio Rizzato,Utilizzo di Modelsim per la

simulazione comportamentale di un componente,.

[5] Xilinx,User Core Templates Reference Guide,Gennaio 2004.

[6] Xilinx,Processor IP Reference Guide,Gennaio 2004.

[7] Xilinx,User Core Template Reference Guide,Gennaio 2004.

[8] Xilinx,Microblaze Processor Reference Guide,Dicembre 2003.

[9] Peter J. Ashenden, "The VHDL Cookbook �rst edition", Luglio

1990.

[10] National Institute of Standards and Technology (NIST), "Federal In-

formation Processing Standards Publication 197 - Announcing

the Advanced Encryption Standard (AES)", 26 Novembre 2001.

[11] J. Daemen, V. Rijmen, " AES Proposal: Rijndael", 1999

BIBLIOGRAFIA 64

[12] Malcotti Francesca, Mele Alessandro, "Gestione degli interrupt con

EDK", Politecnico di Milano - Laboratori di Micro Architetture, 2004.

[13] Davide Murrai, Diego Nichetti, Stefano Orlandi, "Wizard per im-

portare periferiche custom in un progetto EDK", Politecnico di

Milano - Laboratori di Micro Architetture, 2004.

[14] Roberto Palazzo, Davide Pavoni, "Realizzazione di un componente

per un sistema dedicato: codi�ca AES a 512 bit", Politecnico di

Milano, 2004

Documents

Tesi di Laurea - DRESD · POLITECNICO DI MILANO aacoltFdi Ingegneria Dipartimento di Elettronica e Informazione REALIZZAZIONE DI UN'ARCHITETTURA DI CIFRATURA SIMMETRICA AES SU FPGA