UNIVERSITÀ POLITECNICA DELLE MARCHE FACOLTÀ DI INGEGNERIA

Transcript

1 UNIVERSITÀ POLITECNICA DELLE MARCHE FACOLTÀ DI INGEGNERIA Corso di Laurea Triennale in Ingegneria Elettronica GESTIONE DELLA SICUREZZA DI UN PORTALE WEB MEDIANTE CONTROLLO CONDIZIONATO DEGLI ACCESSI E CRIPTAZIONE DEI DOCUMENTI DEPOSITATI Relatore: Prof. Aldo Franco Dragoni Rapporto Finale di: Alessandro Rossi Anno Accademico 2006/2007

2 INDICE INTRODUZIONE 1 CAPITOLO La sicurezza La sicurezza su Internet Aspetti giuridici sulla sicurezza Un quadro comunitario per le firme elettroniche Il nuovo testo unico sulla privacy La crittografia La crittografia simmetrica Cifratura a blocchi Cifratura a flusso I principali algoritmi a chiave simmetrica La crittografia asimmetrica Algoritmi a chiave di cifratura pubblica Algoritmi a chiave di decifratura pubblica Algoritmi ibridi I principali algoritmi a chiave asimmetrica Stima sulla sicurezza degli algoritmi crittografici La funzione di hash I principali algoritmi per la funzione di Hash Stima sulla sicurezza della funzione di Hash La firma digitale La public key infrastructure Il certificato a chiave pubblica Richiesta, ottenimento, durata e revoca di un certificato Autorità di certificazione Standard X Standard PKCS 30 I

3 1.5 La steganografia Steganografia iniettiva e generativa Modelli steganografici Steganografia sostitutiva Steganografia selettiva Steganografia costruttiva La steganografia applicata ai files digitali Steganografia dei files Bitmap Steganografia dei files Wave Steganografia dei files compressi Stima sulla sicurezza degli algoritmi steganografici I protocolli web Il protocollo http Il protocollo https 54 CAPITOLO La Phi.d αlpha s.r.l Descrizione del progetto 63 CAPITOLO Analisi delle specifiche Modellazione dei pericoli Anali delle contromisure Uso insicuro della crittografia Controlli di accesso insufficienti Iniezioni di comandi Gestione insicura delle sessioni Gestione inadeguata degli errori Implementazione del software lato client Software per la gestione della crittografia Software per la gestione della steganografia Implementazione dell applicazione web Login e logout degli utenti Upload e download dei files 83 II

4 CONCLUSIONI E SVILUPPI FUTURI 87 APPENDICE 89 Codice VB.NET del software di crittografia 90 Codice VB.NET del software di steganografia 96 Codice ASP del software web 104 BIBLIOGRAFIA 120 III

5 INTRODUZIONE Nel settembre del 1969, negli USA, l ARPA (Advanced Research Projects Agency), sotto il controllo del Dipartimento della Difesa degli Stati Uniti, diede vita ad una rete di computer: ARPANET. Negli anni successivi il progetto subì un enorme ampliamento fino alla definizione del protocollo TCP/IP che segnò l inizio effettivo di quello che oggi viene definita Internet. Quando il protocollo TCP/IP fu progettato, la rete collegava tra loro università e laboratori di ricerca ed era uno strumento per la condivisione delle risorse e delle informazioni da parte della comunità scientifica, in virtù di ciò gli utenti della rete erano una comunità ristretta e fidata, e per questo non si fece particolare attenzione alle problematiche relative alla sicurezza. Oggi Internet è diventato uno strumento di comunicazione globale, quindi la situazione è molto diversa e il tema della sicurezza in rete assume una grande importanza, basti pensare che anche la giurisprudenza italiana con il D.L. 30 giugno 2003, n. 196 fissa delle regole concrete sul trattamento dei dati ai fini della sicurezza e della privacy e sancisce regole da applicarsi alla trasmissione dei documenti informatici e alla firma digitale con il D.P.R. 10 novembre 1997, n In questa tesi verrà progettato un portale web in cui viene garantito un elevato grado di sicurezza mediante il controllo condizionato degli accessi e la criptazione dei documenti depositati. Per lo scambio delle chiavi segrete, necessarie per l utilizzo di tecniche di crittografia, verrà introdotto un approccio all uso della steganografia. Per la realizzazione del progetto si utilizzeranno diversi linguaggi di programmazione: Visual Basic Script; Java Script; ASP; Visual Basic.NET. Le pagine web verranno create tramite il linguaggio di mark-up HTML

6 CAPITOLO 1 In questo capitolo verrà descritto che cosa si intende per sicurezza su Internet, dopodichè verranno forniti dei cenni sulla crittografia, sulle public key infrastructure, sulla steganografia e sui protocolli per il web

7 1.1 La sicurezza Che cosa si intende con il termine sicurezza? Se consultiamo il dizionario Treccani ( vediamo che per sicurezza si intende: il fatto di essere sicuro, come condizione che rende e fa sentire d essere esente da pericoli, o che dà la possibilità di prevenire, eliminare o rendere meno gravi danni, rischi, difficoltà, evenienze spiacevoli, e sim La sicurezza su Internet Per quanto riguarda Internet, o una qual si voglia rete di computer, tale termine deve essere usato per commisurare il grado di immunità ai rischi che possono presentarsi, in quanto una rete completamente sicura non esiste e forse non esisterà mai. Per garantire la sicurezza di una rete, ci si trova a dovere fronteggiare aspetti e problematiche diverse, per risolvere le quali si usano approcci differenti. I principali servizi per la tutela della sicurezza sono i seguenti: autenticazione d identità: garantire l'identità degli interlocutori; autenticità dei dati: garantire i dati identificativi del mittente; riservatezza: impedire letture non autorizzate, garantendo la segretezza del contenuto della comunicazione; integrità: garantire che dati e informazioni non subiscano modifiche non autorizzate, in particolare durante il transito dal mittente al destinatario; non ripudio: impedire che le parti neghino di aver inviato (o ricevuto) dati che hanno effettivamente inviato (o ricevuto); autorizzazione: permettere l'accesso a determinate risorse o servizi solo a chi è autorizzato a farlo; disponibilità: garantire l'operatività di un servizio e la sua fruibilità da parte degli utenti autorizzati, evitando che azioni di disturbo possano compromettere la disponibilità del sistema. Gli attacchi alla sicurezza di un sistema possono essere dunque molteplici, colpendo l'uno o l'altro di questi aspetti. Un intruso può ad esempio intercettare dei dati (colpendo quindi la riservatezza), modificare le informazioni in transito (integrità), sostituirsi ad uno degli interlocutori (autenticazione), rendere indisponibile un servizio. Un attacco classico è il cosiddetto man-in-the-middle (MITM), in cui un intruso si inserisce nella comunicazione impersonando ciascun interlocutore agli occhi dell'altro, e può così leggere tutti i dati scambiati, modificarli, inserirne altri

8 1.2 Aspetti giuridici sulla sicurezza Dimostrare l autenticità di un documento, sia esso giuridico o privato, dipende dal fatto di poter palesare la sua inalterabilità o delle eventuali tracce che hanno portato ad una modifica. Per quanto riguarda i documenti cartacei questo avviene tramite l apposizione di una firma autografa. Con l avvento e la successiva espansione dei sistemi informatici, la giurisprudenza si è trovata di fronte al problema di dover produrre una normativa capace di poter efficacemente convalidare l autenticità di un documento. Un altro punto focale che i legislatori hanno dovuto risolvere è stato quello di sancire delle regole affinché sia tutelato il tema della riservatezza Un quadro comunitario per le firme elettroniche In questo paragrafo verrà descritto l iter legislativo che ha portato all equiparazione del documento informatico firmato digitalmente alla scrittura privata. In materia di formazione, archiviazione e trasmissione di atti, documenti e contratti in forma elettronica, fino al 1997, esisteva un quadro normativo alquanto frammentario e generico. Il 15 marzo 1997 con la legge n. 59, detta legge Bassanini, il legislatore italiano ha realizzato una vera e propria rivoluzione di diritto pubblico e di diritto privato introducendo nell'ordinamento la nozione di documento informatico e telematico, provvedendo a dettare una specifica disciplina in materia. All'art. 15, secondo comma, dispone gli atti, i dati e i documenti formati dalla pubblica amministrazione e dai privati con strumenti informatici e telematici, i contratti stipulati nelle medesime forme, nonché la loro archiviazione e trasmissione con strumenti informatici, sono validi e rilevanti a tutti gli effetti di legge, e rinvia a successivi regolamenti la precisazione sulle modalità di applicazione della legge, sia per la Pubblica Amministrazione sia per i privati. Uno di questi regolamenti è il D.P.R. n. 513 del 10 novembre 1997, finalizzato alla creazione di un sistema di firma sicura, che disciplina i criteri e le modalità per la formazione, l'archiviazione e la trasmissione di documenti con strumenti informatici e telematici. La caratteristica principale del decreto è costituita dalla definizione di documento informatico e dalla precisa determinazione della sua validità. Il D.P.R. n. 513 stabilisce indirettamente l equivalenza tra documento informatico e documento cartaceo, infatti l equiparazione degli effetti probatori del primo rispetto al secondo è subordinata alla conformità del documento (informatico), alle disposizioni del regolamento e delle regole tecniche che sono state emanate con D.P.C.M. 8 febbraio

9 Le norme di questo decreto sono state successivamente incorporate nel D.P.R. n. 445 del 28 dicembre 2000 detto testo unico sulla documentazione amministrativa. L'ultima tappa è rappresentata dal D.Lgs. n. 10 del 23 gennaio 2002, attuativo della direttiva n. 1999/93/CE, relativa a un quadro comunitario per le firme elettroniche, il quale ha completamente stravolto il sistema esistente affiancando la firma elettronica a quella digitale Il nuovo testo unico sulla privacy Come in precedenza accennato, anche la giurisprudenza italiana, ha disciplinato, il tema della sicurezza nel trattamento dei dati. In questo paragrafo verrà decritto il D.L. 30 giugno 2003, n. 196, entrato in vigore il 1 Gennaio 2004 sostituendo la legge 675/1996 e successivi decreti legislativi, detto anche testo unico sulla privacy. Tale legge si rivolge a tutti coloro che trattano dati personali di clienti, fornitori, dipendenti, utenti, pazienti, colleghi, soci o associati. Quindi vengono coinvolte aziende, liberi professionisti, amministrazioni pubbliche, associazioni e cooperative. La legge sancisce una serie di regole e procedure gestionali rivolte a garantire la sicurezza dei dati personali all interno delle aziende, attraverso l adozione di requisiti minimi di sicurezza che dovranno essere utilizzati nell'espletamento delle suddette attività. Con scadenza ultima al 31 Dicembre 2004 tutte le aziende dovranno adeguarsi alle disposizioni imposte dal D.L. 30 giugno 2003, n. 196 e redigere il Documento Programmatico sulla Sicurezza in cui dovranno essere riassunte le misure a cui saranno vincolati ad adottare per garantire la sicurezza dei dati. Per mancato adempimento di tale obbligo sono previste sanzioni pecuniarie e penali, con multe che possono arrivare fino Euro e sanzioni penali che possono raggiungere la pena di tre anni di reclusione. Per adeguarsi alle disposizioni del nuovo codice sulla privacy, le attività interessate dovranno, adottare una modulistica, individuare i soggetti incaricati del trattamento dei dati e verificare l adeguamento dei propri sistemi informatici secondo quanto previsto dall'allegato B (Disciplinare tecnico in materia di misure minime di sicurezza). Paul Baran in un rapporto per la Rand Corporation sancisce l importanza dell uso delle pratiche di sicurezza, anche se non imposte da un sistema giuridico, dicendo: "...non aspettiamoci che il contributo dei giuristi possa sostituire una buona progettazione tecnica, anche se non si volesse tenere conto del ritardo sociale dei procedimenti legislativi e giudiziari, gli specifici problemi del mondo dei computer si collocano in una dimensione che ad essi, ai giuristi, sfugge completamente..."

10 1.3 La crittografia L etimologia del termine crittografia è data dall associazione di due parole di origine greca: criptos che significa nascondere, e grafèin che significa scrivere, da cui scrivere di nascosto. L arte di scrivere messaggi segreti che possano essere letti e compresi solo dal destinatario risale alla più remota antichità, già la Bibbia parla di un codice segreto per scrivere il nome di Babele, il codice Atbash, esso consisteva nell inversione delle lettere alfabetiche, ovvero la a diventava z, la b diventava y e così via, fino a giungere ai tempi più recenti in cui durante la seconda guerra mondiale i tedeschi avevano ideato Enigma un algoritmo simmetrico per trasmettere in modalità protetta i propri messaggi, in cui ogni mese le chiavi venivano consegnate ai cifratori scritte in un foglio con inchiostro solubile che doveva essere custodito gelosamente dagli stessi. Figura 1a. Cifrario Atbash Figura 1b. Soldati tedeschi che lavorano su Enigma Per secoli quest arte è stata appannaggio quasi esclusivo dei militari e dei diplomatici ed i metodi crittografici erano specifici per l invio di messaggi materiali che venivano affidati ai corrieri. In contrapposizione e non solo, nasce contemporaneamente alla crittografia una nuova disciplina che prende il nome di crittoanalisi che studia come recuperare il contenuto di un messaggio cifrato senza disporre delle informazioni necessarie alla decifratura. La crittografia e la crittoanalisi si basano su una branca della matematica che prende il nome di crittologia. L evoluzione delle tecniche crittografiche ha avuto una svolta quando si è deciso di rendere pubblici gli algoritmi di cifratura e decifratura dei messaggi; infatti la - 6 -

11 pubblicazione degli algoritmi ha reso possibile lo studio da parte dei crittoanalisti, consentendo di scoprirne eventuali debolezze e quindi di selezionare gli algoritmi più sicuri, e ha reso possibile la fruizione degli stessi a chiunque, anche a coloro inesperti di scienza crittologica. La crittografia moderna è in grado di garantire i seguenti servizi di sicurezza: autenticazione d identità: verifica dell identità di una o entrambe le parti coinvolte in una comunicazione; integrità dei dati: il documento trasmesso deve contenere tutte le informazioni in esso presenti sin dalla redazione, con la possibilità di verificare le eventuali alterazioni, intenzionali o meno, che i dati possono aver subito attraversando un canale insicuro; autenticità dei dati: verifica dell effettiva identità del mittente; non ripudio: impossibilità, da parte sia del mittente che del destinatario, di negare l avvenuto scambio di dati. La comunicazione fra due entità, mittente e destinatario, può avvenire in due modi: comunicazione in modo chiaro: Figura 2. Schema di principio di una comunicazione in chiaro fra due entità Il messaggio viene inviato dal mittente verso il destinatario attraverso il canale in modo trasparente (privo di cifratura). Lungo il canale il messaggio è visibile a tutti e questo va a compromettere la sicurezza della trasmissione comunicazione in modo cifrato: Figura 3. Schema di principio di una comunicazione cifrata fra due entità - 7 -

12 Il messaggio in chiaro viene innanzitutto cifrato per mezzo di una chiave dal mittente, il quale lo trasmette attraverso il canale al destinatario. Una volta giunto a quest ultimo, il destinatario tramite l apposita chiave decifrerà il messaggio, ottenendo il messaggio in chiaro originale. Lungo il canale il messaggio è visibile a tutti ma questo non compromette la sicurezza della trasmissione in quanto, essendo cifrato, solo chi è in possesso dell apposita chiave è in grado di comprenderne il significato La crittografia simmetrica La crittografia simmetrica utilizza algoritmi che si avvalgono di un unica chiave sia per le operazioni di cifratura sia per quelle di decifratura, per questo viene detta anche a chiave segreta. Lo schema di principio di una comunicazione con crittografia a chiave simmetrica è il seguente: Figura 4. Schema di principio di una comunicazione cifrata con crittografia a chiave simmetrica Il mittente prima dell invio del messaggio genera una chiave con cui cifra il messaggio e lo manda al destinatario tramite un canale insicuro; quindi chiunque può leggere il messaggio ma non avendo la chiave di decodifica non può interpretarlo. La chiave che ha generato il mittente e che serve al destinatario per decifrare il messaggio viene mandata al destinatario attraverso un canale sicuro in modo tale che nessuno possa intercettarla e leggerla. La sicurezza di questa tecnica crittografica è garantita fintantoché la chiave rimane a conoscenza dei due soli interlocutori

13 Il difetto principale della crittografia simmetrica sta nel fatto che anche se si adotta un canale sicuro, la trasmissione della chiave può essere comunque intercettata. Nel caso in cui un terzo interlocutore, non desiderato, venisse in possesso della chiave, andrebbe a provocare il decadimento di alcuni servizi di sicurezza che invece la trasmissione criptata dovrebbe garantire, quindi verrebbero meno i requisiti di segretezza, di integrità del messaggio e di autenticazione del mittente, infatti la compromissione del terzo interlocutore in possesso della chiave, potrebbe consistere nell intercettazione del messaggio cifrato, nella modifica e cifratura di uno nuovo, senza che il destinatario si accorga di nulla. Un altro svantaggio della crittografia simmetrica riguarda il fatto che ogni utente deve disporre di una chiave diversa per ogni interlocutore con cui voglia comunicare, sapendo che il numero di chiavi cresce con legge quadratica, nella nostra situazione, ponendo n come numero di presunti interlocutori, un utente si n( n 1) troverebbe a gestire chiavi segrete, quindi se il numero di interlocutori è 2 estremamente elevato, l utente si trova a gestire un infinità di chiavi. Gli algoritmi di crittografia simmetrica si possono suddividere in due tipologie in base alla tecnica utilizzata per la cifratura: algoritmi a blocchi: l operazione di cifratura o decifratura viene effettuata su gruppi di bit, byte o word di lunghezza finita organizzati in blocco; algoritmi a flusso: l operazione di cifratura o decifratura viene effettuata sui singoli bit, byte o word Cifratura a blocchi Negli algoritmi a blocchi il messaggio da cifrare, o decifrare, viene suddiviso in blocchi di lunghezza prefissata e l algoritmo viene applicato ad ognuno di questi blocchi singolarmente. Visto ciò risulta ovvio che il messaggio debba avere una lunghezza esattamente multipla della dimensione del blocco, altrimenti si andrebbe a verificare un errore; per ovviare a questa anomalia si provvede a riempire l ultimo blocco con opportuni caratteri di allineamento. Questa operazione è nota con il termine di pad. Esistono diversi metodi per eseguire il pad di un blocco, essi si diversificano in base alla tipologia di dato che contengono. Di seguito si elencheranno le metodologie di pad più comuni, ma in realtà ne esistono innumerevoli altre. Il metodo più semplice è quello di aggiungere zeri fino al raggiungimento della lunghezza prefissata del blocco; se i dati sono binari si completa il blocco con bit che sono l opposto degli ultimi bit costituenti il messaggio; nel caso di caratteri ASCII si usano byte di riempimento casuali specificando nell ultimo byte il carattere ASCII corrispondente al numero di byte aggiunti

14 Cifratura a flusso Negli algoritmi a flusso, il messaggio in chiaro si mostra come uno stream di dati e l operazione di cifratura, o decifratura, viene effettuata su ogni singolo bit, byte o word, in ingresso. Questa tipologia di algoritmi fa uso di un generatore di bit che produce una sequenza di bit pseudo-casuale in relazione alla chiave fornita dagli utenti. Essenziale risulta il generatore pseudo-random, in quanto in fase di cifratura i dati in ingresso vengono messi in XOR con i dati provenienti dal generatore, questo per fare in modo che messaggi identici cifrati con la stessa chiave non diano mai origine a messaggi cifrati uguali. Gli algoritmi a flusso possono essere suddivisi in due categorie: algoritmi autosincronizzanti: in questo tipo di algoritmi il generatore di numeri pseudo-random prende in ingresso, ad ogni step, anche un certo numero di bit cifrati precedentemente, quindi, qualunque sia la chiave segreta, uno stesso bit, o byte, potrà essere cifrato ogni volta in modo diverso a seconda delle precedenti informazioni elaborate dal flusso in ingresso. algoritmi sincroni: in questo tipo di algoritmi, il generatore pseudorandom è completamente indipendente dal flusso di dati in ingresso. Gli algoritmi sincroni risultano essere molto vantaggiosi su canali di trasmissioni rumorosi, in quanto riducono la propagazione degli errori, si pensi per esempio alla trasmissione di un messaggio in un canale rumoroso. Quando il ricevitore riceverà un bit errato, dovuto alla rumorosità del canale, l errore non si ripercuoterà su altri bit, in quanto non c è la dipendenza dagli stati precedenti, come avviene negli algoritmi autosincronizzanti I principali algoritmi a chiave simmetrica I principali algoritmi a chiave simmetrica sono: DES (Data Encryption Standard): fu sviluppato dalla IBM come evoluzione dell algoritmo Lucifer, risalente agli anni 70. Fu il primo algoritmo di cifratura a diventare uno standard nazionale negli Stati Uniti nel Il DES rientra nella classe dei codici a blocchi, ogni blocco ha la dimensione di 64 bit e la chiave di cifratura è di 56 bit. Il DES fu violato per mezzo di un attacco di forza bruta nel 1998, quindi risulta essere poco robusto per l utilizzo odierno. TDES (Triple DES): è una evoluzione del DES, è così denominato in quanto utilizza tre chiavi indipendenti in tre diversi passaggi: una cifratura con la prima chiave, una decifratura con la seconda ed infine un altra cifratura con la terza chiave. Il TDES è sicuramente un algoritmo più complesso e più costoso rispetto al DES, specialmente in termini di burst time, ma è anche molto più sicuro, infatti non è stato ancora violato

15 IDEA (International Data Encryption Algorithm): fu proposto da due scienziati svizzeri dello Swiss Federal Institute of Technology di Zurigo in collaborazione con la Ascom Communications inc.: il Dr. Xuejja. Lai e il Prof. James. Massey. IDEA rientra nella classe dei codici a blocchi, ogni blocco ha la dimensione di 64 bit e sfrutta chiavi di lunghezza di 128 bit. IDEA è generalmente considerato sicuro, poiché sfrutta chiavi di 128 bit. AES (Advanced Encryption Standard): fu sviluppato dai crittografi belgi Joan Daemen e Vincent Rijmen, è noto anche come algoritmo di Rijndael, nome derivato dal nome degli inventori. È stato adottato dalla National Institute of Standards and Technology (NIST) e dalla US Federal Information Processing Standard (FIPS) nel novembre L AES rientra nella classe dei codici a blocchi, ogni blocco ha la dimensione di 128 bit e possono essere impiegate chiavi di 128, 192 o anche 256 bit. L AES risulta essere un algoritmo molto robusto poiché permette l impiego di chiavi di lunghezza fino a 256 bit. L AES è di facile implementazione sia hardware che software e le sue richieste di risorse sono limitate, rendendolo utilizzabile su qualsiasi strumento capace di eseguire operazioni crittografiche La crittografia asimmetrica Nel 1976 Whitfield Diffie e Martin Hellmann, ricercatori all università di Stanford USA, ipotizzarono un nuovo tipo di crittografia radicalmente nuovo. La loro idea era quella di utilizzare un cifrario asimmetrico, cioè un sistema in cui si sarebbero dovute usare due chiavi distinte, in cui una era utilizzata per la cifratura ed una per la decifratura ma la conoscenza di una chiave non permetteva la generazione dell altra, nonostante fossero legate da una relazione matematica. Una delle due chiavi deve rimanere nota al solo possessore e per questo viene detta chiave privata. L altra chiave invece può essere resa liberamente nota ed è utilizzabile da qualsiasi utente necessiti il suo impiego in una comunicazione, per questo viene detta chiave pubblica. Le due chiavi sono legate matematicamente tra loro, ma costruite in modo che sia impossibile risalire alla chiave privata partendo da quella pubblica. La crittografia asimmetrica incrementa notevolmente il grado di sicurezza rispetto a quello che si otterrebbe dall impiego della crittografia simmetrica, in quanto viene eliminata l esigenza di scambiare la chiave fra i due utenti. Nella crittografia asimmetrica un messaggio cifrato con una chiave appartenente alla coppia chiave privata, chiave pubblica, può essere decifrato solo con una chiave associata alla coppia. Per cifrare o decifrare un messaggio si può utilizzare indipendentemente una delle due chiavi della coppia, quindi l utilizzo delle chiavi risulta essere completamente arbitrario ai fini della corretta applicazione dell algoritmo. In base all utilizzo di una o l altra chiave in fase di cifratura o decifratura si possono dividere gli algoritmi in due categorie:

16 algoritmi a chiave di cifratura pubblica: impiegano la chiave pubblica in cifratura e quella privata in decifratura; algoritmi a chiave di decifratura pubblica: impiegano la chiave privata in cifratura e quella pubblica in decifratura. Una differenza importante con gli algoritmi a chiave simmetrica sta nel fatto che gli algoritmi a chiave pubblica possono essere implementati solo come algoritmi a blocchi, in quanto non sarebbe possibile cifrare i dati in ingresso bit a bit Algoritmi a chiave di cifratura pubblica Lo schema di principio di una comunicazione con crittografia a chiave di cifratura pubblica è il seguente: Figura 5. Schema di funzionamento di un algoritmo a chiave di cifratura pubblica Prima di analizzare l effettiva trasmissione del messaggio bisogna analizzare la tipologia di chiavi di cui sono in possesso il mittente ed il destinatario. Il destinatario è in possesso di una coppia valida di chiavi: una chiave privata: K privd ed una chiave pubblica: K pubd. Il destinatario invierà a tutti i suoi interlocutori la propria chiave pubblica in modo che essi possano effettuare la cifratura di un messaggio. In questo modo anche il mittente avrà la chiave pubblica del destinatario. Il mittente cifra il messaggio utilizzando la chiave pubblica del destinatario, invia il messaggio attraverso il canale insicuro al destinatario il quale lo riceve e tramite l utilizzo della propria chiave privata riesce a decifrarlo

17 Il messaggio che passa attraverso il canale insicuro può essere letto da chiunque ma non avendo la chiave appartenente alla coppia: K privd, K pubd non potrà interpretarlo, quindi è garantito il servizio di segretezza. Il difetto fondamentale di questo tipo di algoritmo di cifratura asimmetrica consiste nel fatto che il destinatario non può essere sicuro dell effettiva identità del mittente, in quanto chiunque può procurarsi la sua chiave pubblica e spedirgli dei messaggi cifrati Algoritmi a chiave di decifratura pubblica Lo schema di principio di una comunicazione con crittografia a chiave di decifratura pubblica è il seguente: Figura 6. Schema di funzionamento di un algoritmo a chiave di decifratura pubblica Prima di analizzare l effettiva trasmissione del messaggio bisogna analizzare la tipologia di chiavi di cui sono in possesso il mittente ed il destinatario. Il mittente è in possesso di una coppia valida di chiavi: una chiave privata: ed una chiave pubblica: K pubm K privm. Il mittente invierà a tutti i suoi interlocutori la propria chiave pubblica in modo che essi possano effettuare la cifratura di un messaggio. In questo modo anche il destinatario avrà la chiave pubblica del mittente. Il mittente cifra il messaggio utilizzando la propria chiave privata, invia il messaggio attraverso il canale insicuro al destinatario il quale lo riceve e tramite l utilizzo della chiave pubblica del mittente riesce a decifrarlo

18 Il messaggio che passa attraverso il canale insicuro può essere letto ed interpretato da chiunque poiché chiunque può avere la chiave pubblica del mittente, quindi in questo caso il servizio di segretezza non è garantito. Il vantaggio fondamentale di questo tipo di algoritmo di cifratura asimmetrica si rileva nel fatto che il destinatario se riesce a decifrare il messaggio con la chiave pubblica del mittente è sicuro che il messaggio è stato cifrato da quest ultimo, quindi è garantito il servizio di autenticazione d identità. Gli algoritmi a chiave di decifratura pubblica trovano largo impiego nei sistemi che fanno uso della firma digitale Algoritmi ibridi Si è visto che gli algoritmi a chiave di cifratura pubblica garantiscono il servizio di segretezza ma non quello di autenticazione di identità mentre gli algoritmi a chiave di decifratura pubblica garantiscono gli stessi servizi in modo opposto. Sarebbe molto proficuo utilizzare contemporaneamente una combinazione dei due algoritmi per ottenere entrambi i servizi che costituiscono delle caratteristiche estremamente importanti ai fini della sicurezza. Lo schema di principio dell utilizzo combinato delle due tecniche è il seguente: Figura 7. Schema di utilizzo della cifratura asimmetrica per l invio di un messaggio autenticato e segreto Appurato il fatto che il mittente sia in possesso della sua chiave privata: K privm, della sua chiave pubblica: K pubm e della chiave pubblica del destinatario: K pubd e che il destinatario è in possesso della sua chiave privata: K privd, della sua chiave

19 pubblica: K pubd e della chiave pubblica del mittente: K pubm, è possibile analizzare l effettiva trasmissione del messaggio. Il mittente cifra il messaggio con la propria chiave privata ottenendo un messaggio cifrato intermedio, dopodichè cifrerà il medesimo con la chiave pubblica del destinatario, ottenendo un messaggio cifrato finale diverso da quello intermedio. Ora il mittente invia tramite il canale insicuro il messaggio cifrato che giungerà al mittente. Il mittente per ottenere il messaggio in chiaro dovrà decifrarlo prima con la sua chiave privata e poi con quella pubblica del mittente. In realtà, in cifratura, l ordine di utilizzo delle due chiavi è arbitrario, ma deve essere noto, in quanto chi riceve il messaggio dovrà eseguire la decifratura impiegando le chiavi in ordine inverso. Il servizio di autenticazione del messaggio è garantito dall utilizzo della chiave privata del mittente mentre il servizio di segretezza è garantito dall impiego della chiave privata del destinatario. Un vantaggio che si ha rispetto alla crittografia simmetrica sta nel numero di chiavi che gli utenti devono gestire. Nella crittografia asimmetrica ogni utente dispone di una propria coppia di chiavi ed utilizza sempre questa per comunicare con qualsiasi altro utente. In questo modo si ha un incremento lineare del numero di chiavi in funzione del numero di utenti. Il modello presentato risulta essere molto complicato da applicare in casi reali, quindi si opta per l utilizzo di tecniche miste che uniscono la semplicità della crittografia simmetrica con la sicurezza di quella asimmetrica. Un esempio eccellente riguarda la tecnica impiegata nel protocollo SSL in cui, nella comunicazione tra due entità, viene creata al volo una chiave segreta, detta chiave di sessione, per cifrare il messaggio. La chiave a sua volta viene cifrata con la chiave pubblica del destinatario ed allegata al messaggio stesso I principali algoritmi a chiave asimmetrica I principali algoritmi a chiave asimmetrica sono: RSA (Rivest Shamir Adelman): fu sviluppato da Ron Rivest, Adi Shamir e Len Adelman, nel 1977 e poi brevettato nel 1983 negli Stati Uniti dal MIT. Si basa sul problema matematico della fattorizzazione di un numero, che consiste nel trovare quei numeri primi che, moltiplicati tra loro, forniscono il numero dato. Questo è un problema tanto più complesso quanto più è grande il numero iniziale. Basti pensare che una possibile soluzione al problema sarebbe nel verificare l ipotesi di Riemann che, a tutt oggi, è uno dei sette problemi del millennio per cui l istituto matematico Clay offre un milione di dollari a chi riesca a risolverlo. L'RSA è solitamente combinato insieme ad un algoritmo a chiave privata. Combinandolo ad esempio con il DES l'rsa fornisce dimensioni di chiavi sino a 2048 bit. L'RSA è considerato sicuro se sono usate chiavi

20 abbastanza lunghe in quanto la sua sicurezza si basa sulla difficoltà di fattorizzare numeri interi molto grandi. DSA (Digital Signature Algorithm): è stato proposto nel 1991 dal NIST per l utilizzo nell ambito dello standard DSS (Digital Signature Standard), è stato progettato appositamente per la realizzazione di firme digitali. Il procedimento di cifratura infatti prevede anche l utilizzo di una funzione di Hash (nello specifico la funzione SHA) ed apposite operazioni di verifica della firma. Esso si basa sulla difficoltà di risoluzione del problema del logaritmo discreto. Il logaritmo discreto è definito come il logaritmo, in una certa base n, su un gruppo algebrico (a differenza del logaritmo tradizionale che è definito sull'insieme dei numeri reali). Ad esempio, si consideri il gruppo moltiplicativo degli interi modulo p : * x G = Z p con p numero primo. Si consideri poi l'equazione: a = b mod p dove l operatore mod è il resto della divisione b p. Il problema del logaritmo discreto consiste nel trovare il valore di x tale che l'equazione è soddisfatta. Non sono noti ad oggi algoritmi efficienti per il calcolo dei logaritmi discreti. Si tratta in pratica di un problema NP (non-polinomiale) la cui soluzione richiede un tempo di calcolo esponenziale rispetto alle dimensione del gruppo algebrico G. È proprio l'appartenenza alla classe dei problemi NP che pone il problema del logaritmo discreto alla base nella realizzazione di sistemi crittografici a chiave pubblica. In linea teorica sarebbe possibile ricavare la chiave privata calcolando il logaritmo discreto di quella pubblica. Nella realtà però questa operazione è impraticabile a causa della grandezza dei numeri in gioco. Tale algoritmo però non viene molto impiegato in quanto esistono algoritmi ritenuti molto più sicuri Stima sulla sicurezza degli algoritmi crittografici Agli albori della crittografia, un algoritmo veniva valutato sicuro seguendo il principio di security by obscurity, secondo il quale esso risultava sicuro fintantoché rimaneva segreto a chi non era autorizzato ad accedervi, in quanto la mancata conoscenza non permetteva che questo potesse essere violato. Questa metodologia era radicata profondamente in quanto gli algoritmi erano poco elaborati e quindi era facile violarli. La crittografia moderna non si basa più su questa idea ma sul postulato enunciato da August Kerckhoffs nel 1883 per cui: la sicurezza di un sistema crittografico è basata esclusivamente sulla conoscenza della chiave. I maggiori algoritmi utilizzati per la crittografia sono di dominio pubblico e quindi chiunque ne conosce la metodologia di lavoro ma nonostante ciò questo non costituisce una minaccia alla sicurezza dell algoritmo stesso ma anzi, al contrario,

21 è un incentivo al loro sviluppo, in quanto è più facile scoprirne difetti e debolezze e quindi porvi rimedio. La sicurezza di un algoritmo crittografico dipende dalle particolari proprietà matematiche della classe dei problemi NP, la cui soluzione necessita di una quantità di tempo che aumenta esponenzialmente con i dati in ingresso, rendendo gli attacchi a questi sistemi tanto più impraticabili quanto più aumenta la lunghezza delle chiavi coinvolte nei processi di cifratura e decifratura. La chiave non è altro che una sequenza di bit generata in modo più o meno casuale che, in linea teorica, può sempre essere ricavata. Esistono infatti dei metodi di ricerca esaustiva che consentono di risalire alla chiave utilizzata nella cifratura provando ad applicare l algoritmo ad un testo cifrato, impiegando chiavi sempre diverse, fino a che non si ottiene un risultato sensato. Questo modo di procedere è noto come attacco di forza bruta (brute force attack). Il successo di questo tipo di attacchi dipende dal numero massimo di tentativi che possono essere fatti, ovvero dal numero massimo di chiavi che quel particolare algoritmo può accettare, cioè dal keyspace. La tabella sotto mostra quanto influisce la lunghezza della chiave in un attacco a forza bruta sui tempi necessari a trovare la chiave giusta ipotizzando una forza di calcolo pari a un milione di tentativi al secondo. Lunghezza della chiave Dimensioni del keyspace Tempo di ricerca 32 bit 4, ,2 ore 40 bit 1, giorni 48 bit 2, ,9 anni 56 bit 7, anni 64 bit 1, anni Tabella 1. Tempo di ricerca necessario per un attacco di forza bruta nell ipotesi che si possano effettuare un milione di tentativi al secondo Si ribadisce che, per quanto riguarda la sicurezza del sistema, la chiave gioca un ruolo fondamentale ed in particolare in relazione alla sua lunghezza. Si potrebbe pensare, in via teorica di creare una chiave estremamente lunga, in grado di vanificare ogni attacco di forza bruta, ma ciò avrebbe come svantaggio un tempo notevolmente grande per implementare l algoritmo di cifratura e decifratura del messaggio. Dunque ci si trova di fronte ad un problema di ottimizzazione fra il vantaggio della sicurezza che induce una chiave moto lunga e lo svantaggio di notevoli tempi che rallenterebbero la fase di cifratura e decifratura. Per risolvere questo problema si va a valutare la tipologia di dati che si sta tentando di proteggere: il livello di sicurezza del sistema deve essere tanto più alto quanto più sono sensibili le informazioni in gioco. Secondo quanto detto, è opportuno tener presente il costo richiesto per violare l algoritmo che deve essere superiore al valore dei dati protetti ed il tempo richiesto per violare l algoritmo che deve risultare superiore al tempo per cui i dati cifrati devono rimanere segreti

22 Tenendo da conto quanto appena esposto, qualsiasi tentativo di attacco, anche se andasse a buon fine, non comporterebbe alcun vantaggio a colui che appronta il tentativo d intrusione La funzione di Hash La funzione di Hash è un processo di trasformazione dei bit, che si differenzia dai normali algoritmi crittografici, in quanto dopo la cifratura del messaggio non è possibile effettuare la decifratura. Quando si applica un messaggio ad una funzione di Hash essa restituisce una stringa di bit di lunghezza fissa, che rappresenta una sorta di sintesi matematica del messaggio, detta message digest (impronta digitale). La funzione di Hash gode di alcune proprietà che la rendono crittograficamente sicura: è applicabile a qualsiasi sequenza di dati di qualsiasi tipo e dimensione; il risultato della sua applicazione è una stringa di bit di dimensione fissa indipendente dalla dimensione del messaggio originale; la variazione di un solo bit del messaggio originale comporta la variazione dell intero digest; è una funzione a senso unico (one way), cioè risulta impossibile risalire al messaggio originale partendo dal digest; è una funzione senza collisioni (collision free), nel senso che è impossibile trovare due messaggi diversi tra loro che restituiscano lo stesso digest. In realtà la funzione di Hash è una applicazione non iniettiva caratterizzata da un dominio con uno spazio di dimensione infinita che rappresenta l insieme di tutti i messaggi in chiaro di qualsiasi lunghezza e un codominio con uno spazio a dimensione finita che rappresenta l insieme di tutti i possibili digest di lunghezza prefissata. Risulta però matematicamente impossibile che ad ogni elemento del dominio corrisponda un unico elemento del codominio, è comunque talmente bassa la probabilità che a due elementi distinti del dominio corrisponda uno stesso elemento del codominio che si può dire che la funzione di Hash è una relazione senza collisioni ed a senso unico. Si può dunque dire che due messaggi che hanno lo stesso digest sono uguali tra loro e questo ci permette di utilizzare la funzione di Hash ogni qualvolta il fine è quello di confrontare due messaggi tra loro per verificarne l uguaglianza. Essendo i messaggi di dimensioni arbitrarie, risulta sicuramente più comodo eseguire il confronto direttamente sui digest che sono a lunghezza fissa. Questa tecnica apre la strada ad una delle più importanti applicazioni della funzione di Hash: la firma digitale

23 I principali algoritmi per la funzione di Hash I principali algoritmi che la funzione di Hash utilizza sono: MD5 (Message Digest 5): è un algoritmo sviluppato dai laboratori RSA che fornisce digest di 128 bit, nel 2006 si sono presentati casi di collisioni; SHA (Secure Hash Algorithm): chiamato anche Secure Hash Standard (SHS) è un algoritmo pubblicato dal Governo degli Stati Uniti che produce digest di 160 bit; SHA-1: è la versione migliorata del precedente algoritmo. Produce anch esso digest di 160 bit, ma, a differenza del suo predecessore, l SHA- 1 non è stato ancora violato; SHA-256, SHA-512, SHA-384: sono stati sviluppati e proposti nel Draft Federal Information Processing Standard (FIPS) nel 2001; rispettivamente producono un digest di 256 bit, 512 bit e 384 bit aumentando quindi la sicurezza rispetto a SHA Stima sulla sicurezza della funzione di Hash La funzione di Hash è un algoritmo di cifratura one-way che codifica secondo funzioni matematiche non invertibili un messaggio, cioè non è possibile decodificare il digest a partire dal risultato cifrato. Il digest è teoricamente univoco, non dovrebbero quindi esistere due stringhe diverse che codificate generino lo stesso risultato cifrato, tale eventualità è chiamata collisione e una sua scoperta porterà lentamente l algoritmo ad essere dichiarato non sicuro. Le combinazioni possibili, variano da algoritmo a algoritmo, sono superiori all ordine di milioni di miliardi, lasciando l ingannevole fiducia sull indecifrabilità del digest. Negli anni ottanta il matematico americano Martin Hellman studiò una tecnica chiamata time memory trade-off (compromesso tempo-memoria) per decifrare il digest generato da una funzione di Hash. In pratica Hellman propose di creare dei dizionari in cui venivano inseriti tutti i digest generati da ogni possibile messaggio. La conseguenza è la creazione di un grande vantaggio nella ricerca del digest, infatti in un attacco di forza bruta, il maggiore spreco di burst time sta nella codifica ripetuta della generazione del digest e non nel confrontarlo, mentre con l uso del dizionario si va ad effettuare direttamente il confronto. Il problema di questa tecnica sta nella dimensione del dizionario infatti un dizionario capace di contenere tutti i digest frutto delle combinazioni alfanumeriche di messaggi sufficientemente lunghi supererebbe le decine di terabyte. Per ovviare a ciò Philippe Oechsin, un esperto in sicurezza, ha ideato un procedimento per ridurre il dizionario di digest in una tabella molto più piccola chiamata rainbow tables

24 Come prima cosa si codificano i messaggi e si ottengono i digest corrispondenti; R hash tale che ad un digest faccia ora viene definita una formula di riduzione ( ) corrispondere un messaggio: ovviamente non sarà quello di partenza, poiché è impossibile invertire una funzione di Hash. Si itera t volte il seguente procedimento: si genera l hash del nuovo messaggio e R hash con i = 1, 2,, t dove i indica i si applica la formula di riduzione ( ) passaggi effettuati. Si verrà quindi a definire che: f R Hash Algorithm( f ) i i ( ) i 1 i i + = dove fi = messaggioi, ovvero il messaggio al passo i + 1 è il risultato della formula di riduzione i -esima applicata all i -esimo digest. In questo modo si genererà una catena password-hash-password-hash di migliaia di elementi ma di questi solo il primo e l ultimo verranno conservati su disco con un risparmio di memoria pari a t volte. Ora quando si vorrà confrontare un digest si applicherà f t e si controllerà che il risultato non sia l ultimo elemento di una delle catene (di cui come appena detto conserviamo solo l inizio e la fine); se ciò non fosse vero si applicherà in sequenza ft 1 e f t e si riconfronterà il risultato con l ultimo elemento delle catene. Continuando con questo procedimento all i -esimo passaggio si ricaverà che il digest ricercato fa parte di una certa catena X e quindi con discreta probabilità il messaggio che l ha generato sarà quello che precede nella catena. Non è possibile risalire la catena (si dovrebbe invertire una funzione di Hash) ma è stato memorizzato l inizio di tale catena e si può perciò riapplicargli in sequenza gli t i passi necessari a ritrovare il messaggio del passo precedente. Si ricava il digest del messaggio e lo si confronta con il risultato, scoprendo che è quello giusto. Questo metodo porta raramente a falsi allarmi dovuti a eventuali collisioni, generati dalle formule di riduzione lungo la catena; al contrario la versione originale di tale metodo applicava un unica ( ) i R hash ad ogni passo, con rilevanti percentuali di errore. Tale procedimento è velocissimo ed il tempo di cracking si riduce col quadrato della grandezza della tabella, cioè incredibilmente, usare una tabella da 1 gigabyte è 16 volte più veloce di una da 256 megabyte. Questo metodo risulta molto efficace quando i messaggi sono relativamente corti e quindi ottimale nel violare le password La firma digitale In quasi tutte le attività lavorative risulta indispensabile per verificare l autenticità di un atto l apposizione di una firma autografa. In ambito informatico questo è possibile per mezzo della firma digitale

25 L implementazione e la validazione di una firma digitale richiedono l utilizzo di una funzione di Hash e di un algoritmo di crittografia asimmetrica. Lo schema di principio con cui si realizza la firma digitale di un documento informatico è il seguente: Figura 8. Processo di firma digitale di un documento informatico Il messaggio originale viene elaborato mediante una funzione di Hash generando così il suo digest, a questo punto il digest viene cifrato utilizzando la chiave privata del mittente, infine si costituisce un documento finale costituito K priv M dal messaggio originale, dalla firma ed eventualmente dal certificato contenente la chiave pubblica di decifratura. Il documento così ottenuto viene trasmesso al destinatario, che dovrà verificarne l autenticità al fine di garantire la correttezza della trasmissione. Lo schema di principio con cui si verifica l autenticità della firma digitale di un documento informatico è il seguente: Figura 9. Processo di verifica della firma digitale Il documento firmato viene ripartito in due parti, in una è contenuta il messaggio originale e nell altra è contenuta la firma. Il messaggio in chiaro viene elaborato mediante una funzione di Hash generando così il suo corrispondente digest

26 La firma viene decifrata con la chiave pubblica del mittente K pub M, recuperata dal certificato relativo al mittente stesso, ottenendo così il digest presunto. A questo punto si effettua il confronto fra il digest ottenuto ed il digest presunto. Questa operazione può portare a due situazioni: i digest sono uguali, allora la firma è valida ed il documento è integro oppure i digest sono diversi e questo segnala che il documento ha subito delle modifiche che potrebbero essere di natura dolosa o accidentale, dal momento in cui è stato firmato dal mittente a quello in cui è stato ricevuto dal destinatario. La firma digitale così ottenuta lega l entità, che detiene l uso esclusivo della chiave privata, ai dati, tramite l impiego del digest, infatti ogni firma, anche se apposta con la stesa chiave privata, è unica e diversa in relazione ad un diverso documento. Si può, inoltre, precisare che il documento e la sua firma non devono necessariamente essere trasmessi sullo stesso canale, infatti un invio separato non toglie il legame esistente fra di esse. La firma digitale offre tutte le garanzie di sicurezza di una normale firma autografa, apportando una maggiore difficoltà alla falsificazione del documento, in quanto si dovrebbe entrare in possesso della chiave privata del mittente, e garantisce l integrità del documento, in quanto una qualsiasi modifica del documento implicherebbe la variazione dell intero digest. La fase di trasmissione avviene su canali sicuri, come ad esempio l SSL, garantendo così la sicurezza anche da attacchi del tipo man in the middle

27 1.4 La public key infrastructure Precedentemente si è discusso sulla validità degli algoritmi crittografici e sul vantaggio di utilizzare la firma digitale al fine di garantire la sicurezza e la segretezza della trasmissione di un messaggio. Il problema non è stato completamente risolto in quanto, ipotizzato un corretto utilizzo da parte dell utente delle metodologie prima elencate, per esempio la creazione ed il mantenimento di riservatezza della chiave, la firma digitale lega un documento non al suo autore, ma alla chiave che esso ha utilizzato nell operazione di cifratura, si necessita quindi di un entità che assicuri che quella chiave appartenga effettivamente all autore del messaggio. Inoltre si deve garantire che lo scambio e la divulgazione delle chiavi pubbliche avvengano in modo sicuro. Per questo si deve introdurre il concetto di infrastruttura a chiave pubblica, in cui un autorità fidata si preoccupa di identificare e autenticare tutti gli utenti che vogliano usufruire dei suoi servizi garantendo, inoltre l appartenenza di una chiave pubblica ad uno specifico utente mediante l emanazione di un certificato. L infrastruttura a chiave pubblica, definita acronicamente come PKI, può essere definita in vari modi, per esempio il NIST, nel documento Introduction to Pulic Key Technology and the Federal PKI Infastructure del 2001, la definisce come una gerarchia monopolizzata usata per l amministrazione di certificati e delle chiavi pubbliche, oppure può essere definita come una infrastruttura che fornisce servizi di cifratura e firma digitale ad utenti. Inglobando le varie definizioni in una unica, si può dire che una PKI risulta essere un insieme di hardware, software, risorse umane, protocolli, regole e procedure necessarie per rendere possibile l utilizzo su larga scala dei sistemi di crittografia asimmetrici Il certificato a chiave pubblica Un certificato a chiave pubblica è un documento informatico che associa una chiave pubblica ad un soggetto, per essere valido ai fini di legge deve essere firmato digitalmente da una entità preposta, detta autorità di certificazione che autentica l effettiva appartenenza della chiave al soggetto. Un certificato a chiave pubblica deve quindi contenere: i dati anagrafici del soggetto titolare, denominato subject; la chiave pubblica del soggetto ed informazioni relative allo stesso come l algoritmo di cifratura utilizzato, impieghi previsti, etc; il periodo di validità del certificato; i dati identificativi dell emettitore del certificato, denominato issuer; un digest delle informazioni precedenti cifrato con la chiave privata dell emettitore, denominato signature

28 Gli schemi sotto mostrano i processi di firma e verifica di un certificato: Figura 10. Firma del certificato da parte di un soggetto e di una autorità di certificazione. Figura 11. Verifica di un certificato a chiave pubblica. Quando il mittente vuole stabilire una comunicazione con il destinatario richiede ad una autorità di certificazione di farsi rilasciare un certificato a chiave pubblica. A questo punto il mittente appone la firma sul documento originale ed invia al destinatario sia il documento firmato sia il certificato. Il destinatario all arrivo del messaggio, verifica l attendibilità del certificato e l autenticità del documento firmato. Per fare ciò il destinatario decifra la signature con la chiave pubblica della dell issuer ottenendo un digest presunto da confrontare con il digest ricavato da tutti gli altri campi del certificato elaborati con la funzione di Hash. Se il digest presunto è uguale al digest ricavato allora il

29 certificato è valido e si procede alla verifica della firma, nel caso siano diversi, ciò implica che il certificato non è originale. L utilizzo dei certificati a chiave pubblica è necessario solo se si vuole conseguire la validità ai fine di legge, quindi è del tutto lecito scambiare documenti con la tecnica delle chiavi asimmetriche senza ricorrere all uso dei certificati, se ad esempio i documenti da scambiare non hanno una grande riservatezza Richiesta, ottenimento, durata e revoca di un certificato Un utente che desidera richiedere un certificato ad una autorità di certificazione deve come prima cosa registrarsi presso una autorità di registrazione. La procedura di registrazione costituisce una prima importante relazione tra l utente e l autorità di certificazione. Una volta attestata l'autenticità dell identità dell utente, l autorità di registrazione lo registra in un suo dominio di fiducia. Il fine primario della registrazione è quindi quello di garantire che la chiave pubblica richiesta da un utente sia effettivamente associata e quindi appartenga solo a quel determinato utente. Terminata la fase di registrazione, l'utente può richiedere l'emissione di un certificato. Durante la procedura di generazione di un certificato l'utente sottopone all'autorità di certificazione le informazioni da certificare e quest'ultima verifica l'accuratezza delle stesse in accordo a politiche e standard applicabili. L'autorità di certificazione firma poi le informazioni, generando il certificato e lo pubblica sul sistema scelto per la distribuzione dei certificati. L autorità di certificazione può anche archiviare una copia del certificato e registrare ogni operazione di generazione di certificati su di un proprio archivio. La richiesta di un certificato è realizzata di solito in formato PEM. Il formato PEM prevede l utilizzo di due Encapsulation Block, che indicano la posizione di inizio e di fine del certificato memorizzato nel file. All interno di ogni Encapsulation Block viene utilizzata la codifica Base64. Figura 12. Frammento di file contenente una richiesta di certificato L'utente genera sul proprio computer una coppia di chiavi utilizzando il software fornito dall autorità di certificazione oppure utilizzando quello già incluso nei browser. La chiave privata viene memorizzata localmente in un file nascosto. Se è richiesta una maggiore sicurezza la coppia di chiavi può venire generata tramite una Smart

30 Card collegata ad un computer e la chiave privata resta sempre memorizzata solo sulla Smart Card protetta quindi da PIN. Tramite posta elettronica l'utente invia una richiesta di certificato unitamente alla chiave pubblica generata, all autorità di certificazione di sua fiducia. L autorità di certificazione verifica l'identità del richiedente, di solito è prevista la richiesta di presentarsi di persona presso l autorità di certificazione. Effettuato poi il controllo, l autorità di certificazione emette il certificato come documento elettronico, lo invia al richiedente tramite posta elettronica e lo inserisce nel registro delle chiavi pubbliche. Ogni certificato generato ha una validità temporale limitata al cui termine va sostituito. Il periodo di validità di un certificato, in assenza di compromissioni o di usi illeciti, garantisce all'utente che deve utilizzare tale certificato, che la chiave pubblica può essere utilizzata per lo scopo per cui è stata generata e che l'associazione tra la chiave pubblica e le altre informazioni contenute nel certificato è ancora valida. L autorità di certificazione deve poter garantire misure efficaci contro usi fraudolenti ed illeciti di un certificato; lo strumento che può utilizzare è la revoca. Un certificato deve essere revocato in presenza delle seguenti condizioni: compromissione rilevata o semplicemente sospettata della chiave privata corrispondente alla chiave pubblica contenuta nel certificato; cambiamento di una qualsiasi delle informazioni contenute nel certificato o delle condizioni iniziali di registrazione. Un'autorità di certificazione che necessita di revocare dei certificati prima della loro scadenza naturale deve pubblicare un elenco degli stessi nel Certificate Revocation List (CRL), in modo che tutti gli utenti appartenenti alla stessa infrastruttura siano informati delle avvenute revoche. Le liste di revoca giocano un ruolo di fondamentale importanza in tutti i processi crittografici, in quanto devono essere consultate sia in fase di cifratura che in fase di verifica di una firma, poichè prima di cifrare un messaggio, va verificato che la chiave pubblica che si deve usare appartenga ad un certificato valido. Analogo discorso vale per la verifica di una firma, che può essere ritenuta valida solo se il certificato del firmatario, oltre ad essere autentico ed integro, non è stato revocato. L'autenticità e l' integrità del certificato si controlla verificando la firma dell autorità di certificazione che ha emesso il certificato. Lo stato di revoca si controlla verificando che il certificato in questione non compaia nella lista di revoca emessa dall autorità di certificazione competente. Il metodo di distribuzione della notifica di revoca attraverso CRL, distribuite periodicamente dall'autorità di certificazione, è detto di tipo pull, in quanto sono gli stessi utenti finali a fornirsi delle CRL dal sistema di distribuzione quando è necessario. Il limite legato al metodo di distribuzione delle notifiche delle revoche tramite CRL, è quello della latenza introdotta, infatti quest ultima dipende dalla periodicità di emissione delle CRL, che deriva dalle politiche di sicurezza stabilite dall'organizzazione. Una determinata politica potrebbe richiedere la pubblicazione

31 di una nuova CRL ogni qualvolta si richiede una revoca ma tale procedura risulta, tuttavia, molto dispendiosa dal punto di vista amministrativo. Per ovviare a questo problema, lo standard X.509 introduce una tipologia particolare di CRL definita Delta CRL. Con cadenza stabilita viene pubblicata una CRL base a cui viene associata una Delta CRL che contiene gli aggiornamenti alla CRL base. Date le dimensioni ridotte, le Delta CRL possono essere pubblicate con maggiore frequenza senza comportare un eccessivo consumo di risorse di rete Autorità di certificazione Come descritto nel paragrafo precedente esistono due entità che si occupano della sicurezza dei certificati: l autorità di registrazione e l autorità di certificazione. L autorità di registrazione si occupa di verificare l effettività identità dell utente richiedente in quanto il certificato deve appartenere ad un solo utente: il suo possessore. Una volta che l autorità di registrazione ha attestato la validità dell'identità dell'utente attraverso una serie di procedure definite da una determinata politica di sicurezza, ha il compito di abilitare l'utente come appartenente ad uno specifico dominio di fiducia. Spesso la funzionalità di autorità di registrazione viene espletata dall'autorità di certificazione. Una volta che l autorità di registrazione ha abilitato l utente come appartenente ad uno specifico dominio di fiducia l autorità di certificazione crea un certificato per quell utente. L attività di un autorità di certificazione non si limita esclusivamente alla generazione dei certificati, ma deve poterne gestire l'intero ciclo di vita, deve quindi occuparsi anche delle fasi successive quali l aggiornamento e la revoca. Un ulteriore compito dell'autorità di certificazione è stabilire relazioni di fiducia con le altre autorità di certificazione. Un'autorità di certificazione può operare in modo autonomo, oppure appartenere ad una struttura più articolata. Le autorità di certificazione possono essere collegate essenzialmente in due modi: modello reticolare; modello ad albero. Nel modello reticolare ogni autorità di certificazione nasce come autorità locale di cui si fidano tutti e solo gli utenti appartenenti ad essa, e le altre autorità di certificazione comunicano tra loro la veridicità di un certificato attraverso un certificato particolare detto cross certificate. Lo svantaggio di un tale modello sta nel fatto che le autorità di certificazione potrebbero adottare politiche di sicurezza diverse e quindi il passaggio di un cross certificate da un autorità che garantisce una sicurezza maggiore ad una che ne garantisce di inferiori produrrà un decadimento sulla sicurezza del certificato

32 Nel modello ad albero è prevista un autorità di certificazione globale, la quale garantisce per se stessa autocertificandosi, che demanda ed organizza il compito di certificazione a strutture inferiori, firmando il loro certificato con la propria chiave privata e le autorità inferiori possono avere a loro volta la responsabilità sulla certificazione di altre autorità di livello inferiore. Lo svantaggio sulla riduzione della sicurezza che si verifica nel modello reticolare, non si presenta in questo modello, in quanto è l autorità globale a dettare le politiche di sicurezza per tutte le altre autorità facenti parte alla struttura. Pensando ad una rete globale, è facile immaginare che esistano una molteplicità di autorità di certificazione, con diverse politiche di sicurezza, che devono operare fra loro, è quindi impensabile che ogni utente abbia diretta conoscenza delle chiavi pubbliche di ogni potenziale interlocutore, o delle chiavi pubbliche delle corrispondenti autorità di certificazione. Per risolvere questo problema si utilizzano le cosiddette catene di certificazione, in cui l'utente che riceve un messaggio firmato verifica prima di tutto l'autenticità del certificato con la chiave pubblica dell autorità di certificazione che lo ha emesso e poi la firma del mittente con la sua chiave pubblica contenuta nel certificato. In questo modo è possibile allegare ad un messaggio che si vuole autenticare più certificati, definendo una vera e propria gerarchia di certificati, in cui ognuno attesta l'autenticità del precedente Standard X.509 Lo standard X.509 definisce il formato per i certificati a chiave pubblica e ne regola l esistenza. Lo standard X.509 è descritto nelle specifiche ITU-T corrispondenti alle specifiche ISO/IEC La prima versione dello standard X.509 fu presentata nel 1998, prevedeva un sistema gerarchico delle autorità di certificazione per l emissione dei certificati, in cui solo l autorità di certificazione poteva validare un certificato, in contrapposizione ai modelli allora esistenti di fiducia in cui chiunque poteva firmare e quindi attestare la validità delle chiavi altrui. Trascorsi degli anni la versione 1 risultò inadeguata e vennero introdotte la seconda e la terza versione in cui vennero aggiunti dei nuovi controlli di accesso dei campi, di sostegno e dell indice e furono integrate la compatibilità con altre topologie, aumentando la flessibilità; ad esempio fu permesso l utilizzo in reti di fiducia peer to peer

33 La struttura di un certificato X.509 v3 è mostrata in figura: Figura 13. Struttura di un certificato X.509 v3 Version: indica la versione del formato del certificato. Serial Number: è un codice numerico che identifica univocamente il certificato. Signature Algorithm: specifica l algoritmo utilizzato dall autorità di certificazione per firmare il certificato. Issuer X.500 Name: indica il nome dell autorità di certificazione secondo lo standard di naming X.500. Validity Period: specifica la data e l ora di inizio validità e fine validità del certificato. Subject X.500 Name: nome del possessore del certificato. Subject Public Key Information: contiene il valore della chiave pubblica del possessore del certificato e l algoritmo con cui tale chiave viene usata. Issuer Unique Identifier: è una stringa di bit aggiuntivi, opzionale, usata nel caso in cui nella struttura ad albero ci siano due autorità di certificazione. Subject Unique Identifier: stringa opzionale di bit usata nel caso di omonimia tra due membri di una stessa autorità di certificazione. Extensions: è suddiviso in tre sottocampi: l identificatore del tipo di estensione, un indicatore di criticità e il valore effettivo dell estensione. L indicatore di criticità facilita l interoperabilità tra sistemi che non utilizzano certificati con determinate estensioni e sistemi che, invece interpretano tutte le estensioni definite a livello di standard. Tale indicatore è un flag che indica se l estensione è critica o non critica; nell ultimo caso il sistema che deve elaborare il certificato può

34 eventualmente ignorare l estensione in questione se non è in grado di interpretarla. CA Signature: è la firma digitale dell autorità di certificazione sul certificato Standard PKCS PKCS (Public Key Cryptography Standard) è uno standard rilasciato dalla RSA Laboratories nel 1991 che permette di incrementare lo sviluppo e l impiego delle tecniche di crittografia asimmetrica. Il PKCS nel corso del tempo è diventato lo standard per questo tipo di tecnologie ed è usato in molte applicazioni come ad esempio nel protocollo S/MIME utilizzato per la posta elettronica e nel protocollo SSL impiegato per fornire sicurezza nelle comunicazioni su Internet. Il PKCS è costituito da quindici normative che definiscono gli algoritmi di crittografia, la sintassi e le interfacce per l utilizzo dei vari strumenti crittografici: PKCS#1: RSA Cryptography Standard. Definisce le linee guida per l implementazione dell algoritmo RSA sui calcolatori digitali. Lo standard PKCS#1 incorpora PKCS#2 e PKCS#4. PKCS#3: Diffie-Hellman Key Agreement Standard. Descrive un metodo per l implementazione dell algoritmo di Diffie-Hellman. PKCS#5: Password-Based Criptography Standard. Prescrive delle raccomandazioni per l implementazione della cifratura basata su password. PKCS#6: Extended-Certificate Sysntax Standard. Propone una sintassi ASN.1 che estende quella dei certificati X.509. PKCS#7: Cryptographic Message Syntax Standard. Descrive la sintassi generale per i dati crittografati. Su questo formato si basa ad esempio il protocollo di posta elettronica S/MIME e molti altri formati di interscambio per le informazioni di identificazione personale. PKCS#8: Private-Key Information Syntax Standard. Descrive la sintassi per le informazioni relative ad una chiave privata, e per le chiavi private cifrate. PKCS#9: Selected Attribute Types. Definisce i tipi ASN.1 degli attributi usati in PKCS#6, PKCS#7, PKCS#8 e PKCS#10. PKCS#10: Certification Request Syntax Standard. Descrive una sintassi per la richiesta di firma di un certificato. PKCS#11: Cryptographic Token Interface Standard. Specifica una API (Cryptoki) per i dispositivi in grado di eseguire operazioni crittografiche e trattare le informazioni relative (chiavi e certificati). È lo standard de facto per l interoperabilità tra i diversi modelli e tipi di HSM (Hardware Security Module). Definisce un modello ad oggetti del token indipendente dall hardware sottostante e dalla piattaforma operativa

35 PKCS#12: Personal Information Excange Syntax Standard. Specifica un formato per la memorizzazione o il trasporto di informazioni personali, come chiavi private, certificati e altro. È il formato utilizzato nei browser più comuni per l importazione e l esportazione di chiavi e certificati. PKCS#13: Elliptic Curve Cryptografy Standard. Specifica molti aspetti della crittografia basata sulla teoria delle curve ellittiche, è ancora in fase di sviluppo. PKCS#15: Cryptographic Token Information Format Standard. Propone un modello generalizzato per l accesso ai token crittografici, al fine di favorire maggiormente la compatibilità tra l hardware di diverse marche, viene utilizzato ad esempio nelle Smart Card

36 1.5 La steganografia L etimologia del termine steganografia è data dall associazione di due parole di origine greca: stèganos che significa nascosto, e grafèin che significa scrivere, da cui scrittura nascosta. Nonostante il significato di steganografia e di crittografia sia molto simile, tra le due tecniche esiste una differenza sostanziale. Lo scopo della crittografia è quello di nascondere il contenuto di un messaggio, cioè fare in modo che lo stesso sia interpretabile solo dagli stretti interlocutori, mentre la steganografia si prefigge di nascondere il messaggio facendo in modo che sia nascosta la comunicazione in sé, cioè solo gli interlocutori sanno di scambiarsi un messaggio e nessun altro. La stenografia nasce dall esigenza di andare a colmare le lacune che presentano le tecniche crittografiche, si pensi ad esempio ad un soldato che viene sorpreso a scambiare messaggi cifrati con un governo ostile: indipendentemente dal contenuto del messaggio, il solo fatto che vengano scambiati messaggi cifrati desta ovvi sospetti. Esempi sull uso della steganografia risalgono all epoca dell'impero persiano. Erodoto, racconta la storia di un nobile persiano che fece tagliare a zero i capelli di uno schiavo fidato al fine di poter tatuare un messaggio sul suo cranio; una volta che i capelli furono ricresciuti, inviò lo schiavo alla sua destinazione, con la sola istruzione di tagliarseli nuovamente. Esempi più elaborati sono le griglie di Cardano che sono fogli di materiale rigido nei quali venivano ritagliati fori rettangolari ad intervalli irregolari dove l apposizione su un testo né mostrava il messaggio nascosto in quanto bastava leggere solo i caratteri contenuti in ogni foro, oppure la tecnica delle cifre nulle che venne utilizzata nella seconda guerra mondiale dalle truppe tedesche, la quale consisteva nell'inserire il messaggio nascosto in un altro messaggio di testo, in pratica il messaggio trasmesso veniva composto in modo tale che, unendo le lettere secondo un preciso schema (prime lettere di ogni capoverso, seconde lettere di ogni parola, etc), faceva ottenere il messaggio nascosto. Un'altra tecnica molto usata dai nazisti era quella dei micropunti fotografici, i quali erano fotografie della dimensione di un punto dattiloscritto che, una volta sviluppate e ingrandite, potevano diventare pagine stampate di buona qualità. In tempi recenti la steganografia viene usata per inserire in un file digitale un watermark che in caso di uso illecito, ad esempio una copia, permette di verificare l effettiva paternità del file. Un altro tipo di marchio digitale è il fingerprint che sono inseriti in diverse copie nello stesso file per distribuirlo ad utenti diversi. Il motivo è quello di ottenere una specie di numero seriale sul file che rende possibile al proprietario l identificazione degli utenti che lo hanno distribuito a terzi, ad esempio gratuitamente

37 1.5.1 Steganografia iniettiva e generativa La steganografia si basa sull esistenza di due messaggi: uno detto messaggio contenitore e l atro detto messaggio segreto. Il compito del messaggio contenitore è quello di incapsulare il messaggio segreto in modo tale che nessuno, all infuori degli interlocutori, sappia che il messaggio segreto sia nascosto dentro quello contenitore. L evoluzione delle tecniche informatiche ha favorito lo sviluppo di algoritmi steganografici sempre più sofisticati, sicuri e pratici da usare, ed ha allargato le tipologie di messaggi contenitori, infatti si potranno usare ogni tipo di files presenti su un computer, anche se solitamente si usano immagini, files sonori e files video. In base all'origine del file contenitore si possono distinguere due tipi di algoritmi steganografici: algoritmi di steganografia iniettiva; algoritmi di steganografia generativa. Gli algoritmi di steganografia iniettiva consentono di iniettare il messaggio segreto all'interno di un messaggio contenitore già esistente modificandolo in modo tale che sia in grado di contenere il messaggio nascosto, in più devono cercare di rendere il messaggio steganografato indistinguibile dall'originale, in maniera tale da non produrre sospetti a chi potrebbe esaminare la comunicazione. Gli algoritmi di steganografia generativa, partendo dal messaggio segreto producono un opportuno contenitore atto a nascondere nel migliore dei modi il messaggio segreto Modelli steganografici Le tecniche steganografiche possono essere suddivise in tre categorie: steganografia sostitutiva; steganografia selettiva; steganografia costruttiva Steganografia sostitutiva La steganografia sostitutiva è la tecnica più diffusa, al punto che quando si parla di steganografia in generale ci si riferisce ad essa. La steganografia sostitutiva si basa sul fatto che la maggior parte dei canali di trasmissione introducono un rumore ai messaggi che vi scorrono. Figura 14. Effetto sulla trasmissione di un messaggio in un canale rumoroso

38 Gli algoritmi di steganografia sostitutiva si basano sulla sostituzione del rumore introdotto dal canale con il messaggio che si vuole nascondere e quindi, a meno di conoscere la chiave segreta, è indistinguibile dal rumore vero e proprio, e quindi può essere trasmesso senza destare sospetti. L introduzione di rumore nei files che vengono usati come contenitori proviene dal fatto che essi, se prendiamo ad esempio immagini, files sonori e files video, vengono informatizzati dalla realtà attraverso una conversione analogico digitale, è quindi in questa fase di acquisizione che si introduce il rumore. Le immagini vengono digitalizzate per mezzo di scanner e fotocamere, i files sonori attraverso schede di acquisizione audio, mentre i files video utilizzando videocamere. In pratica gli algoritmi di steganografia sostitutiva vanno a sostituire i bit meno significativi dei files digitalizzati con i bit che costituiscono il messaggio segreto in quanto i bit meno significativi corrispondono ai valori meno evidenti di una misura, cioè proprio quelli che possono essere facilmente affetti da errore. Il messaggio segreto viene introdotto nel file contenitore attraverso un'iniezione steganografica, il file risultante si presenta in tutto e per tutto simile all originale, con differenze difficilmente percettibili ai sensi umani e quindi, a meno di confronti approfonditi con il file originale, utilizzando tecniche apposite che verranno descritte successivamente, è difficile valutare se le eventuali perdite di qualità siano da imputare al rumore od alla presenza di un messaggio segreto steganografato, in più si può notare che spesso il file originale non è disponibile all analista quindi l effettuazione di metodologie di confronto risulta impraticabile Steganografia selettiva La steganografia selettiva è una tecnica puramente teorica e non viene utilizzata quasi mai in pratica. Gli algoritmi di steganografia selettiva si basano sull'idea di procedere per tentativi fino a quando non si riesce a trovare un file contenitore che sia adatto a contenere un certo messaggio segreto senza doverlo modificare o introdurre una variazione sul rumore. Questa tecnica non viene impiegata perché è molto dispendiosa in termini di tempo, ed oltretutto permette di nascondere una quantità d'informazione molto modesta, infatti aumentando la lunghezza del messaggio nascosto diventerebbe sempre più elevata la possibilità di trovare un file contenitore adeguato

39 Steganografia costruttiva La steganografia costruttiva, come la steganografia sostitutiva, inietta il messaggio nascosto nel file contenitore ma nel modificare il file contenitore tiene conto di un modello di rumore, cioè non va a modificare le proprietà intrinseche del file contenitore rendendo il file stenografato estremamente simile a quello originale. Questa tecnica sembrerebbe la migliore, ma in realtà la costruzione del modello di rumore è molto complicata ed immaginando che un possibile attaccante conosca un modello più elaborato per lui sarebbe semplice individuare il messaggio nascosto. Inoltre, se un possibile attaccante venisse in possesso del modello di rumore utilizzato, lo potrebbe analizzare ottenendo la chiave di lettura per tutti i files steganografati con quel modello La steganografia applicata ai files digitali In questo paragrafo verranno descritti i principali algoritmi steganografici che sono applicati a diverse tipologie di files. Verranno essenzialmente presi in esame: files Bitmap; files Wave; files compressi con algoritmi loss less e lossy; in modo da rendere evidente la differenza che intercorre fra la manipolazione di un file non compresso con uno compresso

40 Steganografia dei files Bitmap Bitmap è un tipo di formato dati utilizzato per la rappresentazione di immagini raster sui sistemi operativi Microsoft Windows e OS/2, fu introdotto con Windows 3.0 nel I files Bitmap, hanno generalmente l'estensione.bmp, o meno frequentemente.dib (device-independent bitmap). L immagine è costituita da una successione di pixel a cui si fa corrispondere un colore definito in una tavolozza (palette). Il numero di bit che costituiscono il colore determina la profondità dell immagine. Per files di profondità maggiore di 8 bit i colori non sono indicizzati ma si utilizza la codifica RGB. La codifica RGB è stata descritta nel 1931 dalla CIE (Commission Internationale dell Enclairage), è un modello di rappresentazione dei colori di tipo additivo che si basa sui tre colori fondamentali: rosso (Red), verde (Green) e blu (Blue). Per sintesi additiva si intende che unendo i tre colori fondamentali con la loro intensità massima si ottiene il colore bianco. Un file Bitmap ha la seguente struttura: BITMAPFILEHEADER: contiene informazioni sulla grandezza in byte del file e l'offset del primo byte nella mappa dei pixel; BITMAPINFOHEADER: contiene le dimensioni in pixel dell'immagine e il numero di colori utilizzati, sono indicate inoltre la risoluzione orizzontale e verticale del dispositivo di output che uniti alla larghezza e all'altezza in pixel, determinano le dimensioni di stampa dell'immagine in grandezza reale; RGBQUAD: contiene la rappresentazione di tutti i pixel che compongono la Bitmap. Ora si esamineranno in modo accurato le varie sezioni della struttura indicando offset e descrizione dei vari bit. Il BITMAPFILEHEADER è costituito da: Byte Dimensione Descrizione iniziale 1 2 bftype (Identificatore di formato) Deve essere settato a BM in codifica ASCII per dichiarare che è un file Bitmap 3 4 bfsize (Grandezza complessiva del file) Specifica la grandezza del file in bytes 7 2 bfreserved1 (Riservato1) Deve essere settato sempre a bfreserved2 (Riservato2) Deve essere settato sempre a bfoffbits (Lunghezza intestazione) Specifica l'offset del primo byte nella mappa dei pixel Tabella 2. Descrizione del BITMAPFILEHEADER

41 Il BITMAPINFOHEADER è costituito da: Byte Dimensione Descrizione iniziale 15 4 bisize (Dimensione del BITMAPINFOHEADER) Specifica la dimensione in bytes del BITMAPINFOHEADER 19 4 biwidth (Larghezza della Bitmap) Specifica la larghezza della Bitmap in bytes 23 4 biheight (Altezza della Bitmap) Specifica l altezza della Bitmap in bytes 27 2 biplanes (Numero di pani del dispositivo di output) Deve essere settato sempre a bibitcount (Contatore di bit) Specifica il numero di bits per pixel, i valori accettati sono: 1 (bianco e nero), 4 (16 colori), 8 (256 colori), 24 (16,7 milioni di colori) 31 4 bicompression (Tipo di compressione) Viene settato a 0 se non c è compressione 35 4 bisizeimage (Dimensione della Bitmap) Specifica la dimensione dell immagine in bytes, se non c è compressione deve essere settato a bixpelspermeter (Risoluzione Orizzontale) Specifica la risoluzione orizzontale in pixel per metro del dispositivo di output 43 4 biypelspermeter (Risoluzione Verticale) Specifica la risoluzione verticale in pixel per metro del dispositivo di output 47 4 biclrused (Numero di colori usati) Specifica il numero di colori usati nella Bitmap, se è settato a 0 il numero di colori viene calcolato usando il bbitcount 51 4 biclrimportant (Numero dei colori importanti) Specifica il numero di colori che sono importanti per la Bitmap, se è settato a 0 tutti i colori sono importanti Tabella 3. Descrizione del BITMAPINFOHEADER

42 Il RGBQUAD è costituito da: Byte Dimensione Descrizione iniziale 1 1 rgbblue (Componente di colore blu) Specifica la parte blu del colore 2 1 rgbgreen (Componente di colore verde) Specifica la parte verde del colore 3 1 rgbred (Componente di colore rosso) Specifica la parte rossa del colore 4 1 rgbreserved (Riservato) Deve essere settato a 0 Tabella 4. Descrizione del RGBQUAD La numerazione dell offset è stata fatta ripartire da 1 ma in realtà è seguente a quella del BITMAPINFOHEADER. Da notare il fatto che la struttura della RGBQUAD descritta si avvale della codifica RGB, se invece si fosse utilizzata una tavolozza non sarebbe stato possibile definirne una, in quanto ogni colore avrebbe un codice a se non definibile attraverso una codifica universale. Dopo aver definito in modo rigoroso la struttura di una Bitmap si può affermare che non considerando l intestazione, essa può essere definita come una matrice M N dove M ed N sono rispettivamente la larghezza e l altezza in pixel dell immagine M N P dove La dimensione totale dell immagine sarà data dalla formula ( ) 54 sono i bytes dell intestazione e P è la profondità dell immagine in bytes. Una cosa particolare pertinente la dimensione dell immagine riguarda il fatto che il formato Bitmap prevede che ogni riga sia rappresentata con un numero di bytes multiplo di 4 e gli eventuali bytes aggiuntivi avranno valore 0. Nel corso della trattazione successiva si farà riferimento ad immagini Bitmap a 24bit. Ad esempio per una immagine 2 2 si avranno: 54 bytes per l intestazione a cui vanno aggiunti 2 3 = 6 bytes della prima riga, che diventano 8 bytes (multiplo di 4), a cui si sommano altri 2 3 = 6 bytes della seconda riga, che diventano 8 bytes, cioè un totale di = 70 bytes. Si immagini di avere l immagine 2 2, esaminata in precedenza, tutta bianca, quindi per la codifica RGB tutte le componenti di colore fondamentale avranno la massima intensità, non considerando l intestazione, il file avrà la seguente struttura:

43 N. byte Sequenza decimale originale Sequenza binaria originale B B B B B B B B B B B B B B B B Tabella 5. Codifica binaria e decimale di una bitmap 2 2 tutta bianca Si ricorda che i pixel sono rappresentati da sinistra a destra e dal basso verso l alto e la sequenza RGB è invertita, per cui sarà BGR. A questo punto si pensi di voler nascondere un messaggio segreto dentro l immagine contenitore, utilizzando un algoritmo di steganografia. Ad esempio se si volesse nascondere il carattere A ed il carattere B in codifica ASCII (A= e B= ) si andrà a modificare in ogni bytes dell immagine contenitore il bit meno significativo ottenendo questo risultato:

44 N. byte Sequenza decimale originale Sequenza binaria Originale Sequenza decimale modificata Sequenza binaria modificata Sequenza binaria di A Sequenza binaria di B B B B B B B B B B B B B B B B B Tabella 6. Confronto tra la bitmap originale e quella steganografata Come si può notare confrontando la sequenza originale con quella modificata la variazione sui colori è minima. Per calcolare la dimensione necessaria all inserimento di un messaggio nascosto M N 3 di lunghezza in byte L bisogna risolvere la seguente equazione: L = 8 dove al denominatore si ha la quantità che esprime il numero di byte del file contenitore necessari per contenere un carattere del messaggio nascosto. Per un file 2 2 risolvendo l equazione si verifica che è possibile nascondere al massimo 2 caratteri, come era anche intuibile dall esempio sopra. Sfruttando solo il bit meno significativo di ogni byte diventa estremamente palese che servirebbe un file contenitore di dimensione molto elevata, per sopperire a questo problema si può pensare di sostituire nel file contenitore i 2 bit meno significativi o i 4 bit meno significativi aumentando così la lunghezza massima M N 3 come mostrato dalle rispettive equazioni a L = = 4 caratteri e 3 M N 3 L = = 8 caratteri. 1,5 Tuttavia aumentare la possibile dimensione del messaggio segreto utilizzando non più il singolo bit meno significativo di ogni byte, ma i due, tre o quattro bit meno significativi produce ovviamente una diminuzione della qualità dell immagine e quindi una differenza maggiore fra l immagine steganografata e l immagine originale incrementando così la possibilità di destare sospetti. Quindi si deve trovare un giusto punto di equilibrio fra la lunghezza del messaggio nascosto e la

45 qualità dell immagine ad esempio testando che la differenza di luminosità tra un pixel e quelli che lo circondano non sia troppo alta Steganografia dei files Wave Il WAVEform audio format è un formato audio sviluppato dalla Microsoft e dalla IBM come variante del formato RIFF, capace di gestire vari tipi di frequenze di campionamento, di canali audio e compressioni, la sua estensione è wav. Il Wave è costituito da sequenze di byte incapsulate in blocchi detti chunks. Un file Wave è costituito da tre blocchi: RIFF WAVE Chunk: descrive il fatto che il file RIFF concerne un file Wave che richiede due sotto blocchi: il Format Chunk e il Sound Data Chunk; Format Chunk: contiene la descrizione sul tipo di formato che verrà usato nel Sound Data Chunk; Sound Data Chunk: contiene informazioni sulla lunghezza del suono ed la codifica del suono stesso. Il RIFF WAVE Chunk è costituito da: Byte Dimensione Descrizione iniziale 0 4 ChunkID (Identificatore del blocco) Deve essere settato a RIFF in codifica ASCII 4 4 ChunkSize (Dimensione del blocco) Specifica la lunghezza del resto del blocco, in pratica è la lunghezza dell intero file in byte meno 8 byte per i due campi ChunkID e ChunkSize. In pratica sarà settato a: 4 + (8 + SubChunk1Size) + (8 + SubChunk2Size) 8 4 Format (Formato del blocco) Deve essere settato a WAVE in codifica ASCII Tabella 7. Descrizione del RIFF WAVE Chunk

46 Il Format Chunk è costituito da: Byte Dimensione Descrizione iniziale 12 4 Subchunk1ID (Identificatore del sotto blocco 1) Deve essere settato a fmt in codifica ASCII 16 4 Subchunk1Size (Dimensione del sotto blocco 1) Specifica la lunghezza del resto del blocco. Se la codifica usata è la PCM deve essere settato a AudioFormat (Formato audio) Specifica il tipo di formato audio. Deve essere settato a 1 se la codifica usata è la PCM altrimenti valori maggiori di 1 indicano che è stata effettuata compressione 22 2 NumChannels (Numero di canali) Specifica il numero di canali. Deve essere settato a 1 se il suono è mono, a 2 se il suono è stereo, etc 24 4 SampleRate (Frequenza di campionamento) Specifica la frequenza di campionamento del suono 28 4 ByteRate Deve essere settato a: SampleRate NumChannels BitsPerSample BlockAlign Deve essere settato a: NumChannels BitsPerSample BitsPerSample (Bit per campione) Specifica il numero di bit per campione ExtraParamSize Viene utilizzato solo se la codifica non è PCM 38 ExtraParams Viene utilizzato solo se la codifica non è PCM Tabella 8. Descrizione del Format Chunk

47 Il Sound Data Chunk è costituito da: Byte Dimensione Descrizione iniziale 1 4 Subchunk2ID (Identificatore del sotto blocco 2) Deve essere settato a data in codifica ASCII 5 4 Subchunk2Size (Dimensione del sotto blocco 2) Specifica la lunghezza del resto del blocco. Deve essere settato a: NumSample NumChannels BitsPerSample 8 9 Data (Dati) Deve essere settato con la sequenza di bit che costituisce il suono Tabella 9. Descrizione del Sound Data Chunk La numerazione dell offset è stata fatta ripartire da 1 ma in realtà è seguente a quella del Format Chunk. Per comprendere come è strutturato il campo Data del Sound Data Chunk si prenda ad esempio un suono mono, campionato a Hz a 16 bit. In fase di digitalizzazione, il suono sarà formato da stringhe di 16 bit al secondo, quindi nel campo Data si avrà una successione di campioni lunghi 16 bit. Nel caso di un suono stereo campionato a Hz a 16 bit, le stringhe di 16 bit ottenute sono due, una per il canale destro ed una per il sinistro, quindi nel campo Data ogni campione sarà costituito da due sottocampioni lunghi 16 bit, uno per il canale destro e l altro per il canale sinistro. Nel caso di codifica PCM il file Wave avrà dimensione totale data dalla formula 36 + Bits per campione Frequenza di campionamento Numero di canali Tempo ( ) dove 36 sono i bytes che costituiscono la dimensione del RIFF WAVE Chunk e del Format Chunk, la frequenza di campionamento è definita in Hz ed il tempo è definito in secondi. Come nel caso del file Bitmap è evidente che per applicare un algoritmo di steganografia basterà sostituire i bit meno significativi di ogni campione. Per calcolare la dimensione necessaria all inserimento di un messaggio nascosto di lunghezza in byte L bisogna risolvere la seguente equazione: Bits per campione Frequenza di campionamento Numero di canali Tempo L = d dove d è il numero di byte del file contenitore necessari per contenere un carattere del messaggio nascosto

48 Steganografia dei files compressi I formati esaminati precedentemente, il file Bitmap ed il file Wave, hanno la caratteristica di essere dei formati molto pesanti e per questo non sono molto usati per le trasmissioni su Internet. Per ovviare a questo problema sono stati sviluppati degli algoritmi di compressione che diminuiscono la dimensione del file originale cercando di preservare le caratteristiche visive o sonore del file a seconda che siano immagini o suoni. Gli algoritmi di compressione si suddividono in due categorie: algoritmi loss less: comprimono il file originale senza causare perdita di qualità, sono quindi invertibili; algoritmi lossy: comprimono il file originale causando una diminuzione della qualità e sono per questo non invertibili. Un tipico esempio di file in cui viene utilizzato l algoritmo loss less LZW (Lempel Ziv Welch) è il formato per le immagini GIF (Graphics Interchange Format). Nei files GIF, ogni pixel viene rappresentato da un singolo byte che identifica un colore della palette fra i 256 possibili. In questo tipo di files non è possibile applicare l algoritmo di steganografia elaborato in precedenza. Un primo algoritmo consiste nell acquisire un'immagine con una profondità di colore qualsiasi, limitare il numero di colori ad un numero inferiore a 256 cercando di mantenere comunque una buona qualità visiva, convertire l immagine così ottenuta in GIF completando la palette con dei colori molto simili a quelli rimasti. In questo modo sarà possibile rappresentare un colore in due modi, con il colore originale oppure con il colore aggiunto simile all'originale. Ora per iniettare un messaggio nascosto basterà controllare nella GIF dove esiste la possibilità di scelta fra più colori interscambiabili. Se le alternative sono due si potrà nascondere un solo bit: se il bit è 0 si sceglierà la prima, se è 1 la seconda; se le alternative sono quattro si potranno nascondere due bit: 00 per la prima, 01 per la seconda, 10 per la terza, 11 per la quarta e così via. Questa tecnica non è molto sicura in quanto è facile individuare sottoinsiemi di colori simili che potrebbero evidenziare la presenza di un messaggio steganografato. Un secondo algoritmo più sicuro del precedente sfrutta la struttura della palette della GIF. Essa si compone di 256 colori, di cui non è importante l ordine in cui i medesimi compaiono è quindi possibile ottenere 256! permutazioni e questo a patto di cambiare la sequenza dei puntatori dei colori permette di rappresentare una stessa immagine GIF in 256! modi diversi. In questa maniera sarà possibile log 256! = 1683 bit, cioè 210 byte, e questo indipendentemente dalle codificare ( ) 2 dimensioni dell immagine, in quanto basterà semplicemente permutare in modo opportuno la palette. Questo algoritmo risulta essere molto conveniente se il file contenitore risulta essere di piccole dimensioni

49 Un terzo algoritmo, interessante per la tecnica usata, non va a modificare un file contenitore già esistente ma genera una immagine frattale, utilizzando ad esempio quelle dell insieme di Mandelbrot attraverso una funzione matematica apposita. L immagine creata è una GIF ed il messaggio segreto viene nascosto per mezzo della palette. Tipici esempi di files in cui vengono applicati algoritmi distruttivi sono il file JPEG per le immagini ed il file MP3 per l audio. Nei files JPEG viene applicato un algoritmo di compressione che può essere schematizzato come in figura: Figura 15. Schema che rappresenta l algoritmo di compressione JPEG L immagine originale, usualmente codificata con uno spazio di colore RGB, viene convertita in codifica YUV che scompone l informazione relativa a ciascun pixel in due componenti: la luminanza (Y), che definisce il grado di luminosità nel range da nero a bianco, e la crominanza (UV), che definisce il colore in base al rapporto tra due assi, uno che va dal blu al giallo (U) e l altro che va dal rosso al verde (V). Poiché l occhio umano è più sensibile alla luminanza piuttosto che alla crominanza, l algoritmo va a diminuire il grado di definizione della crominanza lasciando inalterata la luminanza, riducendo fino a metà la dimensione del file iniziale, introducendo però perdita di informazione. A questo punto a ciascun blocco di 64 pixel viene applicata la DCT, acronimo di Discrete Cosine Transform, cioè un insieme di operazioni matematiche che trasformano i valori di luminosità e colore in valori di frequenza, in pratica i valori dei pixel contenuti nei blocchi di 8 8 presi dall immagine originale che variano da 0 a 255 vengono trasformati in frequenze che variano da -721 a 721. Ciascuno dei 64 valori di frequenza viene diviso per uno specifico coefficiente di quantizzazione ed il valore approssimato all intero più vicino, introducendo perdita di informazione. I coefficienti hanno un peso in modo tale da preservare le frequenze che l occhio umano percepisce in modo maggiore, quindi le frequenze più basse memorizzate nell angolo superiore di ogni blocco vengono mantenute, mentre le altre vengono eliminate. I valori ottenuti dal passaggio precedente vengono compressi attraverso un algoritmo loss less, utilizzando l algoritmo di Huffman o il Q-coding. Infine vengono inseriti nel file la tabella contenente i coefficienti di quantizzazione ed i valori della codifica entropica

50 Una possibile applicazione di un algoritmo steganografico ad una immagine JPEG si basa sul fatto che la matrice dei coefficienti ottenuti dalla DCT è un insieme di valori non interi, e poiché la loro rappresentazione informatica è intera deve essere applicato un processo di arrotondamento, proprio con esso, modificandolo appositamente è possibile inserire un messaggio nascosto. Questo algoritmo risulta essere molto robusto in quanto riesce ad evitare la perdita del messaggio nascosto anche se il file viene compresso nuovamente con un algoritmo lossy. La codifica MP3 sfrutta la psico-acustica per eliminare la ridondanza che esiste in un segnale audio. L orecchio umano, come studiato da Fletcher e Munson, risulta essere maggiormente sensibile alle frequenze comprese tra 2 e 5 khz. Figura 16. Soglia di udibilità di un singolo tono Quindi è possibile eliminare dallo spettro del segnale in analisi le frequenze che comunque l orecchio umano medio non percepirebbe: le bassissime e le alte frequenze. Un altro fattore che deve essere esaminato è il cosiddetto mascheramento. Si parla di mascheramento nel dominio della frequenza quando un suono di debole intensità ad una certa frequenza viene sovrastato da un suono ad alta intensità nei pressi della stessa frequenza, nell ordine di qualche centinaio di Hz e l orecchio umano riesce a percepire solo il secondo. Si parla di mascheramento nel dominio del tempo, quando ad esempio si hanno due suoni, uno debole ed uno forte nei pressi della stessa frequenza, quando quello forte cessa, l orecchio umano non percepisce immediatamente il suono debole, ma dovrà trascorrere un certo tempo di latenza, in quanto la membrana del timpano deve assestarsi. In conclusione, l effetto del mascheramento permette di eliminare una grande quantità di spettro del segnale audio perchè non udibile. Per codificare un file audio in MP3, si suddivide il segnale in 32 sottobande attraverso dei filtri, per ognuna delle stesse viene calcolato il valore per la soglia di mascheramento nel tempo ed in frequenza relativi alle bande adiacenti. Se il segnale audio è stereo si riesce ad eliminare ancora della ridondanza dovuta al fatto che l orecchio umano al di sotto di certe frequenze non percepisce la posizione spaziale dei suoni, quindi è possibile per le stesse usare il segnale ad un unico canale. A questo punto vengono effettuate le operazioni di quantizzazione in modo tale da introdurre il minor rumore possibile e di codifica entropica con algoritmi loss less,

51 nella fattispecie si utilizza l algoritmo di Hufmann. Per limitare il disturbo dovuto alla quantizzazione vengono applicati dei fattori di scala ad ogni banda. Infine si crea il file immagazzinando il flusso di bit in uscita. Come per il file JPEG, per applicare un algoritmo steganografico al file MP3 si procede andando a modificare i valori ottenuti dalla quantizzazione a cui sono stati applicati i fattori di scala per limitare il rumore da loro introdotto Stima sulla sicurezza degli algoritmi steganografici La steganografia, ha lo scopo di occultare la trasmissione del messaggio segreto, nel senso che un possibile attaccante non dovrebbe neanche sapere che si sta effettuando una trasmissione. Seguendo il principio di robustezza proposto da Kerckhoff per cui la sicurezza del sistema deve basarsi sull'ipotesi che il nemico abbia piena conoscenza dei dettagli di progetto e sull implementazione del sistema stesso, tutti gli algoritmi proposti non sono sicuri. Per aumentare la sicurezza di una trasmissione si può pensare di usare in modo combinato la steganografia e la crittografia, cioè il messaggio segreto viene prima cifrato e poi occultato in un file contenitore. Però questa soluzione non aumenta in sé la robustezza dell algoritmo steganografico in quanto solo il fatto che un possibile attaccante sia riuscito a sapere che il file contiene un messaggio segreto rende minima la robustezza dell algoritmo utilizzato. Come per la crittografia esiste una scienza che studia il modo di svelare le procedure steganografiche chiamata stegoanalisi. Le principali tecniche di stegoanalisi sono: stego only: lo stegoanalista dispone solo del file steganografato e deve cercare di svelare il messaggio nascosto; know cover: lo stegoanalista dispone sia del file steganografato che del file contenitore, può quindi effettuare dei confronti in modo da cercare differenze tra i due files; know message; lo stegoanalista dispone sia del file steganografato sia del messaggio nascosto, può quindi cercare di scoprire il metodo utilizzato per nascondere l informazione segreta; chosen stego: lo stegoanalista dispone sia del file steganografato che dell algoritmo di steganografia utilizzato; chosen message; lo stegoanalista genera alcuni files steganografati servendosi di opportuni strumenti steganografici partendo da un messaggio preciso, cercando degli elementi che lo aiutino ad identificare l uso di un metodo specifico. L attacco know cover risulta essere il più efficace in quanto se i due files che dovrebbero essere uguali presentano delle differenze, potrebbe significare che ci sia un messaggio nascosto, anche se la differenza potrebbero essere dovuta semplicemente da una diversa informatizzazione e quindi dal diverso rumore introdotto

52 Tenuto conto delle possibili tecniche di stegoanalisi per migliorare la robustezza di un algoritmo bisognerà seguire alcune regole: mai usare come files contenitore, files pubblici o facilmente reperibili; mai usare più volte lo stesso file come contenitore; distruggere i files originali dopo averli usati; poichè darebbe allo stegoanalista la possibilità di effettuare un attacco know cover. Un altro punto cruciale per valutare la robustezza di un algoritmo è il fatto che una possibile compressione del file steganografato possa cancellare il messaggio segreto, quindi gli algoritmi proposti per i files Bitmap e Wave sono da questo punto di vista inutilizzabili, mentre risultano essere abbastanza robusti gli algoritmi utilizzati sui files JPEG e MP3 se accortamente progettati. L algoritmo che sfrutta la modifica della palette sui files GIF risulta essere robusto sotto questo punto di vista ma è banalmente riconoscibile da un attacco chosen stego. Le metodologie pratiche che si utilizzano per effettuare controlli sulle immagini sono due: analisi visuali; analisi statistiche. Le analisi visuali sfruttano degli algoritmi di filtering che riescono a rendere evidente la presenza di un messaggio nascosto ma risultano essere molto lente se la mole di file da esaminare è notevole. Le analisi statistiche confrontano la distribuzione di frequenza dei colori in un potenziale file steganografato con la distribuzione di frequenza teoricamente attesa per un file steganografato, per scoprire la presenza di un eventuale messaggio nascosto

53 1.6 I protocolli web In questo paragrafo verranno descritti i protocolli http e https. Verrà in primo luogo fornita una breve storia del loro sviluppo, dopodichè verranno spiegate le modalità di scambio dei dati utilizzate. Infine saranno esposti pregi e difetti dei due protocolli Il protocollo http Http, acronimo di Hyper Text Transfer Protocol, è un protocollo di trasferimento per il world wide web. Fu progettato alla fine del 1980 da Tim Berners-Lee, la versione 0.9 venne utilizzata per la condivisione delle informazioni tra la comunità dei fisici. Nel 1991 fu sviluppata, sempre dallo stesso Bernere-Lee, la versione 1.0 che fu classificata nel 1996 dalla IETF come RFC Con l avvento dei browser grafici il protocollo http 1.0 risultò essere inadeguato, in quanto non era in grado di ospitare più siti www su uno stesso server, non permetteva il riuso delle connessioni disponibili e non garantiva una sicurezza adeguata. Nel 1997 si passò quindi alla versione 1.1, presentata come RFC 2068 nel 1997 ed aggiornata nel 1999 come descritto dal RFC L http sfrutta il protocollo TCP/IP per fornire i propri servizi di trasmissione. La porta TCP utilizzata usualmente è la 80. Figura 17. Architettura del protocollo http L http a differenza di protocolli come l Ftp, il Telnet e l Smtp, non è stato progettato esplicitamente per trasferire dati specifici ma permette il trasferimento di qualsiasi tipo file. L http è un protocollo di tipo request/response. Fino alla versione 1.0 la connessione veniva stabilita da un client tramite una request e chiusa dal server per mezzo di una response, con la versione 1.1 dopo la

54 response la connessione non viene terminata ma è possibile procedere con una nuova coppia request/response in modo da gestire transazioni multiple. L introduzione di questo metodo è dovuta alla grande complicatezza delle pagine html, che contengo immagini, suoni, etc, quindi per poterle scaricare avrebbero innescato un numero enorme di request/response singole che avrebbero occupato molte risorse del server mentre usando request/response multiple il server gestisce, ad esempio, il client fino alla consultazione completa dell intera pagina. La request e la response sono gestite come un messaggio MIME, Multipurpose Internet Mail Extension, ossia come un messaggio di testo, quindi anche immagini, suoni, etc sono trattati come tali, questo perché l http implementa i protocolli già forniti da Internet a livello più basso. La request è formata da tre campi: request line; header fields; message body. La request line è composta dal metodo di richiesta, dall URI e dalla versione del protocollo. L URI, Uniform Resource Identifier, identifica la risorsa su cui è applicata la request. I metodi di richiesta indicano il tipo di operazione che dovrà compiere il server sull URI. I metodi di richiesta più comuni sono: GET, viene usato per ottenere il contenuto della risorsa dell URI, ad esempio una pagina html; HEAD, viene usato per ottenere l header dell URI, ad esempio per controllare la data di modifica di un file, questo metodo non prevede l uso del body; POST, viene usato per inviare informazione al server, l URI identifica cosa si sta inviando ed il body ne racchiude il contenuto, viene ad esempio utilizzato per inviare i dati contenuti in un form di una pagina html. Gli header permettono al client di trasmettere ulteriori informazioni sulla richiesta e su se stesso. Gli header di richiesta più comuni sono: Host: contiene il nome del server a cui si riferisce l'uri. Con il protocollo http/1.1 risulta essere un campo obbligatorio in quanto permette l'uso dei virtual host; User-Agent: contiene informazioni sul client: tipo browser, produttore, versione, etc. La response è formata da tre campi: status line; header fields; message body

55 La status line contiene un codice a tre cifre che identifica un messaggio di risposta alla request formato in base al seguente schema, dove il carattere x identifica un numero da 0 a 9: 1xx: Informational: contiene messaggi informativi; 2xx: Success: indica se la richiesta è stata eseguita con successo; 3xx: Redirection: contiene indicazioni su come ottenere la richiesta effettuata, poiché il server non è in grado di eseguirla in modo immediato; 4xx: Client error: contiene informazioni sul tipo di errore eseguito nella richiesta del client che rende impossibile il soddisfacimento dal server; 5xx: Server error: contiene informazione sul tipo di errore eseguito dal server per cui non riesce a soddisfare la richiesta. Gli header permettono al server di inserire ulteriori informazioni che non sarebbe stato possibile inserire nella status line. Gli header più comuni sono: Server: contiene informazioni sul server: tipo e versione; Content-Type: contiene informazioni sul tipo di contenuto restituito. Tali informazioni, dette Media type. Per esempio ad una risposta HTML sono frequenti i tipi MIME (RFC 1521): text/html: identifica un documento html; text/plain: identifica un documento di testo non formattato; image/jpeg: identifica un immagine di formato JPEG. Il protocollo http offre la possibilità gestire la request/response chain ossia, di regolare il percorso logico che seguirà la request/response dal client al server anche tramite l inserimento di entità intermedie. Una request/response chain può essere modificata da tre entità: Proxy; Gateway; Tunnel

56 Il proxy è una entità software che si trova fra il client ed il server. Quando il client inoltra una request, essa viene indirizzata al proxy che la rinvia al server, dopodichè il server invia la response al proxy che la rinvia al client. Il proxy ha la funzione di caching, ossia memorizza tutte le pagine che i client richiedono e quelle raggiungibili dalle stesse, poichè hanno un alta probabilità di essere richieste, quindi l utilizzo del proxy risulta vantaggioso quando la linea tra esso ed il server è più veloce rispetto a quella tra il client ed il server. Da notare è il fatto che la connessione risulta essere sempre client-proxy, qualunque sia il server finale. Figura 18. Connessione http con proxy Il gateway è un entità che si trova tra il client ed il server, ma a differenza del proxy, il client vede il gateway come il server finale. Il gateway prende la request inviata dal client verso il server interessato, attende la response e la rinvia al client, in modo trasparente. Il gateway risulta essere vantaggioso quando ci si trova a comunicare con una serie di server che rispondono allo stesso nome, infatti esso smisterà le varie request ai server opportuni facendo percepire al client di comunicare con un unico server e quindi ottimizzando la connessione. Figura 19. Connessione http con gateway Il tunnel è un entità che permette lo scambio tra due collegamenti senza modificare la comunicazione; è usato quando la comunicazione necessita di

57 passare da un punto ad un altro attraversando un entità che non è in grado di trasmettere tale messaggio. Un esempio di utilizzo del tunnel avviene quando sulla rete è presente un firewall. Il tunnel permette di instaurare una connessione punto-punto ai capi del firewall, in modo da far vedere al client il server che altrimenti sarebbe stato nascosto, quindi il tunnel viene attivato solo quando avviene una request per il server nascosto, mentre rimane disattivato per le altre richieste. L utilizzo del tunnel risulta essere trasparente al client, in quanto se la request viene lasciata passare al server, il client avrà la sua response, mentre se il tunnel la blocca il client riceverà un errore dal browser. Figura 20. Connessione http con tunnel Il protocollo http ha essenzialmente tre difetti. Un primo difetto è dovuto al fatto che la connessione TCP, quando viene aperta ha una velocità molto bassa, questa poi aumenta fino ad andare a regime, una transazione request/response spesso non dura abbastanza per raggiungere tale velocità e quindi l http risulta essere inefficiente. Un miglioramento è stato apportato con le request/response multiple, che aumentando la durata della connessione, aumentano la probabilità di raggiungere la velocità di regime. Un secondo difetto si ha perché l http usa uno scambio dei dati stateless, cioè non esiste una memoria delle richieste del client e delle risposte del server, quindi se ad esempio si sta compilando una serie di form concatenate e cade la linea quando ancora non è stata terminata la procedura, tutta la compilazione viene cancellata poiché quasi sicuramente alla nuova connessione l indirizzo IP sarà diverso, oppure potrebbe accadere che ad un altro utente, che si collega allo stesso server appena è caduta la linea dell altro, venga assegnato l indirizzo IP precedente dell altro utente ed esso si ritroverebbe con le form compilate dal precedente utente. Una possibile soluzione è l utilizzo dei cookies che sono dei file che vengono inviati dal server al client in cui sono contenute informazioni riguardanti la connessione ed il server può richiederle se necessario al client. Il terzo difetto deriva dal fatto che la trasmissione dati dell http è in chiaro, quindi risulta relativamente facile osservare lo scambio che avviene tra il client ed il

58 server anche quando essa risulta essere riservata, ad esempio nello scambio di credenziali di autenticazione Il protocollo https L https è stato introdotto per migliorare la sicurezza del protocollo http, che attraverso l utilizzo di tecniche di crittografia e di autenticazione riesce a garantire un elevato livello di protezione nella trasmissione dei dati. L https in pratica interpone fra il TCP e l http il protocollo SSL. Figura 21. Architettura del protocollo https Il protocollo SSL, acronimo di Secure Socket Layer, fu sviluppato originariamente da Netscape, successivamente fu migliorato ed adottato come standard per Internet sotto il nome di TLS, Transport Layer Security, come descritto nel RFC Il protocollo SSL garantisce che solamente il client ed il server siano in grado di conoscere il contenuto della comunicazione. La porta TCP utilizzata usualmente è la 443. Una tipica trasmissione di un messaggio utilizzando il protocollo SSL si basa su due fasi. La prima fase ha la funzione di effettuare l'autenticazione reciproca del client, del server e di scambio della chiave di cifratura da utilizzare nel corso della connessione. La seconda fase è quella vera e propria di trasmissione del messaggio in cui lo stesso viene suddiviso in blocchi di lunghezza prefissata, ciascun blocco viene compresso e gli viene aggiunto il codice MAC atto a garantire l'autenticità dei dati, il blocco complessivo viene cifrato utilizzando un algoritmo simmetrico ed in testa viene posto l header SSL. Il blocco così composto viene inviato al server tramite il protocollo TCP/IP

59 Il server alla ricezione del blocco effettuerà il procedimento inverso rispetto a quello effettuato dall utente, quindi eliminerà l header SSL decifrerà il messaggio utilizzando la chiave opportuna, verificherà che il codice MAC sia quello del client, eliminerà il codice MAC, decomprimerà il blocco risultante ed infine, riunendo i vari frammenti, otterrà il messaggio originale. Riassumendo, la procedura di criptazione si basa su una chiave pubblica che il server invia al client ad ogni connessione, per mezzo di essa vengono generati pacchetti criptati che possono essere letti solo dal server che ha rilasciato la chiave pubblica poiché sarà l unico host a possedere la chiave privata. L'SSL Handshake protocol coordina gli stati del client e del server, permettendo così ai sistemi operativi di ognuno di operare in modo efficace. Lo stato è rappresentato in modo doppio: una volta come lo stato operativo corrente, e, durante la fase di handshake, come lo stato in attesa; inoltre sono mantenuti separati gli stati di lettura da quelli di scrittura. Una sessione SSL può includere più di una connessione sicura; inoltre le applicazioni possono avere più sessioni simultanee. Lo stato della sessione è costituito dai seguenti elementi: session identifier: è una sequenza arbitraria di bytes scelta dal server per identificare uno stato attivo della sessione, o comunque riesumabile; peer certificate: è un certificato X.509 del peer. Può essere nullo; compression method: specifica l'algoritmo usato per comprimere i dati prima della crittografia; cipher spec: specifica l'algoritmo di crittografia bulk (ad es. null, DES, etc.) e l'algoritmo MAC (per es. MD5 o SHA). Stabilisce inoltre alcuni parametri dell algoritmo di cifratura; master secret: sono 48 bytes segreti, condivisi dal client e dal server; is resumable: è un flag che indica se la sessione può essere usata per iniziare nuove connessioni. Lo stato della connessione è costituito dai seguenti elementi: server and client random: è una sequenza di bytes scelti dal server e dal client per ogni connessione; server write MAC secret: è la sequenza segreta usata nelle operazioni MAC sui dati scritti dal server; client write MAC secret: è la sequenza segreta usata nelle operazioni MAC sui dati scritti dal client; server write key: è la chiave per i dati cifrati dal client e messi in chiaro dal server; initialization vectors: se è usato un blocco cifrato con algoritmo CBC, allora per ogni chiave è mantenuto un vettore d'inizializzazione (IV). Questo campo è inizializzato dal protocollo SSL handshake. Poi il codice cifrato finale di ogni record è salvato per essere usato con i record seguenti;

60 sequence numbers: ognuna delle due parti comunicanti mantiene separati numeri di sequenza per i messaggi spediti e ricevuti per ogni connessione. Quando uno dei due manda o riceve un messaggio di change cipher spec, il numero appropriato della sequenza è posto a zero. I numeri di sequenza sono espressi da 64 bits e non possono quindi eccedere Il protocollo SSL Record layer riceve i dati dai livelli superiori senza interpretarli, in forma di blocchi non vuoti di dimensione arbitraria. Esso frammenta i blocchi di informazioni in SSLPlaintext records, di dimensione massima di 2 14 bytes. L SSLPlaintext record è costituito da: ProtocolVersion: specifica la versione del protocollo in uso; ContentType: è formato da 4 campi: o change_cipher_spec: specifica il cambio di cifratura usato per la comunicazione; o alert: indica eventuali condizioni di errore; o handshake: negoziazione che avviene nella sessione SSL; o application_data: sono i dati trasmessi nella sessione SSL. Quando viene applicato un algoritmo di compressione la SSLPlaintext si trasforma in una SSLCompressed. Tutti i records sono compressi tramite un algoritmo definito nello stato corrente della sessione anche se all'inizio viene definito come CompressionMethod.null. Nel caso in cui venisse usata una CipherSpec i dati relativi agli algoritmi di compressione vengono cancellati dallo stato. L algoritmo di compressione deve essere di tipo loss less e non può aumentare la lunghezza del contenuto più di 1024 bytes. Se la decompressione incontra un SSLCompressed.fragment che scompattato fosse più lungo di 2 14 bytes, deve segnalare un fatal decompression_failure alert. Tutti i records vengono protetti utilizzando algoritmi di crittografia e MAC definiti nel CipherSpec. Anche se inizialmente il CipherSpec è settato a SSL_NULL_WITH_NULL_NULL vengono comunque utilizzati gli algoritmi di cifratura e MAC. Le tecniche usate per le operazioni di crittografia e di MAC sono stabilite nel CipherSpec.cipher_type; tali metodi trasformano una struttura SSLCompressed in una SSLCiphertext. La decifratura inverte tale trasformazione. Le trasmissioni includono anche un numero di sequenza, in modo che i messaggi persi, alterati o intrusi siano rilevabili. Possono essere utilizzati due tipi di cifratura, quella a flusso e quella a blocchi. Gli algoritmi stream ciphers convertono le strutture SSLCompressed.fragment in stream SSLCiphertext.fragment e viceversa. Il MAC sarà definito come: hash(mac_write_secret + pad_2 + hash(mac_write_secret + pad_1 + seq_num + length + content))

61 dove: +: denota la concatenazione; pad_1: è il carattere 0x36 ripetuto 48 volte per MD5 o 40 volte per il SHA; pad_2: è il carattere 0x5c ripetuto lo stesso numero di volte del precedente; seq_num: è il numero di sequenza del messaggio; hash: è l'algoritmo hash definito nella CipherSpec. Concludendo la lunghezza del SSLCiphertext sarà: SSLCiphertext.lenght = SSLCompressed.lenght + CipherSpec.hash_size Gli algoritmi block ciphers, trasformano la struttura SSLCompressed.fragment in un blocco SSLCiphertext.fragment, dove però ci sarà una particolare attenzione ad operazioni di padding, le quali aggiungono caratteri per forzare la lunghezza del plaintext ad essere un multiplo della lunghezza dei blocchi cifrati dall'algoritmo di crittografia. Il protocollo SSL Change cipher spec è finalizzato a segnalare le transizioni nelle strategie di crittografia. Il protocollo consiste di un singolo messaggio, che è cifrato e compresso secondo il Current CipherSpec. Il messaggio consiste di un singolo byte di valore uno. Il messaggio di change cipher spec è mandato sia dal client che dal server per notificare all'altro che da quel momento in poi i records saranno protetti usando le nuove, appena negoziate CipherSpec e chiavi. La ricezione di questi messaggi causa al ricevente la copia del pending read state nel current read state: infatti sia il server che il client mantengono separato questo doppio stato. Quando il client o il server manda un messaggio di change cipher spec, esso copia il pending write state nel current write state. Il client manda allora un messaggio di change cipher spec seguente i messaggi di handshake key exchange and certificate verify, ed il server ne manda uno dopo aver processato con successo il messaggio di key exchange ricevuto dal client. Quando l'handshake è completato il client ed il server si scambiano i messaggi di change cipher spec ed iniziano a comunicare, usando le nuove proprietà appena concordate. Un messaggio di change cipher spec inaspettato provoca un unexpected_message alert. Quando si riesuma una sessione, il messaggio di change cipher spec è spedito subito dopo il messaggio di hello. Il protocollo SSL Alert ha lo scopo di inviare messaggi di alert in caso di anomalie. Ogni alert ha una priorità, ad esempio un messaggio con livello fatal si risolve con l immediata terminazione della connessione. Come gli altri messaggi anche quelli di alert sono cifrati e compressi come specificato nello stato corrente della connessione. Esistono due tipi di alert: quelli di chiusura e quelli di errore

62 Gli alert di chiusura vengono inviati quando il client ed il server devono comunicarsi che la connessione sta terminando per evitare un attacco. Entrambi possono iniziare lo scambio dei messaggi di chiusura. In particolare il messaggio close_notify che notifica al ricevente che il mittente non trasmetterà più su quella connessione. La sessione diviene non riesumabile se qualche connessione è terminata senza il dovuto messaggio close_notify con livello warning. Gli alert di errore vengono inviati quando uno dei due interlocutori riscontra un errore, allora la parte che lo ha rivelato manda un messaggio all'altra; dopo la trasmissione/ricezione di un messaggio di fatal alert, entrambe le parti immediatamente chiudono la connessione. Sia il server che il client sono obbligati a cancellare ogni identificatore di sessione, chiave, e altri segreti associati con la connessione fallita. I principali messaggi di alert di errore sono: unexpected_message: identifica che un messaggio inappropriato è stato ricevuto. Questo tipo di allerta è sempre fatale; bad_record_mac: questa allerta è spedita quando un record è ricevuto con un errato MAC; questo messaggio è sempre fatale; decompression_failure: identifica che la funzione di decompressione ha ricevuto un errato input, ad esempio dati che si espandono oltre la lunghezza loro assegnata; questo messaggio è sempre fatale; handshake_failure: indica che il mittente è incapace di negoziare un set accettabile di parametri di sicurezza tra quelli possibili; questo messaggio è sempre fatale; no_certificate: può essere mandato in risposta ad un certificate request se non è disponibile una certificazione appropriata; bad_certificate: viene mandato in caso di certificazione errata, contenente una firma che non è verificata correttamente, etc; unsupported_certicate: identifica una certificazione non supportata; certificate_revoked: indica che una certificazione è stata revocata dal suo firmatario; certificate_expired: indica che una certificazione è scaduta o attualmente non valida; certificate_unknown: indica che un problema non meglio specificato è sorto nel processare la certificazione; illegal_parameter: indica che un campo dell handshake è di dimensione errata o inconsistente con altri campi; questo messaggio è sempre fatale. Il protocollo SSL Handshake fornisce i parametri per la crittografia che compongono lo stato della sessione, ed opera interfacciandosi con il protocollo SSL Record Layer. Quando un client ed un server iniziano a comunicare, concordano sulla versione del protocollo, scelgono gli algoritmi di crittografia, si autenticano a vicenda, ed usano la crittografia a chiave pubblica per generare dati segreti condivisi. Questi processi sono eseguiti nel protocollo handshake, in particolare il client spedisce un messaggio di client hello al quale il server deve

63 rispondere con un messaggio di server hello, altrimenti si verificherebbe un errore fatale e la connessione fallirebbe. I messaggi client hello e server hello sono usati per stabilire le policy di sicurezza ottenibili fra client e server. Ad esempio il messaggio client hello avrà i seguenti attributi: protocol version: contiene la versione del protocollo utilizzato; session ID: contiene un numerio identificativo; cipher suite: contiene le combinazioni di algoritmi di crittografia supportati dal client, il server sceglierà una cipher suite oppure, se non c'è una scelta accettabile chiuderà la connessione; compression method: contiene una lista di algoritmi di compressione supportati dal client, se il server non ne supporta nessuno la sessione sarà chiusa. In modo analogo si avranno gli attributi del server hello dove nella cipher suite sarà contenuta la singola cipher suite, scelta dalla lista fornita dal client e nella compression method sarà contenuto il singolo metodo di compressione scelto dal server dalla lista fornita dal client. Inoltre, hanno due valori casuali che vengono generati e scambiati: il ClientHello.random ed il ServerHello.random, i quali devono essere indipendenti l uno dall altro. Dopo il messaggio di hello il server spedisce il suo certificato, se deve essere autenticato, oppure invia un messaggio di server key exchange se ad esempio il server non ha certificato, o se il suo certificato è solo per la firma. Se il server viene autenticato, può richiedere un certificato al client se ciò è in accordo con la cipher suite scelta. A questo punto il server manderà il messaggio di server hello done, indicando che la fase hello-message dell'handshake è completa, ed attenderà una risposta dal client. Se il server ha mandato un messaggio di certificate request, il client dovrà spedire o un certificate message o una no certificate alert. Il messaggio di client key exchange verrà mandato adesso, il cui contenuto dipende dall'algoritmo a chiave pubblica selezionato con il client hello ed il server hello. Se il client ha spedito un certificato con abilitazione alla firma, allora un messaggio di certificate verify verrà spedito per verificare esplicitamente il certificato. A questo punto un messaggio di change cipher spec viene mandato dal client, che copia il pending Cipher Spec nel current Cipher Spec. Il client manda immediatamente il messaggio di finished usando i nuovi algoritmi, chiavi e stringhe segrete concordate. Il server risponde con un messaggio di change cipher spec, copia il pending Cipher Spec nel current Cipher Spec, e spedisce il suo messaggio di finished in accordo con la nuova Cipher Spec. In questo modo la fase di handshake è terminata ed il client ed il server possono cominciare a scambiare dati del livello applicazione. Se il client ed il server decidono di riabilitare una precedente sessione o di duplicarne una esistente, il client manderà un client hello usando la Session ID della sessione da riesumare, il server controllerà la sua session cache per trovare una corrispondenza: se questa viene trovata il server manda un server hello con lo

64 stesso Session ID. Adesso sia il client che il server devono mandare un messaggio di change cipher spec e procedere direttamente fino al messaggio di finished. Una volta che il ripristino è completo, il client ed il server possono iniziare a scambiarsi dati di livello applicazione. Se il server non trova una corrispondenza di Session ID nella propria session cache, allora il server genera un nuovo Session ID e verrà eseguito un handshake completo. Il protocollo SSL risulta essere non sicurissimo se utilizza algoritmi di cifratura poco robusti, ad esempio l RC4 con chiave a 40 bits risulta essere poco affidabile poichè alcuni gruppi indipendenti sono riusciti a forzarlo in circa 8 giorni. Un altro difetto del protocollo SSL sta nel fatto che non protegge da attacchi agli host, quindi sarebbe conveniente proteggersi con software di garanzia dell integrità dei dati come ad esempio Tripwire. Tripwire usa funzioni hash sicure per garantire che i documenti non siano cambiati rispetto ad una versione di riferimento protetta in scrittura, se verifica un eventuale attacco, notifica all amministratore del sistema con una l avvenuta intrusione e ripristina i file alla situazione iniziale. Un ultimo difetto del protocollo SSL, è quello per cui esso riduce le prestazioni del server, in quanto lo stesso si trova a cifrare la pagina web richiesta dal client e se essa è molto pesante si potrebbero riscontrare notevoli rallentamenti o addirittura il timeout della pagina; quindi risulta conveniente progettare le pagine che useranno l https con poca grafica e più contenuti testuali

65 CAPITOLO 2 In questo capitolo verrà presentata l azienda presso la quale è stato effettuato il tirocinio. Si illustrerà poi la situazione di partenza in seguito alla quale è stato sviluppato il progetto, evidenziando le specifiche richieste poste in corso d opera

66 2.1 La Phi.d αlpha s.r.l. La Phi.d'αlpha s.r.l. è un azienda di consulenza strategica di impresa che si occupa dello sviluppo di sinergie estremamente articolate e mette in comunicazione i vari comparti di una azienda, intervenendo tempestivamente sulle aree deboli al fine di seguire costantemente ed ottimizzare i processi aziendali con soluzioni integrate. In altri termini, la Phi.d'αlpha s.r.l., aiuta le imprese ad organizzarsi e strutturarsi per far fronte al mercato globale partendo dalla individuazione del merito creditizio sino ad arrivare alla valutazione dell'azienda. Essenzialmente, la Phi.d'αlpha s.r.l., si occupa di consulenza finanziaria ed economica, permettendo così alle aziende clienti di creare valore ottemperando i seguenti obiettivi: ottimizzazione dei flussi di cassa relativi alla gestione operativa; minimizzazione del livello di rischio aziendale; minimizzazione nel costo delle fonti di finanziamento. L'attività della Phi.d'αlpha si esplica nelle seguenti possibili fasi di intervento: analisi andamentale; analisi quantitativa; analisi qualitativa e dei rischi operativi. Per analisi andamentale si intende l analisi dei rapporti che l azienda cliente instaura con il sistema bancario, quindi si effettua una verifica: dei rapporti bancari tramite web-banking, dei movimenti, dei saldi contabili e liquidi e delle condizioni di tenuta conto, della coerenza tra il numero di banche affidanti e le dimensioni aziendali, studiando i dati storici, attuali ed incrementali. Per analisi quantitativa si intende l analisi della struttura patrimoniale e dell equilibrio finanziario dell'azienda, quindi ci si troverà ad analizzare bilanci aziendali in modo da misurare la capacità dell'azienda di svilupparsi, di produrre risorse adeguate e reddito sufficiente per la copertura del debito e di remunerare il capitale di rischio. Per analisi qualitativa e dei rischi operativi si intende l analisi dell attività aziendale e della sua presenza sul mercato, studiando la tipologia della clientela e dei fornitori, analizzando rischi aziendali, nella fattispecie anche quelli dovuti ai contratti utilizzati sia per operazioni commerciali sia per rapporti con gli istituti di credito

67 2.2 Descrizione del progetto Da quanto descritto nel paragrafo precedente è facile evincere che la Phi.d'αlpha s.r.l. si occupa in maniera frequente della trattazione di documenti finanziari ed economici, quindi di dati sensibili e riservati che devono essere trasmessi per la loro natura, con modalità sicure. Fino ad oggi la Phi.d'αlpha s.r.l. ha utilizzato per la trasmissione di tali documenti, o mezzi non multimediali o semplici . Con l avvento di nuove normative giuridiche più restrittive e con l aumento di possibili azioni di spionaggio aziendale dovuto ad hacker, la Phi.d'αlpha s.r.l. ha deciso di dotarsi di un portale web in cui fosse possibile trasmettere documenti di elevata sensibilità in modo sicuro. La Phi.d'αlpha s.r.l. possedeva già un sito web ma non predisposto a tale esigenza, in quanto sviluppato diversi anni orsono risultava essere statico in quanto creato in semplice linguaggio html. Il vecchio sito risiede su un server Microsoft in hosting con supporto database Microsoft Access e linguaggio ASP, implementato su protocollo http. La Phi.d'αlpha s.r.l. ha richiesto esplicitamente di utilizzare tali tecnologie per la realizzazione del loro progetto. Il progetto richiesto consiste nell implementazione di un portale web ad accesso riservato con controllo condizionato degli accessi e criptazione dei documenti depositati. Essenzialmente la loro esigenza era quella di avere una zona su web dove poter condividere in modo sicuro documenti che poi sarebbero potuti essere consultati anche da diversi clienti e collaboratori. La gestione delle credenziali di autenticazione sarà gestita dalla Phi.d'αlpha s.r.l. stessa che, con cadenza trimestrale, fornirà ai suoi clienti e collaboratori un username ed una password per accedere all area riservata, quindi non sarà implementata una sezione di registrazione in quanto tale area è di possibile accesso ai soli collaboratori o clienti. Punto focale per la realizzazione è il fatto che i clienti ed i collaboratori sono in numero limitato, nell ordine di qualche decina. Una richiesta essenziale era quella di creare una tecnologia che rendesse il file trasmesso attribuibile solo ad una certa persona. Un requisito fondamentale, sollecitato fin dall inizio del tirocinio, era quello di realizzare un interfaccia molto semplice, friendly, utilizzabile anche da persone poco pratiche nell uso dei computers. Infine è stato richiesto di aggiornare tutto il sito in modo da mantenere i vecchi contenuti ma modificandone la struttura in modo da renderlo più dinamico, per esempio creando sulle pagine web un area dove fossero presentate le news del sito, aggiornabili tramite un database

68 CAPITOLO 3 In questo capitolo verrà descritta in modo accurato la realizzazione del progetto stesso, giustificando le eventuali scelte progettuali, in modo da far comprendere i vantaggi e gli svantaggi di alcune tipologie di decisioni

69 3.1 Analisi delle specifiche L obiettivo principale di questo tirocinio è stato la realizzazione di un portale web, che facesse collimare la sicurezza con la semplicità di utilizzo. Prima di descrivere la fase realizzativa vera e propria si spiegheranno le motivazioni che hanno portato a certe scelte progettuali. Innanzitutto sono state esaminate le tecnologie disponibili per la realizzazione, in questo caso un server Microsoft in hosting con supporto database Microsoft Access e linguaggio ASP con supporto del protocollo http. Per quanto riguarda l utilizzo di un database Microsoft Access, la scelta è stata avallata e non è stata richiesta una eventuale modifica con un DBMS (DataBase Management System) come MySQL o Oracle, in quanto il numero di dati da immettere e le query da effettuare in tale archivio risultano essere in numero esiguo, e quindi è adatto a tale scopo anche ad un database Microsoft Access senza precludere prestazioni sulla consultazione del portale. Visto che il portale sarà eseguito su di un server Microsoft e programmato in linguaggio ASP si è dovuto installare sul computer preposto allo sviluppo del progetto l IIS (Internet Information Service) per poter collaudare in remoto le pagine sviluppate. Per quanto riguarda il fatto di utilizzare un protocollo insicuro come l http, sono state fatte delle proposte di implementazione su protocollo https, ma visto il tempo ridotto del tirocinio, non è stato realizzato. A questo punto si può passare ad esaminare le specifiche richieste che possono essere riassunte in due punti: accesso riservato con controllo condizionato degli accessi; criptazione dei documenti depositati. Per esaminare queste specifiche si è proceduto con una prima fase di modellazione dei pericoli. 3.2 Modellazione dei pericoli La modellazione dei pericoli consente di individuarli in modo sistematico e di classificare quelli con la maggiore probabilità di incidenza sull applicazione da sviluppare. Si può dire, senza suscitare grandi obiezioni, che non esiste un sistema sicuro al 100% quando un'applicazione web è esposta ad un ambiente ostile come Internet, quindi l'unica soluzione possibile per sviluppare un applicazione web robusta è riconoscere la presenza di pericoli e ridurre o gestire i rischi associati. Anche se la modellazione dei pericoli risulta essere uno studio abbastanza elaborato e dispendioso in termini di tempo, e quindi di denaro, risulta essere

70 efficiente poiché rende la programmazione del software efficace già al primo sviluppo, basti pensare solo al fatto che risulta estremamente complicato identificare tutti i potenziali pericoli in una sola volta; in più la redazione della modellazione dei pericoli risulta un documento essenziale in fase di aggiornamento o di ampliamento del software. Il processo di modellazione dei pericoli può essere riassunto in sei fasi: Figura 22. Processo di modellazione dei pericoli Descriviamo in modo più preciso ogni fase. 1. Identificare i beni da proteggere: consiste nell individuazione dei beni, quindi dei files o dei dati di valore che devono essere protetti dai sistemi ostili. 2. Creare una panoramica dell'architettura dell applicazione: consiste nello sviluppo di diagrammi e tabelle semplici per documentare l'architettura dell'applicazione, inclusi sottosistemi, confini delle zone protette e flusso dei dati. 3. Scomporre l'applicazione: consiste nell individuazione delle varie interconnessioni con i sistemi ostili in cui si interfaccia l applicazione, per intercettare i vari punti vulnerabili del progetto. 4. Identificare i pericoli: consiste nell individuazione dei pericoli che potrebbero interessare l'applicazione. 5. Documentare i pericoli: consiste nella redazione di un modello che descriva i vari pericoli a cui è vulnerabile l applicazione. 6. Classificare i pericoli: consiste nella classificazione dei pericoli in modo da stabilire le priorità e poter affrontare prima quelli più seri, ovvero quelli che presentano i rischi maggiori. Il processo di classificazione valuta la probabilità del pericolo a fronte dei danni che potrebbe provocare in caso di attacco. È possibile che per alcuni pericoli sia preferibile non eseguire azioni correttive, se si paragona il rischio con i costi necessari per ridurlo. Iniziamo a redarre il modello dei pericoli. I beni da proteggere sono essenzialmente due: credenziali di autenticazione immesse dai clienti e dai collaboratori; file sensibili depositati dai clienti e dai collaboratori

71 L architettura dell applicazione può essere schematizzata come in figura: Figura 23. Diagramma dell architettura dell applicazione Analizzando l applicazione si vede che essa risulta interconessa con sistemi ostili in svariati punti. Possiamo suddividere i possibili pericoli per l applicazione suddividendoli in: pericoli a livello host; pericoli a livello applicazione. I pericoli a livello host sono quelli che scaturiscono dalla configurazione del server Microsoft. Le vulnerabilità principali da considerare sono: mancato aggiornamento con patch di sicurezza recenti, produce un alto rischio di esposizione a virus, cavalli di Troia, worms e attacchi IIS; utilizzo di porte, protocolli e servizi non necessari, accrescono la superficie di attacco e consentono ad utenti malintenzionati di raccogliere informazioni sull'ambiente e di sfruttarle a proprio vantaggio; possibilità di accesso anonimo non autenticato; utilizzo di password e criteri account inadeguati, consentono attacchi di violazione delle password, spoofing dell'identità. Questa tipologia di pericoli non verrà esaminata in quanto essendo lo spazio fornito alla Phi.d'αlpha s.r.l. in hosting viene già gestito da tecnici specializzati e competenti. I pericoli a livello applicazione sono: utilizzo di una convalida dell'input inadeguata, che apre la strada ad attacchi di script tra siti, SQL injection e di overflow del buffer; passaggio di credenziali o cookie di autenticazione su collegamenti di rete non crittografati, che consente l'acquisizione di credenziali o il dirottamento di sessione; utilizzo di criteri password e di account inadeguati, che consentono l'accesso non autorizzato;

72 incapacità di proteggere gli aspetti di gestione della configurazione dell'applicazione, incluse le interfacce di amministrazione; archiviazione di segreti di configurazione, come stringhe di connessione e credenziali degli account di servizio, in formato non crittografato; utilizzo di account di processo e di servizio con privilegi eccessivi; utilizzo di tecniche di codifica dell'accesso ai dati non sicure, che aumentano il pericolo associato agli attacchi di iniezione di comandi; utilizzo di un sistema di crittografia debole o personalizzato e impossibilità di proteggere adeguatamente le chiavi di crittografia; protezione basata sull'integrità dei parametri passati dal browser, ad esempio, i campi di modulo, le stringhe di query, i dati dei cookie, le sessioni e le intestazioni http; utilizzo di una gestione delle eccezioni non sicura, che può aprire la strada ad attacchi di tipo Denial of Service e alla divulgazione di dettagli di livello sistema di grande utilità per i pirati informatici; controllo e registrazione inadeguati, che possono comportare pericoli di ripudio. A questo punto si è passato alla classificazione del rischio di ogni pericolo. Il rischio può essere valutato come: rischio = probabilità potenziale danno. Procedendo con questa metodologia si è verificato che i rischi a più alto valore sono: uso insicuro della crittografia; controlli di accesso insufficienti; iniezioni di comandi; gestione insicura delle sessioni; gestione inadeguata degli errori. La fase di modellazione dei pericoli risulta conclusa, a questo punto si passa alla fase di valutazione delle possibili contromisure per limitare al massimo le vulnerabilità. 3.3 Analisi delle contromisure In questo paragrafo verranno descritte le possibili contromisure effettuabili per limitare l effetto delle vulnerabilità a rischio più alto riscontrate nella fase di modellazione dei pericoli

73 3.3.1 Uso insicuro della crittografia L utilizzo della crittografia verrà applicato ai file sensibili che i clienti ed i collaboratori trasmetteranno all area riservata del portale web della Phi.d'αlpha s.r.l.. Sono possibili due strategie di inserimento della fase di de-cifratura, può essere implementata lato server o lato client. Per implementazione lato server si intende che la de-cifratura viene eseguita da una funzione ASP durante l up-download del file come mostrato in figura: Figura 24. Diagramma dell architettura dell applicazione con cifratura lato server Per implementazione lato client si intende che la cifratura viene eseguita dagli utilizzatori nel proprio computer per mezzo di un software, dopodichè verrà eseguito l upload del file già cifrato, mentre nella fase di download i file vengono prelevati senza procedure ASP direttamente dall area riservata e decifrati nel proprio computer come mostrato in figura: Figura 25. Diagramma dell architettura dell applicazione con cifratura lato client L implementazione scelta è stata quella lato client in quanto, anche se quella lato server risulta essere più facile da eseguire per l utilizzatore, in quanto si trova ad

74 inserire solo la chiave ed il resto viene eseguito tutto dall applicazione web, questo tipo di implementazione risulta inadeguata per due motivi, come prima cosa produce un alta occupazione delle risorse del server con conseguente rallentamento, infatti essendo la fase di upload implementata in puro codice ASP e non con applicazioni installate sul server, inserire la fase di de-cifratura in questo punto provoca un grande tempo di trasmissione del file, come seconda cosa la trasmissione vera e propria viene eseguita in chiaro prima di essere cifrata dalla funzione ASP, quindi risulta vulnerabile ad attacchi di sniffing. In conclusione è stato sviluppato un software in VB.NET per gestire la decifratura dei file, non si è utilizzato software come PGP in quanto risultano essere troppo elaborati e di difficile comprensione per gli utilizzatori del portale. A questo punto sorge il problema di scelta fra un algoritmo asimmetrico o uno simmetrico. Visto che la Phi.d'αlpha s.r.l. ha esplicitamente richiesto che i file trasmessi potessero essere attribuiti al solo mittente e visto che l utilizzo di procedure di autenticazione tramite smart card è stato scartato, visti i tempi ridotti del tirocinio, si è pensato di impiegare un algoritmo a chiave privata, nella fattispecie l AES. Poiché gli algoritmi a chiave privata producono la gestione di un elevato numero di chiavi, si è pensato alla possibilità di sviluppo di un software steganografico che nascondesse dentro una immagine bitmap la chiave segreta, è stato quindi prodotto in VB.NET tale software. Si è pensato alla steganografia, poiché così la trasmissione delle chiavi può avvenire in modo sicuro anche tramite protocollo http ed è possibile per l utente l abbinamento del file trasmesso con la relativa immagine con chiave nascosta Controlli di accesso insufficienti Il portale deve gestire una fase di autenticazione degli utenti e proprio in questa fase che si insediano il maggior numero di vulnerabilità. La metodologia di autenticazione più utilizzata in ambito web si basa sull'invio delle proprie credenziali username e password da browser al server in chiaro, dopodichè, questo le confronterà con il database contenente le credenziali. Se non si utilizza un tunneling SSL, ciò può divenire un problema in quanto tramite un attacco di sniffing è possibile rintracciare le credenziali e conseguentemente riuscire ad ottenere l'accesso al programma web, utilizzando, appunto, le credenziali altrui così carpite effettuando un reply attack. Visto che il progetto sarà implementato su protocollo http si è pensato di cifrare la password con un algoritmo di hashing nella fattispecie MD5. Come per la fase di crittografia, l implementazione della funzione di hash può essere eseguita lato server e lato client. Per implementazione lato server, si intende che la funzione di hash viene eseguita da uno script ASP durante la fase di autenticazione come mostrato in figura:

75 Figura 26. Diagramma dell architettura dell applicazione con hash lato server Per implementazione lato client si intende che la funzione di hash viene eseguita in fase di invio da uno script lato client, ad esempio utilizzando Java Script, come mostrato in figura: Figura 27. Diagramma dell architettura dell applicazione con hash lato client L implementazione scelta è stata quella lato server in quanto, la gestione della funzione di hash lato client poteva produrre errori dovuti al blocco da parte del browser dello script Java Script ed il rischio di sniffing risultava essere molto limitato poiché, essendo il numero di utenti esiguo ed il loro accesso casuale, risultava molto difficile una possibile intercettazione di tali credenziali. Questo tipo di procedura di autenticazione risulta comunque vulnerabile ad attacchi di brute forcing, quindi si è predisposto l inserimento di una password non intelligibile, per evitare attacchi a dizionario, e di minimo 8 caratteri alfanumerici. Un'altra vulnerabilità, di basso rischio, è dovuta alla funzione di hash, infatti sono possibili delle collisioni sulle password, ma per questo non è possibile fare nulla, se non utilizzare funzioni di hash robuste

76 3.3.3 Iniezioni di comandi Un altro punto focale da analizzare, sempre dovuto all immissione delle credenziali di autenticazione, risulta essere quello di possibili attacchi dovuti ad iniezioni di comandi. Essendo il dialogo fra database e server gestito da codice SQL ci si troverà di fronte alla gestione di possibili attacchi di SQL injection. Per ovviare a questa vulnerabilità si è pensato di inserire una funzione di validazione dei dati che sostituisca i caratteri sospetti con caratteri non nocivi in modo da sventare l attacco Gestione insicura delle sessioni Per quanto riguarda la gestione delle sessioni create per tenere traccia degli utenti autenticati nell area riservata la soluzione ottimale sarebbe quella di utilizzare il protocollo https, ma visto che non è possibile, si sono usati degli accorgimenti che ne riducono le vulnerabilità, come ad esempio il fatto che i dati di sessione vengono inviati esclusivamente tramite POST e mai con il metodo GET poiché quest ultimo risulta visibile nell url. Per evitare che le pagine dell area riservata fossero richiamate ed accessibili in modo automatico attraverso l inserimento dell url o tramite ricerca su motore di ricerca si è implementata una funzione di verifica tramite le variabile di sessioni che se fornisce esito negativo, quindi l utente non è loggato, lo redirige sulla pagina di login. Per quanto riguarda la fase di logout si è prestata molta attenzione al fatto di possibilità di raggiungere le pagine dell area riservata per mezzo del bottone indietro del browser, per ovviare a questa vulnerabilità si è sviluppata una funzione che valuta l expires della pagina attraverso una procedura condizionale Gestione inadeguata degli errori Le ultime vulnerabilità prese in esame sono state quelle dovute alla gestione superficiale degli errori. La gestione corretta degli error fa si che un errore dell applicazione web, non sia fonte di informazioni sulla struttura interna del software ad eventuali attacchi. Basti notare che anche il semplice File Not Found piuttosto di un Access Denied può essere un informazione utile per un utente malintenzionato. Un altro esempio sono gli stack trace che generati dalla Virtual Machine forniscono spezzoni di codice a chi richiede la pagina al cui interno risiede un errore di programmazione. Per eliminare questa tipologia di vulnerabilità è stata effettuata una revisione completa del codice sorgente ed è stata effettuata una gestione accurata delle eccezioni in modo tale che restituiscano messaggi chiari per l utente e non compromettenti per l applicazione web

77 3.4 Implementazione del software lato client Per lo sviluppo del software lato client è stato utilizzato come linguaggio di programmazione il Visual Basic.NET, e come piattaforma IDE il Microsoft Visual Basic 2005 Express Edition. Si è scelto di utilizzare questa versione del compilatore poiché risulta essere totalmente gratuita e scaricabile dal sito Microsoft. Anche se presenta alcune limitazioni, come ad esempio la modalità di debug delle applicazioni solo in locale e la bassa estendibilità all aggiunta di strumenti esterni al menù e all uso di controlli di terze parti, risulta essere più che sufficiente per lo sviluppo del software relativo alla gestione delle policy di sicurezza richieste. Altro punto a favore, è che a differenza delle versioni Standard e Professional, risulta essere molto compatto, circa 40 MB, e la Microsoft non ha imposto nessun vincolo sulla creazione di software commerciale. I software che verranno sviluppati sono due: software per la gestione della crittografia; software per la gestione della steganografia Software per la gestione della crittografia Per lo sviluppo del software di crittografia si è utilizzata la classe appartenente al namespace System.Security.Cryptography in cui il Framework mette a disposizione del programmatore un insieme di classi dedicate a quasi ogni tipo di algoritmo di cifratura, sia per funzioni di hashing sia per algoritmi simmetrici sia asimmetrici. Come detto in precedenza si è scelto di utilizzare l algoritmo di cifratura AES poiché fornisce un elevata robustezza. Il software, tralasciando la gestione degli errori e delle eccezioni, può essere schematizzato attraverso due schemi a blocchi, uno per la fase di cifratura l altro per la fase di decifratura: Figura 28. Schema a blocchi delle funzioni di de-cifratura

78 La lettura e scrittura del file avvengono come strem binari poichè si è voluto creare un applicazione che gestisse qualsiasi tipo di file, se si fosse voluto ad esempio gestire solo file di testo si sarebbe potuto utilizzare una codifica come ad esempio la UTF-8. Le funzioni più importanti di questo programma sono quella di cifratura e quella di decifratura. Su entrambe le funzione devono essere inizializzati i valori di alcune variabili indispensabili per il funzionamento della classe che implementa l AES. Come prima cosa è necessario definire: BlockSize: dimensione del blocco; IV: vettore di inizializzazione. La BlockSize è l'unità minima da crittografare e gli viene assegnato il valore di 16 byte. Il vettore di inizializzazione ha un significato particolare che deve essere spiegato. L algoritmo AES per crittografare usa la chiave segreta ed il risultato della codifica dei byte precedenti, quindi è chiaro che prima dei primi 8 byte non ci sarà nulla, quindi è necessario fornire una base di partenza all algoritmo e questa è proprio il vettore di inizializzazione. Anche il vettore di inizializzazione ha la dimensione di 16 byte. A questo punto è necessario fornire la chiave segreta con la sua relativa dimensione. La chiave segreta viene data dall utilizzatore del software attraverso la compilazione di una TextBox, quindi assumerà il tipo stringa. Essendo un valore immesso, deve prima essere validato, per fare ciò è stata creata una funzione apposita che attraverso un espressione regolare controlla che siano immessi solo caratteri alfanumerici (alfabetici minuscolo, alfabetici maiuscolo, numeri) e che essi siano in numero sufficiente rispetto alla dimensione della chiave scelta, infatti è stata implementa la possibilità di far scegliere all utilizzatore la lunghezza della chiave fra 128 bit (16 caratteri) e 256 bit (32 caratteri). Il fatto di aver limitato il numero delle possibili chiavi risulta un indebolimento alla robustezza dell algoritmo, infatti si è passati dalla possibilità di inserire 256 caratteri a quella di inserirne 62, nella fattispecie per le chiave a 128 bit si passa da un valore di 2 3,4 10 ad un valore di 62 4,8 10 mentre per le chiavi a 256 bit si passa da un valore di , 2 10 ad un valore di ,3 10. Questa scelta è stata effettuata poiché risulta più semplice per l utilizzatore inserire una stringa di caratteri alfanumerici piuttosto che una sequenza di codice binario o esadecimale qualsivoglia. Una volta impostate queste proprietà della classe è possibile effettuare la decifratura utilizzando i metodi : CreateEncryptor().TransformFinalBlock(,,); CreateDecryptor().TransformFinalBlock(,,);

79 dove la funzione TransformFinalBlock accetta come parametri: inputbuffer: è l input sul quale eseguire l'operazione; inputoffset: è l offset nella matrice di byte dal quale iniziare a utilizzare i dati; inputcount: è il numero di byte nella matrice di byte da utilizzare come dati; e restituisce l array di byte contenente il file de-cifrato. Come richiesto dalla Phi.d'αlpha s.r.l. si è cercato di sviluppare il software in modo tale che fosse il più friendly possibile. Il software si presenta come una sola finestra in cui è possibile effettuare tutte le operazioni. Figura 29. Finestra del software per la gestione della crittografia Per rendere il più semplice possibile l utilizzo del software è stata gestita l immissione del file da de-cifrare per mezzo di un operazione di Drag&Drop, infatti per ottenere il path del file basta trascinarlo nella TextBox denominata Path. A questo punto l utilizzatore sceglierà la lunghezza della chiave scegliendo fra 16 e 32 caratteri ed inserirà la chiave nella TextBox denominata Chiave infine sceglierà se effettuare la cifratura o la decifratura premendo i bottoni in basso a destra ed in basso a sinistra. Il file cifrato avrà come estensione.cry mentre il file decifrato ritornerà ad avere l estensione originale. I files prodotti dal software verranno posizionati nella stessa directory del file che lo ha generato. Per evitare difficoltà dovute ad errori dell utilizzatore sono state gestite tutte le possibili eccezioni con il relativo messaggio di spiegazione sull errore commesso, sono state quindi gestiti errori dovuti a path non validi, a chiavi segrete non valide, etc Software per la gestione della steganografia Per ottenere una trasmissione della chiave maggiormente sicura si è pensato di inviarla in un file steganografato

80 Per rendere il file meno vulnerabile ad un possibile attacco, invece di utilizzare un software in commercio ne è stato sviluppato uno apposito, con un algoritmo ottimizzato. La tecnica steganografica applicata è di tipo sostitutivo e vengono utilizzati come file contenitori, immagini Bitmap. Ipotizzando una distribuzione equiprobabile fra gli zero e gli uno del file e quelli del messaggio, andando a modificare i bits meno significativi del file contenitore si produrrebbe una variazione del 50% dei byte che devono contenere il messaggio segreto. Per diminuire questa probabilità si è pensato, che essendo il messaggio relativamente corto in quanto la chiave può essere di 16 o 32 caratteri, è possibile utilizzare 64 byte per ogni carattere poiché i caratteri alfanumerici sono 62, richiedendo file contenitori di minimo 3 kb per chiavi da 16 caratteri e 6 kb per quelle da 32 caratteri. I 64 byte possono essere immaginati, pensando alla struttura di un file Bitmap, come una matrice 8 8 come in figura: Figura 30. Matrice contenente la codifica dei caratteri della chiave dove solo il riquadro nero identifica il carattere. Essendo i riquadri bianchi molto più numerosi di quelli neri si è pensato di associare a loro una sequenza di bits meno probabile. In particolare i riquadri neri sono stati rappresentati con una sequenza di soli zero mentre quelli bianchi con qualsiasi altra sequenza purché sia presente almeno un uno. La probabilità composta di avere n bits zero consecutivi è probabilità di avere tutte le altre parole sarà n 1, quindi la n 2 Immaginando di utilizzare questo procedimento su di un file contenitore con distribuzione equiprobabile di zero ed uno si vedrà che aumentando il numero di bits costituenti i riquadri il numero di bits da sostituire tenderà a diminuire

81 Ad esempio, per un blocco di 1024 byte si avrà che: N. di bits costituenti il riquadro N. di bits da modificare nel file contenitore Tabella 10. Esempio di bits da modificare nel file contenitore in base ai bit costituenti il riquadro Uno dei casi peggiori che si può avere, si presenta quando si usa come file contenitore un immagine completamente bianca. Si è per esempio utilizzata un immagine di 1056 byte ed è stato modificato sempre il primo riquadro dei 64. In questo caso anche un semplice attacco visuale fa notare l esistenza di una anomalia nell immagine ed andando a scomporla nei canali RGB è addirittura possibile identificare una certa sequenzialità su bits: Figura 31. Analisi visiva fra un immagine e la sua relativa steganografata Utilizzando un attacco statistico, l anomalia risulta evidente, in quanto esaminando l immagine convertita in cifre esadecimali, si nota subito l improbabilità di un rumore strutturato come quello in figura

82 Figura 32. Analisi statistica fra un immagine e la sua relativa steganografata Utilizzando invece immagini con variazioni di colore molto frequenti il risultato è molto apprezzabile, in quanto ad un attacco visivo risulta essere indistinguibile, mentre ad un attacco statistico, utilizzando sempre immagini diverse si rende difficoltosa l analisi. Per giustificare quanto detto verrà fornito un esempio con immagine cover con alta varianza nella frequenza di colore. Figura 33a. Immagine originale Figura 33b. Immagine steganografata L immagine ha una dimensione di di byte. Per la steganografia dell immagine sono stati utilizzati i seguenti parametri: chiave segreta: 534b44a19bf18d20b71ecc4eb77c572f numero i bit per byte: 2 shift del cifrario a scorrimento: 23 ottenendo una variazione di 532 bit su 523 byte, cioè una media di 1,02 bit per byte

83 Esaminando l immagine convertita in cifre esadecimali si vede come l immagine steganografata abbia una piccola variazione sulle componenti RGB del colore quasi sempre nell ordine dell unità. Figura 34. Frammento di codice esadecimale dell immagine e della sua relativa steganografata Per rendere più sicuro l algoritmo, i codici che costituiscono la chiave possono essere cifrati per mezzo di un cifrario a scorrimento. Il software, tralasciando la gestione degli errori e delle eccezioni, può essere schematizzato attraverso due schemi a blocchi, uno per la fase di inserimento della chiave e l altro per la fase di estrapolazione: Figura 35. Schema a blocchi delle funzioni di iniezione ed estrapolazione della chiave Il software si presenta come una sola finestra in cui è possibile effettuare tutte le operazioni. Figura 36. Finestra del software per la gestione della steganografia