GnuPG: Crittografia, Privacy e Open Source

Dovendo parlare di questioni di sicurezza, è necessario definire qualche concetto di base che verrà utilizzato nel seguito, anche perché la tendenza a dare per scontato il significato di alcuni termini di uso comune può essere fuorviante, oltre che impreciso. Le caratteristiche che deve possedere una firma digitale utilizzabile nel mondo reale sono:

Queste sono le caratteristiche implicite di una nostra firma a penna su un qualsiasi documento. Andando a buonsenso una firma digitale su un documento egualmente digitale dovrebbe assimilarsi a questa situazione ma, come vedremo, non è proprio così, e le cose non sono per nulla semplici, né dal punto di vista tecnologico, né dal punto di vista legale. Ma andiamo con ordine.

Per una serie di malintesi, o per un’eccessiva fiducia nella tecnologia, vista spesso come “La Soluzione”, di solito si pensa alla posta elettronica, ed in generale al documento in formato digitale, alla stregua di una normale lettera postale o di un fascicolo rilegato. Purtroppo, questo non è per niente vero, ed i motivi sono poco evidenti ai non “addetti ai lavori”.

Parlando di posta elettronica, i protocolli e gli standard con cui viene trattata sono ideati ed implementati per consentire la comunicazione attraverso un canale che per assunto era sicuro e fra alleati. Questo era vero quando la Rete era agli inizi e si chiamava Arpanet, l’antenata destinata alla comunicazione fra le università e gli istituti di ricerca. Non lo è più da quando i messaggi transitano sull’odierna Internet, che occorre iniziare a pensare come un luogo ostile. I punti deboli più evidenti del protocollo possono essere riassunti nei seguenti punti, senza entrare in dettagli troppo tecnici:

Tutto questo non sta a significare che la posta elettronica sia inutilizzabile, visto che è regolarmente impiegata come mezzo di comunicazione da buona parte del mondo industrializzato, ma semplicemente che così com’è non è sicura.

Gli stessi problemi li abbiamo di fronte ad un qualsiasi altro documento in formato digitale, che sia un testo, un foglio di calcolo o una presentazione: gli strumenti di creazione normalmente utilizzati non prevedono questo livello di sicurezza. Un fascicolo di carte è molto difficile da modificare, e chi lo fa deve essere ben attento a non lasciare tracce. Viceversa, un qualsiasi documento digitale è semplicissimo da modificare senza lasciare traccia alcuna.

Allo stesso modo non è dato sapere se il documento è stato effettivamente scritto, inviato o approvato dal mittente dichiarato nel documento stesso o indicato nel messaggio di posta elettronica che lo trasporta. Un documento fisico, cartaceo, può riportare la firma del mittente, che può essere addirittura apposta in presenza di testimoni, o di un notaio, che ne può certificarne l’autenticità anche a distanza di anni. Per un documento digitale questo è al momento poco fattibile, per ragioni che vedremo.

Per questi motivi, dal punto di vista legale e commerciale, i documenti in formato elettronico e la posta elettronica, a meno di artifici tecnologici o di procedure particolari, non possono essere equiparati alle controparti del mondo materiale. Questo vale anche per i rapporti fra privati, dove la riservatezza sta sempre più diventando un requisito importante.

Con gli strumenti che conosciamo ed utilizziamo quotidianamente, la risposta alla domanda nel titolo non può che essere negativa. Occorre aggiungere qualcosa, in attesa che venga proposto uno standard, un sistema, un qualcosa in più per risolvere almeno parzialmente questi problemi.

La crittografia può rispondere in parte alle basilari necessità di riservatezza e di autenticità. Non è la soluzione definitiva, che probabilmente non esiste e non esisterà mai, ma può almeno portare la posta elettronica ed i documenti digitali al livello minimo di riservatezza che possiede una lettera in busta chiusa.

Il problema è che, fino a qualche tempo fa, la crittografia era costosissima. Il suo impiego richiede risorse di calcolo, che significano tempo e denaro. Tentando la creazione di messaggi segreti, anche per gioco, possiamo renderci conto del tempo che occorre per cifrare sia pure un breve messaggio.

La conseguenza era che solo le applicazioni militari ne potevano usufruire, perché il costo da sostenere era nulla rispetto al danno derivante dalla possibilità che informazioni preziose cadessero in mano al nemico. Inoltre lo studio di nuovi sistemi per cifrare richiedeva elevate competenze in parecchi campi, non solo puramente tecnologici: fino all’inizio del ventesimo secolo i principali esperti di crittografia erano linguisti.

Negli anni a cavallo fra la Prima e la Seconda Guerra Mondiale qualcosa cambiò con la commercializzazione del primo sistema crittografico meccanizzato, che rendeva immensamente più semplice e veloce lo scambio di informazioni in modo sicuro: Enigma. Il costo dell’apparecchio era elevato, non certo alla portata di tutti, ma garantiva un livello di segretezza prima impensabile all’industriale o al commerciante che poteva permettersi la spesa. Anche se venduta in pochi esemplari, Enigma in questa versione segnò in qualche modo la fine del monopolio militare sulla cosiddetta crittografia forte. Purtroppo l’inizio della guerra, oltre alle altre tragedie ben più gravi, provocò una battuta d’arresto nello sviluppo di applicazioni civili della crittografia. Nel dopoguerra, la divisione del mondo in due blocchi portò a considerare in modo ancora più attento i codici segreti, al punto da classificarli a tutti gli effetti armamenti, la cui esportazione era ed è tutt’ora considerata un reato gravissimo, esattamente come vendere ordigni nucleari ad altre nazioni.

L’informatizzazione di massa e il computer alla portata di tutti hanno cambiato notevolmente le cose, non solo in questo campo. Oggi sono disponibili congegni crittografici terribilmente robusti per pochi Euro e versioni di software in open source altrettanto affidabili.

Il fatto che siano open source non diminuisce la loro efficacia, anzi, secondo un assioma della crittografia, detto principio di Kerckhoffs, il miglior sistema possibile non deve avere segreti nel funzionamento, perché una volta scoperto il segreto il sistema crittografico diventa del tutto inutile per chiunque in un solo colpo. Un buon sistema deve la sua forza ad un segreto individuale, differenziato e conosciuto solo dal singolo utente: se viene violato, solo affari e documenti di quell’utente sono in pericolo, tutti gli altri sono al sicuro. Immaginandolo come una serratura, se la sua costruzione prevede un componente segreto è sufficiente esaminarne un campione: una volta capito il funzionamento si ha accesso a tutte le abitazioni protette da quel modello. Se invece la serratura non ha componenti segreti, colui che voglia introdursi in una abitazione deve entrare in possesso delle chiavi di quell’esemplare, che non funzioneranno su nessun altro.

Traducendo in termini di uso comune in crittografia, il segreto deve risiedere non nella procedura crittografica, ma in qualcosa che sceglie il proprietario dei dati da proteggere e che conosce solo lui. Esattamente come le chiavi di casa, che sono in possesso solo del proprietario legittimo, pur usando serrature di uso comune il cui funzionamento è noto.

Proprio per esplicitare questa caratteristica di segreto personale in possesso del solo proprietario, questi dati segreti usati in crittografia vengono chiamati appunto chiavi.

Per meglio capire la differenza, il cifrario che Cesare usava per le comunicazioni con i suoi generali prevedeva che ogni lettera dell’alfabeto fosse sostituita con la lettera che la seguiva a tre posizioni di distanza: la “A” diventava “D”, la “B” diventava “E” e così via. Una volta capito il meccanismo, anche se Cesare avesse cambiato il segreto, in questo caso il numero di posizioni di distanza fra le lettere dell’alfabeto originale e le corrispondenti nell’alfabeto del messaggio segreto, era piuttosto facile e veloce trovare la nuova chiave, anche andando a tentativi. La cifratura di Cesare è in effetti un sistema crittografico debolissimo.

Di contro, gli Alleati riuscirono a mettere le mani sui piani di costruzione di Enigma prima dell’inizio della guerra, ma non ne ricavarono alcun beneficio. Il meccanismo di cifratura era piuttosto sofisticato: la macchina usava tre dischi di codifica, scelti fra cinque, la cui posizione iniziale poteva essere cambiata a piacere, e un pannello a spinotti, che permetteva di scambiare la posizione delle lettere a coppie. Pur avendo un esemplare originale di Enigma occorreva sapere quali dischi erano usati, la loro posizione iniziale e la configurazione degli spinotti: senza questi dati, costituenti la chiave, era praticamente impossibile decifrare il messaggio.

Gli Alleati riuscirono a far breccia in Enigma per vari motivi, inizialmente nessuno legato a come era costruito, ma piuttosto perché venne usato male: per esempio, venivano cifrati anche i bollettini meteorologici, trasmessi metodicamente sempre alla stessa ora e dalla stessa stazione. Sapendo il probabile contenuto del messaggio si riusciva a risalire alla posizione dei dischi e degli spinotti. Solo quando questa possibilità venne meno, si lavorò per trovare un punto debole nel sistema crittografico, scoperto solo grazie all’intervento di una squadra di matematici di prim’ordine e di nientemeno che Alan Turing, il padre della moderna Scienza dell’Informazione. Ma nonostante questa scoperta, occorreva tutte le volte scoprire la chiave, la posizione dei dischi e degli spinotti, tanto era robusto il sistema.

La storia di Enigma è da prendere a monito: nessun sistema è inviolabile, o almeno non lo resta a lungo. Se poi viene usato male, anche il sistema più sicuro diventa inutile.

Esistono molti sistemi di crittografia ma, per quello che ci interessa in questo momento, li possiamo dividere fondamentalmente in due categorie: simmetrici ed asimmetrici. I sistemi simmetrici usano la stessa chiave per cifrare e decifrare, mentre i sistemi asimmetrici usano chiavi differenti, non intercambiabili.

Enigma è un sistema simmetrico, perché la chiave per cifrare e decifrare è la stessa. Da questa caratteristica nasce il problema della cosiddetta distribuzione delle chiavi, cioè che mittente e destinatario del messaggio devono prima accordarsi sulla chiave segreta, comunicarsela in qualche modo. È una falla abbastanza grave, e costituì uno dei punti deboli nell’uso di Enigma. I sistemi simmetrici sono come una serratura: la stessa chiave apre e chiude.

Nei sistemi asimmetrici si usano due differenti chiavi, una segreta ed una pubblica, e la chiave segreta non viene mai divulgata né trasmessa ad alcuno ma rimane sempre e solo in possesso del proprietario. La cifratura asimmetrica funziona come un particolare tipo di lucchetto, la chiave pubblica, la cui costruzione non permetta di risalire alla chiave che lo apre, la chiave privata, di cui soltanto io ho un esemplare. Di questi lucchetti ne distribuisco a centinaia, aperti, ai miei amici. Quando uno di loro deve comunicarmi qualcosa, mette il messaggio in una scatola, la chiude con uno dei miei lucchetti e me la manda. Solo io potrò aprire il lucchetto e accedere al contenuto della scatola.

Rimane il problema che chiunque può prendere uno dei miei lucchetti e spedirmi un messaggio a nome di un altro, quindi non posso sapere se il mittente è proprio chi dice di essere. Inoltre non sempre la sola cifratura mette al riparo da modifiche al messaggio, per motivi che vedremo meglio.

Anche in questo caso la crittografia asimmetrica viene in aiuto, senza aggiungere altri componenti. Il sistema di cifratura ha la particolarità che può essere invertito, ossia si può usare la chiave privata per cifrare e quella pubblica per decifrare. Può sembrare inutile cifrare un messaggio che tutti possono decifrare a piacere con la chiave pubblica, ma ricordando che si possono decifrare con la chiave pubblica solo i messaggi che ho cifrato con la mia chiave privata, che possiedo soltanto io, automaticamente ho generato un processo di firma verificabile, dato che solo io posso aver cifrato il messaggio in questo modo. Ecco risolto anche il problema della autenticità del mittente, e quindi il non ripudio.

La firma digitale sarebbe molto scomoda da utilizzare se fosse obbligatorio cifrare tutto il messaggio, dato che per leggerlo sarei comunque costretto a decifrarlo. Per questo motivo si usa una scorciatoia che rende il messaggio leggibile a tutti, e solo chi ne ha necessità può verificare l’autenticità della mia firma. Il metodo usato coinvolge un concetto chiamato hash, in parole povere una sequenza di numeri generata a partire dal messaggio che ha queste caratteristiche uniche:

Le funzioni di hash sono molto veloci, e con documenti di grandi dimensioni sono molto più rapide di una cifratura, per cui hanno tutte le caratteristiche che servono per una firma digitale. Una semplice funzione di hash può essere la somma di tutti i caratteri del messaggio in codice ASCII: da questo numero che risulta è impossibile risalire al messaggio, e la grandezza dell’hash è limitata. Per comodità e sicurezza, le funzioni realmente utilizzate restituiscono un numero di lunghezza fissa, piuttosto grande: ad esempio SHA1 usa numeri da 160 bit mentre MD5 ne usa da 128 bit.

La procedura è la seguente: prendo il documento o il messaggio che voglio firmare, ne calcolo l’hash con una funzione nota, e applico una cifratura al solo hash con la mia chiave privata. Poi spedisco il documento e l’hash cifrato, che rappresenta la mia firma. Posso spedire le due parti anche separatamente, non ha importanza. Chi riceve il documento lo può leggere senza problemi, dato non è crittografato, e se vuole verificare che io sia il mittente effettivo, calcola l’hash del documento allo stesso modo in cui l’ho calcolato io, poi decifra la firma con la mia chiave pubblica, e ottiene l’hash calcolato da me: se i due hash sono identici il documento è senza dubbio inviato da me.

Inoltre, dato che l’hash è strettamente collegato al contenuto del messaggio firmato, una qualsiasi modifica viene immediatamente segnalata dalla non corrispondenza dell’hash originale e quello del messaggio ricevuto: risolto anche il problema dell’integrità del messaggio.

Permettetemi una breve digressione di carattere semiserio. Quando di parla di crittografia e di comunicazione sicura, rimane sempre difficile spiegare come interagiscono le persone coinvolte, per cui si fa riferimento a dei nomi per identificare anche mnemonicamente i personaggi. I più noti sono Alice e Bob, con Alice che vuole comunicare con Bob. Eve rappresenta qualcuno che può spiare la comunicazione, ma non modificarla, la spiona appunto, mentre Trudy è quella che può alterare i messaggi in transito, oltre a spiarli. Mallory è invece in grado di portare attacchi attivi, quindi non deve attendere che Alice mandi un messaggio a Bob, ma ne crea di nuovi, riutilizza quelli vecchi, altera i dati sui server, operando insomma come man in the middle. Il livello di sofisticazione degli attacchi è crescente, e la corrispondente contromisura di difesa diventa più complessa, andando da Eve a Trudy, a Mallory.

Immaginiamo allora il malefico trio che complotta per ingannarmi, in presenza di una cifratura asimmetrica e di firma digitale:

Si può aumentare in modo sostanziale la sicurezza delle nostre comunicazioni, oltre a mettere un serio ostacolo a chi volesse spiare e modificare la nostra posta elettronica, come le simpatiche Eve e Trudy.

Una possibilità per Mallory, dei tre il più esperto e pericoloso, potrebbe essere quella di portare un attacco molto sofisticato, “inquinando” la mia chiave pubblica, sostituendola con una generata da lui, ma che sembri appartenere a me. Chi voglia spedirmi un messaggio privato, prenderebbe la chiave contraffatta, cifrerebbe il messaggio per me, che verrebbe intercettato da Mallory, decifrato con la sua chiave privata, letto, cifrato di nuovo con la mia chiave pubblica vera e rispeditomi. In questo caso non avrei nessun indizio che il messaggio è stato letto strada facendo, ma come potete intuire per Mallory sarebbe un lavoraccio. Dovrebbe compromettere almeno un server di posta elettronica, e sperare che nessuno si accorga che ci sono in giro chiavi contraffatte che non mi appartengono. Come vedremo nel seguito, il lavoro diventa improbo, se non impossibile, se chi usa le chiavi le controlla attentamente prima di impiegarle.

Vediamo molto rapidamente i metodi usati per decifrare un codice senza avere la chiave segreta. Questo ramo della crittografia, imparentato molto strettamente con la statistica e l’alta matematica, viene chiamato crittoanalisi.

Per decifrare il codice di Cesare occorrono al massimo 26 tentativi, considerando anche le lettere “j”, “k”, “w”, “x” e “y”. Questo metodo di decifrazione viene chiamato brute force, con la pura forza: si tentano tutte le chiavi fino a scoprire quella che trasforma il messaggio in codice in un testo di senso compiuto. È un sistema molto valido quando le possibili chiavi sono relativamente poche. Con il cifrario di Cesare la chiavi sono solo 26, quindi è il metodo più economico.

Se invece si usa un alfabeto totalmente casuale, in cui ogni lettera è sostituita da un’altra a caso, il numero di chiavi diventa molto più alto, pari al fattoriale di 26, circa 400 milioni di miliardi di miliardi. Questo sistema di cifratura viene chiamato a sostituzione monoalfabetica, per il fatto che l’alfabeto viene sostituito da un altro, unico per tutta la lunghezza del messaggio.

Provando mille chiavi al secondo occorrerebbero in media 6 miliardi di miliardi di anni per trovare quella giusta. Detto così sembra un codice inviolabile, ma possiede un punto debole notevole: ogni lettera dell’alfabeto è sostituita sempre dalla stessa, per cui analizzando la frequenza delle lettere usate diventa molto più facile scoprire quale lettera sostituisce quella nel messaggio in chiaro. In tutte le lingue ogni lettera dell’alfabeto viene usata più o meno spesso, per esempio in italiano le lettere “a”, “e”, “i” sono usate molto più spesso di altre, mentre la lettera “q” è molto poco usata. Inoltre ci sono alcune regole per cui ad esempio la lettera “h” compare dentro una parola solo se è preceduta dalle lettere “c” o “g”. Questo sistema viene chiamato analisi delle frequenze, e permette di decifrare un codice di questo tipo in brevissimo tempo, dell’ordine dei minuti.

I moderni codici di cifratura sono enormemente più complessi, e richiedono calcoli matematici sofisticati. Ma non sono del tutto inviolabili: ogni codice ha il suo punto debole, che non è detto sia tale da rendere possibile la decifrazione, ma può permettere di confondere un messaggio al punto tale da renderlo illeggibile. Questo problema affligge i codici detti block cypher, che per cifrare un messaggio lo dividono in blocchi di lunghezza predefinita. In questo caso diventa possibile scambiare o manipolare i singoli blocchi in modo tale da rendere il messaggio privo di senso una volta decifrato.

Altro sistema di attacco è quello detto del chosen cleartext, in cui si assume che il testo da decifrare contenga una parola nota, e si tentano varie chiavi di cifratura fino ad ottenere una sequenza di caratteri identica ad una presente nel messaggio da decifrare: in questo modo si scopre la chiave segreta e si può decifrare l’intero messaggio. Questo è il modo in cui gli Alleati, cercando parole note all’interno dei bollettini meteo tedeschi, cifrati con Enigma, decifravano i messaggi. Questa debolezza affligge molti sistemi di cifratura simmetrica, anche se i moderni algoritmi sono immuni da questo problema.

Oggi molti dei sistemi utilizzati non soffrono di questi problemi, e nel progettare algoritmi di cifratura si pone molta attenzione ad evitare queste vulnerabilità. La vita del decifratore si è fatta molto difficile: i codici segreti non sono più quelli di una volta…​

La risposta non è semplice, contrariamente a quanto si crede. Gli elementi che rendono sicuro un modello di firma digitale e di crittografia non sono solo algoritmi e matematica, ma una parte sostanziale la fa il software e l’immancabile fattore umano.

Posso avere l’algoritmo di cifratura matematicamente inviolabile, ma se la persona che lo usa non capisce ad esempio che la chiave privata di un metodo asimmetrico è più importante delle chiavi di casa, la bontà dell’algoritmo è del tutto inutile.

Dal punto di vista tecnologico e matematico, i moderni algoritmi di crittografia si basano tutti sulla impossibilità per chiunque di avere le risorse di calcolo necessarie a decifrare un solo messaggio. Uno degli algoritmi si basa sulla difficoltà della scomposizione in fattori primi, applicata a numeri molto grandi, tipicamente centinaia di cifre decimali: la chiave privata è costituita da due numeri primi differenti molto grandi, mentre la chiave pubblica è il prodotto di questi due numeri, un numero ancora più grande. Tutta la robustezza del sistema si basa sul fatto che il tempo necessario per ricavare i due numeri primi dalla chiave pubblica, pur avendo a disposizione tutti i computer del pianeta, è di migliaia di volte l’età dell’universo. E questo per una sola chiave.

Unica possibilità per chiunque volesse violare un messaggio cifrato con questo algoritmo sarebbero i tanto temuti computer quantici, per cui esistono già algoritmi teorici in grado di trovare in pochissimo tempo la scomposizione in fattori dei numeri di seicento e più cifre usati in alcuni sistemi crittografici. Per ora, a parte applicazioni dimostrative, simili computer sono ancora lontani, e comunque esistono già alcuni algoritmi di cifratura resistenti anche all’attacco dei computer quantici, come ad esempio il metodo di firma di Lamport.

Per la firma digitale la robustezza si basa anche sulla relativa difficoltà di individuare due differenti testi che restituiscano lo stesso hash e che abbiano un senso compiuto. È certamente possibile trovare, con un bel po’ di pazienza e di potenza di calcolo, due sequenze di caratteri in grado di generare lo stesso hash, ma la difficoltà vera è far sì che i messaggi abbiano senso compiuto e il contenuto voluto. Per cui, nonostante le recenti notizie allarmistiche di “rottura” di alcuni algoritmi di hash, la firma digitale può essere ancora considerata relativamente sicura.

Al di là di queste considerazioni più o meno filosofiche, la sicurezza può essere facilmente compromessa in modi molto più semplici. Per poter funzionare, tutti i software crittografici hanno bisogno di memorizzare da qualche parte i dati necessari, come ad esempio la chiave privata. Per accedervi viene richiesta una password, per evitare che qualcuno, dal nostro computer, possa spedire messaggi spacciandosi a tutti gli effetti per noi. Uno dei punti deboli è proprio questa password. Se qualcuno riesce a mettere le mani sui file dove il nostro programma di crittografia memorizza i dati, ha la possibilità di sfruttare una scorciatoia notevole: invece di cercare di rompere la nostra chiave privata, impresa che come abbiamo visto è al momento impossibile per chiunque, si può concentrare sulla password che abbiamo scelto per proteggerla. Tanto per rendere l’idea, se scegliamo una password di sei caratteri alfabetici a caso ed il tizio ha a disposizione un normale PC, potrebbe trovare la password in meno di quattro giorni, con tanti saluti alla nostra identità e riservatezza digitali. Oppure il sistema più semplice potrebbe essere di inserire un keylogger nel nostro computer e conoscere la password in pochi minuti, se il nostro sistema di crittografia non viene usato correttamente, e solo su computer sicuri. Ma fermiamoci qui, dato che questo porta la discussione fuori dal tema.

I sistemi di firma basati su smartcard non soffrono dello stesso problema, ma ne hanno altri: il punto di forza è che la chiave privata non esce mai dalla smartcard, e che quello che transita è l’hash, che viene inviato alla smartcard e ritorna indietro cifrato con la chiave privata. Se però il computer fosse compromesso da qualcuno che al momento della firma sostituisca senza troppe difficoltà l’hash del mio documento con l’hash del suo, firmerei il suo documento invece del mio, senza accorgermene.

In definitiva, il problema comune a tutti i sistemi di firma è che non sappiamo con certezza cosa stiamo firmando. Ma stiamo veramente facendo le pulci, come si suol dire…​

Esiste una smartcard progettata per funzionare secondo le specifiche di OpenPGP, standard su cui si basa GnuPG. Maggiori dettagli si trovano sul sito del produttore: www.g10code.de. L’uso di questa smartcard può aumentare il livello di sicurezza del nostro sistema di firma e crittografia, ma si può rendere comunque difficile la vita ad un eventuale Mallory con alcuni semplici accorgimenti che vedremo nel seguito, anche senza usare particolari dispositivi.

La firma digitale è un modo per attestare l’origine di un messaggio o un documento in formato elettronico, in un certo senso è anche una attestazione della nostra identità. Quindi il problema successivo è: chi certifica che quella chiave pubblica è proprio la mia? E che io sono proprio chi dico di essere?

Non è un problema banale, perché se non è chiaro come viene associata la chiave pubblica alla mia persona, non è possibile fare affidamento su tutto il sistema. Questo è il vero punto debole di tutti i sistemi di firma digitale, anche perché è il momento in cui il fattore umano pesa in modo determinante.

Si arriva quindi al concetto di modello di certificazione, cioè il metodo con cui viene verificata l’identità del proprietario e certificata, appunto, l’associazione con la sua chiave pubblica. L’organizzazione del sistema di certificazione viene spesso indicato con l’acronimo PKI (Public Key Infrastructure), che si fa carico sia della distribuzione delle chiavi pubbliche, che di fornire la prova di appartenenza delle chiavi stesse. Al momento ne esistono di due tipi, usati e conosciuti:

La principale differenza è che nel primo caso una sola entità certifica identità e associazione fra chiave e possessore, mentre nel secondo questa certificazione è distribuita fra i partecipanti all’infrastruttura, e nessuno ha a priori più autorità di altri.

Come è normale, ci si domanda se i due modelli siano equivalenti, ed in quali casi. Come è facile immaginare, le discussioni in merito sono tante e piuttosto accese. Tanto per dare una idea, la legge italiana equipara un documento elettronico firmato digitalmente con il modello ad Autorità di Certificazione ad un contratto scritto e firmato, mentre non assegna a priori alcun valore alle firme digitali create con il modello della Rete di Fiducia, che comunque non possono essere rifiutate a priori in sede di giudizio, ma a discrezione del giudice possono essere ritenute attendibili. Comunque in nessun caso (e mi sento di dire, in tutta franchezza, per fortuna) la firma digitale può avere il valore di un documento autenticato di fronte ad un notaio, sempre per la legge italiana. Maggiori dettagli li possiamo trovare sul sito Interlex, che si occupa di tematiche legali in relazione alle tecnologie dell’informazione.

Non che il modello della Autorità di Certificazione sia invulnerabile. Dal punto di vista puramente concettuale, è molto più semplice ingannare una entità singola che ingannarne molte indipendenti, per cui, andando a buon senso, il meccanismo della rete della fiducia è più difficile da indurre in errore, dato che l’identità di una persona, come vedremo, viene controllata più volte, da persone diverse, in occasioni differenti.

Inoltre c’è una vulnerabilità non trascurabile nel metodo di rilascio dei certificati di firma. Basta presentarsi allo sportello di una delle organizzazioni autorizzate per avere un certificato con smartcard, presentando un documento di identità. Se si pensa che il numero di documenti contraffatti in circolazione è piuttosto consistente, e che molti di essi sono indistinguibili da un documento valido, se non analizzandoli con tecniche piuttosto sofisticate, è facile capire come un impiegato di sportello possa essere ingannato da un siffatto documento, anche qui con tanti saluti alla “certificazione”. Se poi pensiamo che dal lato dell’Autorità, in un unico punto, sono memorizzati tutti i dati di associazione fra certificati di firma e identità, mentre nel modello a Web of Trust i dati sono distribuiti, il cerchio si chiude: chi volesse alterare l’associazione fra una chiave pubblica ed una identità reale avrebbe vita infinitamente più facile con un solo bersaglio da attaccare, l’Autorità, mentre con la Rete della Fiducia dovrebbe alterare un numero imprecisato di archivi, nei computer di tutti quelli in cui è memorizzata la chiave pubblica da alterare. Il motivo sarà evidente nel seguito.

Tralascio del tutto considerazioni sul trattamento dei dati personali di identificazione in modo centralizzato da parte di un unico organismo…​

Termino qui questa parte introduttiva e teorica. Spero sia stata sufficiente a spiegare i concetti di base che verranno poi richiamati nel seguito. Alcuni concetti sono stati volutamente soltanto introdotti, dato che verranno ampiamente trattati nei capitoli seguenti.

Se siamo interessati ai dettagli sul funzionamento della crittografia moderna, agli aspetti matematici, ed alla crittoanalisi, in Rete il materiale è abbondante, partendo dal livello introduttivo fino alla trattazione matematica completa.

Il principale strumento è GnuPG, che possiamo scaricare in versioni pronte per l’uso con quasi tutti i sistemi operativi più diffusi.

Esclusa l’installazione, che per Windows verrà trattata separatamente, nel seguito tutte le operazioni fatte usando direttamente GnuPG dalla shell di Linux potranno essere applicate in maniera assolutamente identica usando il prompt dei comandi di Windows, la sintassi e le procedure sono le stesse. Potrebbe succedere che in Windows l’eseguibile di GnuPG non sia nel percorso di ricerca delle applicazioni specificato in PATH: basta aggiungerlo, o altrimenti ci sposteremo dentro la directory in cui è installato il file eseguibile gpg.exe ed eseguiremo tutte le operazioni da lì.

La chiave privata, i dati di convalida della firma nostra e delle firme dei nostri amici e conoscenti sono conservati su normali file, in forma cifrata. Questi file sono uno dei punti deboli di tutto il nostro sistema crittografico, il segreto supremo, e occorre che siano protetti al massimo contro il pericolo che qualcuno possa trafugarli. Inoltre, dato che per definizione la chiave privata è unica e non ripetibile, la sua eventuale perdita è irrecuperabile. A parte queste considerazioni, i file in cui GnuPG memorizza tutti i dati, anche se cifrati, sono normali file che possono essere copiati e sottoposti a backup, e GnuPG non trova differenze a lavorare sugli originali o su copie. Non solo, i file che usa la versione Windows sono identici e compatibili con la versione Linux e viceversa, quindi chi come me usa entrambi i sistemi operativi può usare gli stessi file. Detto questo dobbiamo far coincidere esigenze contrastanti:

Queste due esigenze, in aperto contrasto fra loro, possono però essere parzialmente conciliate con qualche accorgimento, che inoltre rende più fruibile il sistema di firma e crittografia.

Dopo aver provato diverse alternative, quella che trovo più comoda, anche per chi usa più computer, o anche per chi usa il notebook, è un disco USB removibile, che sia un normale hard disk o un disco flash a stato solido, la familiare “chiavetta USB”, molto di moda in questo periodo. Dato che il volume di dati è veramente minimo, nel mio caso sono meno di cento kilobyte, l’ideale potrebbe essere un piccolo pen drive USB da 128Mbyte, da portare insieme alle chiavi di casa o dell’auto.

Si istruisce GnuPG ad usare il percorso giusto per i file di lavoro, in questo caso il disco removibile. Se ci dimentichiamo di connetterlo al momento della firma, GnuPG avvisa soltanto che non riesce a trovare quello che serve, senza fare danni. Poi, periodicamente, se ne fa un backup su un supporto a piacere, cifrando i file con un algoritmo simmetrico, con le procedure che vedremo più avanti, confondendoli insieme a migliaia di altri e con un nome insospettabile, in modo che se il supporto dovesse essere smarrito o sottratto, chiunque lo ritrovi non sia attirato dal contenuto. In questo modo sul computer non è conservato nulla, e se mai dovesse essere smarrito o trafugato, dentro non ci sarebbero dati così importanti.

L’elemento critico diviene il disco USB, che va protetto da eventuali letture o manomissioni da parte di estranei. Se vogliamo esagerare, potremmo usare strumenti come la cifratura del filesystem, permessa sia dalle ultime versioni di Windows che da Linux. In questo modo abbiamo una doppia sicurezza: la password di accesso alla chiave privata di GnuPG, e la password per accedere al filesystem cifrato, che ovviamente saranno differenti. La password del filesystem potrebbe anche essere memorizzata nel computer, per evitare di doverla digitare ad ogni connessione del disco USB, e dare comunque un po’ di sicurezza in più, perché chi volesse trafugare la nostra chiave privata deve avere due cose: il computer e il disco USB. Chi trafugasse il solo disco dovrebbe affrontare due diverse decifrazioni, una del filesystem ed una dei file di GnuPG, mentre chi trafugasse il computer avrebbe la password del filesystem ma non avrebbe il filesystem. Ma siamo veramente paranoici…​

Per quanto riguarda la frequenza dei backup, può essere ridotta se si usa un keyserver in Internet, perché le modifiche alle firme sono registrate anche sul server. Però se si perde il database della fiducia, cioè il database dove viene memorizzato il grado di fiducia che abbiamo assegnato ad ogni persona con cui abbiamo avuto contatti, il tempo necessario per ricostruirlo non è trascurabile, per motivi che saranno evidenti nel seguito, per cui un backup ad ogni modifica è caldamente consigliato.

Quindi, ricapitolando:

Usando un disco USB removibile, possiamo affermare di rispettare uno dei paradigmi della sicurezza, obbedendo ai requisiti per la cosiddetta autenticazione forte, che impone che siano usati almeno due differenti metodi per identificarmi, ad esempio scelti fra i seguenti:

Per poter usare le mie chiavi crittografiche ho bisogno di una cosa che ho (il disco USB) e di una che so (la password di accesso di GnuPG), ed ecco soddisfatte le premesse.

La parte GnuPG è disponibile su tutte le principali distribuzioni Linux e spesso viene già installata, per verificare mediante firma digitale tutti gli aggiornamenti che vengono rilasciati per il sistema operativo e le applicazioni. Quindi chi usa Linux può passare immediatamente alla generazione delle chiavi, previa verifica dell’installazione di GnuPG. Se per qualche motivo non fosse installato, basta far riferimento alla documentazione della nostra distribuzione, dove troveremo come reperire ed installare i programmi aggiuntivi necessari.

Unica cosa da fare, se vogliamo utilizzare un disco USB, è di creare un link simbolico nella home directory che punti al mount point del disco USB. La logica è questa: GnuPG usa una directory con nome .gnupg nella home dell’utente in cui memorizza i file di lavoro. Dato che vogliamo mettere questi file sul disco USB, che supponiamo venga montato in automatico in /media/usb, basta creare un link simbolico nella nostra home con il nome .gnupg che punti ad una directory scelta da noi dentro il disco USB, ad esempio /media/usb/.miafirma. Occorrono due semplici operazioni, la prima è la creazione della directory nel disco USB, con il comando:

seguito dalla creazione del link simbolico per GnuPG con il seguente comando, lanciato dalla vostra home directory:

Esiste un altro metodo per indicare a GnuPG dove sono i file delle chiavi: modificare il file di configurazione. Ha però uno svantaggio: se dimentichiamo di inserire il disco USB vengono creati da zero nuovi file, vuoti, senza restituire un errore. Se invece si usa il link simbolico, GnuPG tenta di creare i file vuoti se non viene infilato il disco USB, ma non ci riesce per via della presenza del link stesso e ci avverte con un errore, che possiamo prendere come un “ricordati di inserire il disco”.

Le versione che ho usato in Linux è quella presente nella distribuzione Fedora Core 6, per la precisione la 1.4.7 e successive. Per quello che riguarda questa guida non c’è alcuna differenza fra questa versione ed altre precedenti o successive presenti nelle varie distribuzioni Linux, al netto di piccole differenze nei messaggi o in alcune opzioni usate raramente.

Come abbiamo detto, GnuPG può essere usato allo stesso modo sia da Windows che da Linux, tramite la riga di comando. Teniamo conto però di due aspetti: l’uso dal riga di comando in Windows è piuttosto scomodo; non tutti sono a loro agio con la riga di comando.

Per fortuna esistono programmi di interfaccia verso GnuPG che, oltre a fare da tramite per le operazioni di gestione delle chiavi, rendono immensamente più semplici le operazioni di routine, come cifrare un messaggio o verificare una firma.

Dal sito di GnuPG è possibile avere una idea delle varie possibilità, ma a mio avviso la migliore è GPG4Win, che permette in un colpo solo di installare:

Di questi, non installeremo GPGol (il plugin per OutLook, vedremo che WinPT ci permette di fare le stesse cose), GPA (ridondante rispetto a WinPT, oltre ad avere quanche funzione in meno), GPGee che funziona solo con diritti amministrativi (inoltre lo sviluppo è abbandonato dal 2005) e Sylpheed-claws (semplicemente perché obbliga a cambiare totalmente il programma per la posta elettronica). Il pacchetto è disponibile in due versioni, di cui prenderemo quella lite, che semplicemente non include i manuali, solo in tedesco.

Nel seguito vedremo come si usano i programmi che abbiamo scelto, ora ci dedicheremo all’installazione, che richiede i diritti di amministrazione.

Al lancio dell’installazione, se non abbiamo diritti da amministratore, subito dopo la presentazione (Figura 1) e la licenza (Figura 2), viene appunto mostrato un messaggio (Figura 3) che avverte di questo vincolo e termina il programma senza fare altro. Se invece stiamo usando un utente con i diritti giusti, l’installazione prosegue senza mostrare il messaggio.

Al momento in cui scrivo le versioni disponibili sono quelle nelle immagini. Certamente, nel frattempo saranno disponibili nuove versioni, ma fondamentalmente avranno le stesse funzioni di base, almeno quelle utilizzate in questa guida e le differenze non influiscono in nessuna delle procedure indicate nel seguito.

L’installazione prosegue con la scelta dei componenti da installare (Figura 4). Come abbiamo già accennato, installeremo solo alcuni componenti.

Arriva il momento di scegliere la posizione dei programmi (Figura 5), dove mettere icone di avvio (Figura 6) e la voce nel menù Start (Figura 7): possiamo lasciare i valori predefiniti.

Appena confermata la posizione nel menù Start parte l’installazione (Figura 8), che termina qualche minuto dopo (Figura 9)

L’ultimo pannello conferma il successo dell’installazione (Figura 10).

Per ora non lanciamo nulla, anche se possiamo verificare la presenza nel menù Start dei programmi appena installati.

Verificato che tutto sia in ordine, possiamo passare ad una delle fasi cruciali, con la generazione dei nostri segreti più preziosi: le chiavi crittografiche.

Per prima cosa verifichiamo se nel nostro computer è installato GnuPG, e come sia configurato. Queste informazioni si ottengono digitando il comando che segue:

I dati che ci interessano sono la Home, che ci dice dove saranno memorizzati i file delle chiavi pubbliche e private, qui indicata quella predefinita in Linux, in Windows sarà quella che indicheremo al momento di generare le chiavi, come vedremo più avanti; l’elenco degli algoritmi conosciuti sia per la cifratura a chiave pubblica che per quella simmetrica, elencati sotto la voce Cifrari; degni di nota anche gli algoritmi di hash e quelli di compressione. Questo elenco è utile se si prevede di scambiare dati con altre persone che hanno versioni di software differenti: dobbiamo avere gli stessi algoritmi, altrimenti uno dei due non riuscirà a fare qualcuna delle operazioni tipiche. Se per esempio si usa un algoritmo di hash che ha solo uno dei due, l’altro non potrà verificare la firma.

Riporto la procedura in versione Linux, usata dal nostro amico Pinco, ma, come spiegato sopra, le operazioni eseguite da Caio in Windows con il prompt dei comandi sono assolutamente identiche:

Ci vengono date parecchie informazioni, tutte importanti, come è buona abitudine quando si usa un software per applicazioni che coinvolgono la sicurezza:

Scegliamo a piacere, ricordando però che optare per la generazione di una coppia di chiavi soltanto per la firma implica non poter cifrare, a meno di generare successivamente una coppia di chiavi aggiuntiva, quindi tanto vale generarla subito.

Supponendo di scegliere quello che ci propone GnuPG, la coppia di chiavi DSA per la firma sarà di 1024 bit, mentre per la coppia di chiavi per la cifratura di dati e messaggi viene richiesta la dimensione preferita. Il valore proposto è adeguato, per cui risponderemo solo con un Invio:

La domanda successiva riguarda la scadenza della chiave. Possiamo specificare un tempo limite o lasciare il valore proposto, che rende le chiavi senza scadenza. Il valore si può cambiare successivamente, e comunque di solito si sceglie di non dare nessuna scadenza, visto che la nostra firma non dovrebbe cambiare nel tempo. Oppure, in casi particolari, possiamo scegliere un valore di comodo in previsione del tempo massimo per cui useremo queste chiavi.

Supponiamo di scegliere trenta anni, un valore adeguato visto anche che probabilmente per quell’epoca le firme digitali saranno tutt’altra cosa.

La scadenza si può cambiare anche successivamente, se non è quella voluta. Viene adesso il momento di associare le chiavi generate alla nostra identità ed al nostro indirizzo di posta elettronica.

È importante che i dati siano corretti e che l’indirizzo di e-mail sia quello che verrà utilizzato con questa chiave, perché, pur potendo modificarli in seguito, se la nostra chiave pubblica viene divulgata con dati errati, il problema è che ci vorrà tempo e pazienza prima che i dati corretti vengano recepiti da tutti quelli che ci conoscono. Molti programmi di posta elettronica selezionano automaticamente la chiave da usare in funzione del destinatario, cioè dell’indirizzo a cui viene inviato il messaggio. Se qui ne dichiariamo uno e poi abitualmente ne usiamo un altro, pur potendolo aggiungere all’elenco delle nostre identità, se chi ci vuole mandare un messaggio cifrato usa un programma di posta che integra le funzioni di GnuPG deve indicare ogni volta quale chiave usare, perché il programma userà la prima identità, quella con cui viene generata la prima coppia di chiavi. Se è tutto in ordine possiamo rispondere:

Siamo ad uno dei momenti cruciali. La scelta della password di accesso alle chiavi private.

Tanto per dare un’idea delle “idee geniali” nella scelta di una password il numero più usato è ‘1’ messo in coda, come pure il simbolo più usato è il punto, per separare il numero dal resto: password.1 è l’esempio classico, ben conosciuto da chiunque voglia scoprire una password, che compie i primi tentativi proprio in questa direzione. L’importanza di questa password è anche sottolineata dal fatto che GnuPG la chiama passphrase, proprio per indicare che una singola parola è troppo debole.

Questa è l’ultima domanda, da qui in avanti il processo si compie in automatico, fino alla generazione di tutti i dati necessari. Durante il processo di generazione delle chiavi viene stampata a video una sequenza di caratteri per mostrare l’andamento. Se abbiamo scelto di generare sia una coppia di chiavi di firma che una coppia per la cifratura, come avviene se prendiamo le scelte predefinite, i messaggi mostrati sotto vengono ripetuti due volte, una per ogni coppia di chiavi:

Il tempo di generazione delle chiavi è fortemente dipendente sia dalla lunghezza della chiave che dalla velocità del vostro computer. Da notare che viene usato estensivamente il generatore di numeri casuali, ed è il motivo per cui ogni chiave è unica, e non è possibile generarne un’altra identica. Al termine viene fatto il riepilogo delle chiavi generate e della scadenza:

Gli elementi in questi ultimi messaggi sono caratteristici e li rivedremo spesso durante l’uso di GnuPG.

Se non vogliamo utilizzare il prompt dei comandi, possiamo sfruttare la comoda interfaccia messa a disposizione da WinPT. Valgono comunque tutte le considerazioni e gli avvertimenti dati fino ad ora (cfr. sez. 2.5).

Verifichiamo di aver inserito il supporto su cui memorizzare i dati di GnuPG, come spiegato sopra, prima di avviare WinPT. Per comodità supporremo di usare un disco USB flash, la ben nota chiavetta USB o pen drive. Alla partenza riceviamo un avviso (Figura 11) che appare quando non esistono ancora i file delle chiavi pubbliche o private. Se invece abbiamo dimenticato di inserire il pen drive USB dove sono i file di GnuPG appare un avviso differente (Figura 12).

In questo momento ci troviamo nella prima situazione, non avendo ancora generato le nostre chiavi. Se invece siamo nella seconda situazione, dopo aver risposto No, compariranno una serie di messaggi di errore e di richieste di indicare la directory con i file delle chiavi: basta annullare tutte le operazioni per uscire da WinPT, ed una volta inserito il disco nella presa USB basta riavviare il programma.

Dobbiamo generare le chiavi, ma le impostazioni predefinite di WinPT posizioneranno i file delle chiavi crittografiche in una directory sotto la gerarchia Documenti, nel disco principale del computer. Dato che invece vogliamo posizionare i file sul pen drive USB, ignoriamo questo pannello, senza chiuderlo, e facciamo clic col tasto destro sulla piccola icona a forma di chiave vicino l’orologio in basso a destra del desktop. Dal menù che appare (Figura 13) scegliamo Preferences  GPG per accedere al pannello di configurazione di GnuPG (Figura 14).

Mettiamo il segno di spunta nella casella Overwrite default settings, sbloccando le due caselle di testo in alto. Nella prima dobbiamo indicare quale sia la posizione dei file, cioè la lettera del disco corrispondente al pen drive. Basta premere il pulsante di fianco alla casella GnuPG home directory, ed otteniamo il classico pannello di scelta (Figura 15) da cui selezioneremo il drive.

In questo esempio (Figura 16) abbiamo selezionato il drive E:\, e le chiavi saranno memorizzate nella radice del disco. Possiamo anche creare una directory e piazzarci dentro le chiavi, se vogliamo condividere lo spazio con altri dati.

Confermate le scelte con il pulsante OK, possiamo tornare al pannello rimasto aperto (Figura 11), nel quale premiamo il pulsante Cancel, poi lanciamo di nuovo WinPT dal menù Start, per fare in modo che tenga conto delle scelte fatte. Questa volta al pannello controlleremo che sia selezionata la voce Generate a GnuPG key pair, poi premiamo OK.

Nel pannello che appare (Figura 17) dobbiamo mettere il nostro nome, cognome e indirizzo di posta elettronica che vogliamo siano associati alle chiavi crittografiche. I dati qui inseriti devono essere quelli veri, che utilizzeremo effettivamente con la nostra identità digitale, per intenderci, quelli scritti nei nostri documenti di identità (a parte l’indirizzo di posta elettronica).

Qui facciamo le veci del nostro amico Pinco, che mette il suo nome e il suo indirizzo di posta elettronica, entrambi inventati.

Alla pressione del tasto OK, ci viene chiesta la password di protezione delle chiavi crittografiche (Figura 18), e se ne scegliamo una troppo corta veniamo avvisati (Figura 19). Di seguito ci viene chiesta di nuovo la stessa password (Figura 20), per impedire che errori di digitazione rendano poi inaccessibili le chiavi crittografiche.

Con WinPT non viene chiesto di assegnare una scadenza alle chiavi, né il commento da associarvi. Le chiavi sono create senza scadenza, e in ogni caso vedremo che questi parametri sono modificabili in qualsiasi momento, dopo la generazione delle chiavi, sia usando la riga di comando che WinPT.

Appena inserita la seconda volta la password parte la generazione delle chiavi (Figura 21), che termina dopo qualche tempo (Figura 22).

Al passo successivo viene proposto di fare un backup delle chiavi appena generate (Figura 23), cosa caldamente consigliata.

Vengono salvati due file, quelli realmente importanti al momento: il file delle chiavi pubbliche (Figura 24) e quello delle chiavi private (Figura 25).

Chiaramente questi due file sono preziosissimi, specialmente quello delle chiavi private, e non vanno lasciati incustoditi. Al più presto ne faremo un backup da qualche parte, tenendone solo due copie: quella di lavoro, sul pen drive, e quella di riserva, ad esempio masterizzata in un CD-R, da riporre in un luogo sicuro. Ne avremo bisogno solo in caso di perdita dei dati dal pen drive.

Avviando di nuovo WinPT, non otterremo ora nessuna finestra, ma una icona nella barra delle applicazioni (Figura 26): cliccandovi col tasto destro del mouse si ottiene un menù con le funzioni principali (Figura 13). Quella che ci interessa al momento è la prima, Key Manager. Scegliendola si ottiene l’interfaccia per la gestione delle chiavi (Figura 27).

C’è elencata una sola chiave, dato che il nostro amico Pinco non ha ancora avuto contatti con il mondo esterno.

Purtroppo è successo: qualcuno ha rubato il disco USB con dentro le nostre chiavi crittografiche. In teoria è solo questione di tempo prima che violi la password ed inizi a firmare mail e documenti a nome nostro. Cosa fare?

Anche questa possibilità è prevista. Al momento della generazione delle chiavi, o anche successivamente, è possibile creare un certificato di revoca, una chiave speciale che consente di revocare la validità della nostra chiave segreta principale dalla data in cui viene usato il certificato. Questo significa che tutti i messaggi ed i documenti firmati prima della data di revoca continuano a valere, ma ogni messaggio o documento firmato dopo la revoca non ha più alcun valore.

Dato che la chiave di cifratura è convalidata dalla firma digitale apposta su di essa al momento della generazione, anche il valore di tutte le sotto-chiavi di cifratura decade nello stesso momento in cui la chiave di firma viene revocata.

Il comando da impartire è il seguente:

L’opzione --output è seguita da un nome di file dove GnuPG deve scrivere il certificato di revoca, in questo caso revoca.asc. In tutti i comandi che non coinvolgono operazioni su file, GnuPG manda il prodotto delle operazioni a video, cosa poco utile in situazioni come questa, in cui i dati generati hanno un impiego particolare.

Per indicare a quale chiave ci si riferisce si può usare il nome o il cognome, l’indirizzo di posta elettronica o meglio l’ID della chiave, il numero esadecimale a otto cifre che la identifica.

Occorre indicare la chiave, dato che ci troviamo di fronte ad una azione potenzialmente distruttiva. Possiamo generare certificati di revoca solo per le chiavi che ci appartengono, cioè di cui abbiamo sia la parte pubblica che privata.

I motivi elencati non sono messi a caso, ognuno è legato ad un diverso comportamento di GnuPG quando trova una chiave revocata. Nel nostro caso, la scelta sarà la numero 1: utilizzeremo questo certificato solo in seguito ad un furto di dati che coinvolga i file di GnuPG:

Si può scrivere quello che si vuole, anche nulla:

Supponendo che tutto sia a posto diamo risposta affermativa:

Al solito occorre la password, cosa abbastanza ovvia, altrimenti chiunque può generare un certificato di revoca dal nostro computer e annullare la validità delle nostre chiavi:

Quest’ultimo messaggio nella versione inglese diventa:

Il Mallory citato qui è proprio quello di cui abbiamo parlato nella parte teorica (sez. 1.5), il personaggio che agisce come man in the middle.

Ci troviamo ora un file dal nome revoca.asc il cui contenuto è simile a questo:

Non è una buona idea conservarlo sullo stesso supporto dove teniamo i file della nostra chiavi crittografiche: se il disco USB viene rubato, in un colpo solo il ladro ottiene sia la chiave privata, e una volta scoperta la password di protezione inizia a firmare a nostro nome messaggi e documenti, sia il certificato di revoca, che non è cifrato ed è immediatamente utilizzabile per essere inviato ad un keyserver, annullando la validità di tutte le firme da quel momento in poi, anche se sono del legittimo proprietario.

Se in più, nonostante gli avvertimenti, non abbiamo copia di backup dei file dei keychain, non avremo neanche la possibilità di generarne uno nuovo. La nostre chiavi saranno perdute per sempre, o peggio in mano ad altri: non avremo altra possibilità che avvertire di persona tutti gli amici e conoscenti che le nostre chiavi non sono più valide.

Caio può comodamente usare l’interfaccia messa a disposizione da WinPT, chiamando il Key manager (Figura 27), e dopo aver selezionato la sua chiave, dal menù Key scegliere la voce Revoke Cert (Figura 28).

Compare un pannello in cui sono presenti tutti gli elementi già visti: la ragione per la revoca, un commento opzionale, la password ed il file in cui vogliamo salvare il certificato (Figura 29).

Terminata la generazione, pressoché istantanea, un messaggio ci avverte di conservare con cura il certificato appena creato (Figura 30).

Come possiamo vedere non è nulla di terribilmente complicato, una volta capiti i motivi. Ora abbiamo una contromisura anche per rispondere a questa situazione, remota ma sempre possibile.

In questo momento il public keychain è vuoto, o meglio, contiene soltanto la nostra chiave pubblica. Perché sia utilizzabile, occorre per prima cosa distribuirla, in modo che sia disponibile a tutti. Per questo motivo esistono i public keyserver su Internet, che mettono a disposizione tutte le chiavi pubbliche che gli utenti hanno volontariamente distribuito. Due esempi sono pgp.mit.edu e subkeys.pgp.net, ma ne esistono innumerevoli altri, ed in WinPT ne sono già elencati alcuni (Figura 31). La buona notizia è che non è necessario usare tutti lo stesso keyserver, dato che esiste un protocollo di scambio delle chiavi fra server: inviando la vostra ad un singolo keyserver sarà distribuita a tutti gli altri, nel giro di qualche giorno. Purtroppo esistono più reti indipendenti di keyserver, ed in qualche caso ci si imbatte in servizi di verifica delle chiavi che hanno poco di affidabile: tutte le chiavi inviate a quel server vengono controfirmate dal server stesso, e per scaricare le chiavi di chiunque bisogna registrarsi, fornendo la propria chiave pubblica. Questa procedura crea l’illusione di un sistema di verifica dell’autenticità delle chiavi, che in realtà poco o nulla aggiunge al sistema di sicurezza, mentre in realtà è più dannoso, a mio modesto parere, per la falsa sensazione di prendere chiavi “verificate” che invece di certo non hanno nulla, men che meno nel senso inteso dal Web of Trust. Ma sarà tutto più chiaro dopo che avremo parlato di come si fa lo scambio di chiavi pubbliche.

Per pubblicare le nostre chiavi si può procedere in vari modi, anche in funzione del keyserver e delle preferenze personali. Si può esportare in un file e inviarla a quei server che mettono a disposizione un’interfaccia web per questo tipo di operazioni, o impartire istruzioni a GnuPG o WinPT per l’invio diretto. Per esportarla in un file, i nostri due amici Pinco e Caio possono operare allo stesso modo con il prompt dei comandi:

che genera il file chiave.asc con dentro tutto il contenuto della chiave pubblica indicata, in questo caso quella di Pinco, pronto per essere inviato al keyserver.

Se invece intendiamo lasciare il lavoro a GnuPG ed il server lo permette, possiamo inviare la chiave direttamente con il seguente comando:

ed il server risponde confermando che la chiave è stata ricevuta.

Con WinPT l’operazione è ancora più semplice: dopo aver lanciato il Key Manager si seleziona la chiave che si vuole esportare e si clicca col tasto destro del mouse. Dal menu che compare si seleziona Send to Keyserver e si sceglie uno di quelli proposti. Viene chiesta conferma (Figura 32), ed a operazione avvenuta viene mostrato un avviso (Figura 33). Non occorre altro, al più dopo qualche giorno possiamo verificate su un differente keyserver l’esistenza della nostra chiave, a conferma che è liberamente disponibile e distribuita sulla rete dei keyserver.

Nelle figure ho usato la mia chiave GnuPG, per non inviare roba inutile ai server.

Usando invece la riga di comando, per evitare di specificare tutte le volte il keyserver possiamo modificare il file di configurazione di GnuPG. Il file si trova nella stessa directory dei file generati al momento di creazione delle chiavi, ad esempio nel pen drive, che GnuPG mostra con il comando visto precedentemente nella voce Home, e si chiama gpg.conf. Per selezionare il keyserver preferito, basta aprire il file con un normale text editor (Vim, Emacs, Nano, Joe, GEdit in Linux, Blocco Note in Windows) e controllare se esiste già una riga come questa:

senza il carattere ‘#’ davanti. Se esiste, possiamo lasciarla invariata oppure sostituire il keyserver con quello preferito. In generale, tutte le opzioni di GnuPG usate sulla riga di comando possono essere rese permanenti inserendole in questo file, basta togliere i due trattini davanti all’opzione. Ad esempio, sopra si è usata l’opzione -⁠-⁠armor che indica a GnuPG di creare sempre firme, chiavi e certificati in caratteri ASCII stampabili. Per renderla permanente basta aggiungere in un punto qualsiasi del file di configurazione la riga:

e dal quel momento in poi non sarà più necessario specificare l’opzione -⁠-⁠armor in ogni comando. Se momentaneamente si vuole annullare l’effetto di queste modifiche al file di configurazione, basta specificare l’opzione voluta sulla riga di comando: per indicare un diverso keyserver lo indichiamo esplicitamente, nel modo solito, e quello indicato nel file di configurazione verrà ignorato. Analogamente, per annullare l’effetto della riga armor basterà specificare l’opzione -⁠-⁠no⁠-⁠armor, che ha l’effetto opposto di -⁠-⁠armor. In breve, tutte le opzioni date sulla riga di comando hanno la precedenza rispetto a quelle nel file di configurazione.

Nessuno vieta di pubblicare le chiavi su un keyserver, e poi mandare una mail agli amici per indicare quale sia. Se però abbiamo compreso l’importanza della chiave pubblica e della corretta associazione col proprietario, sappiamo che in questo modo nessuno sarà certo che quella sia proprio la mia chiave. L’unico modo è di incontrare di persona quelli a cui voglio distribuirla e indicarla con certezza, fornendo un foglio su cui sono stampati questi dati:

Ottenere questi dati è piuttosto semplice, usando il comando:

Oppure sempre tramite il Key Manager di WinPT, selezionare la chiave e dal menù Key scegliere Properties, ottenendo un pannello con tutti i dati richiesti (Figura 34).

Il passo successivo è incontrare la persona con cui si vuole fare lo scambio di chiavi per consegnargli il foglio con tutti i dati. Lo scopo è proprio quello di assicurare che la nostra chiave sia proprio quella e non altra, e che siamo proprio chi dichiariamo di essere. Secondo il Manuale della riservatezza di GnuPG è necessario portare con sé ben due documenti di identità, di tipo non facilmente falsificabile, e mostrarli alla persona con cui facciamo lo scambio. Potrebbe sembrare paranoia, ma se abbiamo compreso la filosofia di questo modello di certificazione, capiremo che è fondamentale assicurasi dell’identità di chi abbiamo di fronte, e nel contempo provare la nostra. Se è una persona che conosciamo bene, come ad esempio nostro fratello, possiamo limitarci ad un solo documento di identità. Sto scherzando, ma è assolutamente importante capire che è questa verifica dell’identità che rende forte la Rete della Fiducia.

Non è assolutamente necessario, ed è anzi inutile, portare un foglio con la nostra chiave pubblica stampata per intero, o un supporto con dentro i dati. Può essere presa da un keyserver, in modo molto più sicuro ed al riparo da errori di trascrizione, e chi la preleva la verifica confrontando i dati della chiave con quelli forniti al momento dello scambio, soprattutto con il fingerprint, che non è ripetibile, e neppure falsificabile. Ancor meno serve un computer, che addirittura viene sconsigliato, per quanto possa sembrare strano. La ragione è molto semplice: se qualcuno modifica la propria versione di GnuPG (che, lo ricordiamo, essendo un open source rende disponibile a tutti il proprio sorgente) potrebbe alterare le chiavi al momento dello scambio, e portare attacchi nello stile di Mallory (l’uomo nel mezzo, ricordate?). Inoltre è molto più pratico fare senza, anche perché non tutti hanno un computer portatile e per estrarre la chiave pubblica dai file della nostra chiave dovremmo copiarli su un computer non nostro, con tutti i rischi che ne conseguono.

Uno degli elementi costitutivi della Rete della Fiducia è anche la nostra reputazione come “verificatori”. Se siamo superficiali nella verifica dell’identità di quelli con cui scambiamo le chiavi, la nostra firma di convalida varrà poco o nulla, con conseguenze che saranno chiare fra poco. Ricordiamo che nella verifica delle firme conta quanta fiducia hanno gli altri nella nostra comprensione del meccanismo e nella nostra accuratezza.

Il nostro amico Pinco è tornato a casa, con il foglietto che gli ha dato Caio. Si è accertato che Caio fosse proprio chi diceva di essere, quindi è ragionevolmente sicuro che sia tutto in ordine. Accende il computer e preleva la chiave pubblica di Caio dal keyserver usando l’ID della chiave:

Potrebbe anche aver ricevuto la chiave pubblica con una mail, in allegato, da Caio stesso. In questo caso il comando sarebbe leggermente differente, supponendo che la chiave sia nel file chiave.asc:

ma il risultato sarebbe lo stesso. Arriva il momento cruciale, in cui Pinco deve verificare la autenticità della chiave, per cui con il comando che segue fa calcolare a GnuPG il fingerprint della chiave importata:

Confronta attentamente il fingerprint ottenuto con quello che ha sul foglietto, e verifica che siano identici. Ora è ragionevolmente sicuro che nessuno si sia messo in mezzo e che ha importato proprio la chiave di Caio: può procedere con la controfirma. Senza questa operazione, se Pinco riceve una mail firmata da Caio, pur sapendo che è proprio la sua firma, riceve da GnuPG un messaggio simile a questo:

Che dice che la firma è corretta, ma nessuno ci assicura che quella chiave appartenga proprio a Caio, cosa che in effetti non è vera, dato che Pinco lo ha verificato di persona. Da notare che il fingerprint corrisponde esattamente alla chiave pubblica di Caio.

Per rendere definitiva la verifica, e rendere pubblico il fatto che conosce Caio ed attestare che quella è proprio la sua chiave pubblica, deve fare due distinte operazioni:

La prima operazione si esegue con il comando:

Dopo la digitazione della password, la procedura termina senza ulteriori messaggi. Se la chiave crittografica che andiamo a firmare ha una scadenza, ci viene chiesto se vogliamo che la nostra firma di convalida scada nello stesso momento, cosa che normalmente non pone problemi. L’unica possibilità che mi viene in mente è se il proprietario di quella chiave decida successivamente di prorogare la durata della chiave, ed allora la nostra firma di convalida scadrebbe prima. Possiamo anche lasciare che la nostra non abbia termine di validità. Verifichiamo che la firma sia andata a buon fine:

Le prime righe compaiono quando si hanno modifiche tali da chiedere il ricalcolo della catena di certificazioni attraverso la Rete della Fiducia, per esempio proprio alla convalida di una chiave con la propria firma crittografica. Vedremo meglio cosa significa più avanti, per ora accettiamola così. La riga che inizia con pub e quella seguente mostrano i dati della chiave pubblica di Caio, mentre le due righe successive che iniziano per sig mostrano rispettivamente la firma che GnuPG appone alle chiavi appena generate, una sorta di autoconvalida, e la firma che Pinco ha appena generato. Il “3” subito a fianco della prima firma appartiene proprio a questa convalida che esegue GnuPG autofirmando le chiavi al momento della generazione, ed assegnando il massimo valore possibile di validità alla firma stessa. La seconda firma appartiene invece a Pinco, ed è quella appena apposta. Non riporta nessun numero perché GnuPG, se non diversamente specificato, associa alla firma un no comment, cioè niente di speciale da dire su questa firma. Se per qualche motivo intendiamo assegnare un livello di certificazione alla chiave che andiamo a convalidare, dobbiamo aggiungere l’opzione -⁠-⁠ask⁠-⁠cert⁠-⁠level alla riga di comando. In questo caso la sequenza di firma mostra una domanda in più relativa al livello di certificazione:

In effetti questo passo è abbastanza inutile: se non si è in grado di certificare una chiave, cioè non siamo in grado di affermare che quella chiave appartiene al proprietario dichiarato, e che il proprietario dichiarato è proprio chi dice di essere, è praticamente inutile firmare. Per questo motivo GnuPG considera valide le firma di convalida che hanno associato un no comment. E per la stessa ragione non è necessario specificare un livello di certificazione: o siamo sicuri, e firmiamo, o non lo siamo, ed allora non firmiamo e basta, senza mezzi termini.

Anche Caio farà la stessa operazione, usando il Key Manager di WinPT. Seleziona il menù Keyserver ed ottiene il pannello di interrogazione (Figura 31). Nella casella in basso digita l’indirizzo di posta di Pinco o l’ID della sua chiave pubblica, seleziona uno dei server dalla lista sopra e preme il pulsante Search. Normalmente riceverà un solo risultato. Alcuni server permettono ricerche più generiche, ad esempio col solo cognome, nel qual caso riceverà più risultati e dovrà selezionare quello voluto, verificando l’indirizzo di posta elettronica o l’ID della chiave.

Il risultato che vedete è a seguito della ricerca della mia chiave pubblica, dato che ho evitato di inquinare i keyserver con chiavi di personaggi inventati. Alcuni keyserver hanno una interfaccia web che permette ricerche più complete, per esempio anche solo con nome o cognome.

Premendo il pulsante Receive la chiave scelta viene scaricata ed aggiunta al nostro keyring e viene notificato il buon esito dell’operazione.

Ci sono anche altre possibilità. Una è fare l’importazione da file della chiave, se ad esempio viene inviata per posta elettronica, o scaricata da un sito web. Molti keyserver mettono a disposizione anche una interfaccia web per cercare e scaricare chiavi pubbliche, per cui alla fine avremo dei file da importare, selezionando dal menù Key la voce Import. Compare il consueto pannello di selezione file, punteremo quello che contiene la chiave e la importiamo. Al solito viene mostrato prima un pannello di conferma (Figura 36) da cui controllare che sia proprio la chiave voluta, poi un riepilogo delle chiavi importate (Figura 37).

Ora anche Caio ha la chiave pubblica di Pinco e vuole firmarla per convalida. Seleziona la chiave pubblica di Pinco e dal menù Key sceglie Sign. Gli viene proposto un pannello (Figura 38) che contiene gli stessi elementi visti per Pinco, unica differenza è che occorre togliere la spunta alla casella Sign local only prima di firmare, altrimenti la firma varrà solo per Caio. Dopo aver inserito la password viene notificato l’esito dell’operazione.

La casella Ask for certification level ha la funzione equivalente all’opzione -⁠-⁠ask⁠-⁠cert⁠-⁠level di GnuPG, e come possiamo notare non viene richiesto il livello di certificazione, uniformando il comportamento alla versione a riga di comando di GnuPG.

Nell’elenco delle chiavi possiamo notare che che sotto la colonna Validity dove c’era None, ora c’è Full.

Rimane un ultimo passo: notificare ai keyserver, e quindi a tutti quelli che conoscono sia Pinco che Caio, che sono state controfirmate le rispettive chiavi. Quindi Pinco con Linux eseguirà questo comando:

mentre Caio farà un clic col tasto destro del mouse sulla chiave di Pinco e dal menù selezionarà Send to Keyserver, scegliendone uno dalla lista che compare.

Dopo qualche tempo, variabile da pochi secondi, se usano lo stesso keyserver, a qualche giorno, se ne usano due differenti, i nostri amici potranno aggiornare le proprie chiavi pubbliche scaricando le nuove firme. Per Pinco basta dare il comando:

Mentre per Caio è sufficiente il solito clic col tasto destro del mouse sulla propria chiave e la scelta della voce Refresh from Keyserver. Come conferma avrà al termine il pannello di riepilogo simile a quello già visto (Figura 37) con stavolta indicata una nuova firma.

Tutta questa procedura è possibile anche senza keyserver, esportando le chiavi pubbliche firmate su file e scambiandoli:

Caio eseguirà la stessa procedura, importando la chiave pubblica di Pinco, firmandola e rimandandola indietro. Senza keyserver è poi compito loro inviare le chiavi aggiornate a tutti i loro amici e conoscenti.

Rimane una ultima parte da esaminare, la cui importanza è fondamentale. Pensare di incontrare tutti di persona per fare lo scambio di chiavi è impensabile, e renderebbe assolutamente inutile il meccanismo. Come abbiamo detto precedentemente (sez. 1.9), ci si avvale della verifica indiretta di firme provenienti da persone di cui non abbiamo la chiave pubblica direttamente firmata da noi, ossia persone che non conosciamo. La parte che ancora non abbiamo visto riguarda proprio il livello di fiducia che riponiamo nelle persone che abbiamo incontrato e con le quali abbiamo scambiato le chiavi pubbliche.

Per spiegare il meccanismo dovremo chiedere la collaborazione di un altro nostro amico, che chiameremo Tizio. Tizio conosce Pinco, ma non conosce Caio. Inoltre si fida poco di Pinco perché lo giudica un po’ superficiale, ed è convinto che firmi le chiavi pubbliche altrui con troppa facilità.

Supporremo che Tizio sia un utente Linux, e la sua chiave pubblica abbia questi parametri di identificazione:

Tizio ha la chiave pubblica di Pinco, debitamente verificata a controfirmata. Per completare la procedura manca solo che definisca quanto si fida di Pinco. Non è una fiducia generica, ma sulla comprensione che secondo Tizio Pinco ha del meccanismo del Web of Trust e sulla diligenza che applica alla verifica delle chiavi e delle identità altrui prima di controfirmarle.

Fidarsi, nell’ambito della firma digitale con questo modello di certificazione, significa che si accetta una firma di convalida fatta da un nostro amico come se fosse nostra, cioè come se avessimo incontrato di persona l’altro e verificato noi stessi la chiave e l’identità.

Per tornare ai nostri amici, se Tizio si fida completamente di Pinco, per lui una firma convalidata da Pinco è attendibile a tutti gli effetti. Se controlla la chiave di Caio, che non conosce di persona, e vede che è verificata da Pinco, può accettarla per buona. Se invece ritiene Pinco poco o per nulla affidabile, la presenza di una firma di Pinco sulla chiave pubblica di Caio per lui non ha nessun valore.

Vediamo i possibili casi, seguendo Tizio mentre assegna il livello di fiducia a Pinco. La procedura per cambiare il livello di fiducia sulla persona è la seguente:

Questo modo di chiamare GnuPG mette a disposizione una interfaccia molto semplice ed efficace che permette praticamente tutte le operazioni sulle chiavi sia pubbliche che private. Per sapere quali comandi sono accettati basta dare uno sguardo alla pagina del manuale, oppure usare il comando help, che mostra un breve elenco con le operazioni possibili.

Prima diamo un breve sguardo alle informazioni presentate. Nella prima riga vi sono i dati della chiave pubblica di Pinco, con subito sotto i valori di fiducia (trust), al momento sconosciuto visto che Tizio non ha ancora deciso quanto si fida di Pinco, e validità (validity), cioè se la chiave è ancora utilizzabile. Se ad esempio fosse scaduta ci sarebbe scritto expired, o revoked nel caso di chiave revocata tramite certificato. Nell’ultima riga fra parentesi quadre c’è il livello di certificazione dato da Tizio alla chiave di Pinco, in questo caso full, piena, dato che si sono incontrati di persona e Tizio ha verificato l’identità di Pinco.

Tizio assegna il livello di fiducia a Pinco con il comando trust:

Vengono ripetuti i dati di riepilogo, e le scelte possibili (il fingerprint è quello delle chiavi pubbliche, non l’impronta dei polpastrelli). La domanda è chiara: quanto ti fidi?

Per capire quanto è privata, il livello di fiducia assegnato ad ogni chiave è salvato nel file separato trustdb.gpg il cui contenuto è accessibile solo a noi e nessun altro.

Se si assegna fiducia piena ad una persona, tutte le chiavi pubbliche da lui firmate saranno attendibili per noi, come se avessimo eseguito personalmente la procedura di firma e convalida. Quando Tizio assegna fiducia piena a Pinco, la firma di convalida di Pinco sulla chiave di Caio sarà attendibile per Tizio esattamente come se fosse una sua firma. Ecco perché la fiducia deve essere intesa in senso molto stretto, e concessa con molta attenzione.

Questo concetto può essere ripetuto a catena per Caio, per cui se un amico di Caio scrive a Tizio, e questo amico ha la sua chiave pubblica firmata da Caio stesso, Tizio può decidere di assegnare fiducia piena a Caio, e considerare attendibili le chiavi da lui controfirmate.

GnuPG possiede un gruppo di regole predefinite per stabilire la validità di una chiave pubblica in base al livello di fiducia assegnato ad ogni persona. Le regole sono configurabili a piacere, e quelle predefinite sono:

Cerco di spiegarmi meglio con un esempio: abbiamo la nostra catena di amici in cui Caio conosce Pinco, che conosce Tizio. Supponiamo che Tizio a sua volta abbia un amico che scrive un messaggio a Caio, quindi una catena a tre salti:

Perché Caio possa considerare attendibile la firma dell’amico di Tizio ogni anello della catena, ogni salto, deve essere certificato. Il primo anello, Caio-Pinco, è valido perché Caio ha incontrato Pinco, e quindi la chiave di Pinco per lui è valida. Il secondo anello, Pinco-Tizio, richiede che Caio assegni piena fiducia a Pinco, in seguito alla quale la chiave pubblica di Tizio, incontrato da Pinco, è per Caio attendibile. L’ultimo anello, Tizio-Amico di Tizio, provocherà da parte di GnuPG una segnalazione di non attendibile, perché Caio deve prima assegnare una fiducia a Tizio, anche se non lo ha mai incontrato di persona, per indicare al programma che si fida delle sue firme. Soltanto dopo che Caio avrà espresso un livello di fiducia su Tizio, il programma potrà calcolare se la firma dell’Amico di Tizio è attendibile o meno.

La fiducia che Caio concederà a Tizio non sarà automatica, ma Tizio dovrà in un certo senso conquistarsela, dimostrando con il suo comportamento di essere un “verificatore” attendibile. Nel mondo reale quasi mai succede che da un giorno all’altro ci scriva un perfetto sconosciuto con il quale è necessario scambiare documenti firmati. Succede invece che ci sia un rapporto di lavoro o uno scambio di informazioni particolarmente importanti, per cui dopo un po’ che le persone si conoscono nasce l’esigenza di certificare il mittente. Per comprendere a cosa equiparare la firma digitale, possiamo pensarla come appendere la carta d’identità al messaggio. Non sono molte le situazioni che necessitino questo livello di attenzione.

Tornando ai valori predefiniti indicati sopra, questi possono non incontrare il nostro favore, ma sono modificabili a piacere per incontrare le nostre esigenze di sicurezza. Anche queste modifiche sono assolutamente personali e private, e se decidiamo che una firma per noi non è attendibile, il nostro giudizio è definitivo e inappellabile. La chiave di comprensione è che deve essere attendibile per noi.

Se ad esempio stiamo intrattenendo corrispondenza per un delicato progetto di lavoro, potremmo decidere di ritenere attendibili le chiavi pubbliche solo fino al secondo livello, e richiedere almeno cinque firme con fiducia parziale per renderne una totalmente attendibile. Oppure scegliere di rifiutare tutte le firme con fiducia parziale, quale che sia il livello e il numero. Lo facciamo noi, nel nostro computer, sui messaggi indirizzati a noi.

Il sistema è molto flessibile e totalmente personalizzabile, per venire incontro a tutte le esigenze di sicurezza che si possano presentare nell’attività quotidiana. Sicuramente il concetto della validità a catena non è facile da digerire e richiede un po’ di pratica, ma non lasciamoci spaventare, è più difficile spiegarlo che applicarlo.

Torniamo al nostro amico Tizio che ha deciso di assegnare fiducia parziale a Pinco:

Ora la voce trust riporta marginal, indicando appunto che la sua fiducia di Tizio in Pinco è parziale.

Per rendere continua la sua catena di certificazione, Caio farà la stessa operazione nei confronti di tutti i componenti della catena stessa. Per assegnare il livello di fiducia con WinPT si richiama il Key Manager, si seleziona con un clic tasto destro del mouse la chiave desiderata e dal menù si seleziona Properties ottenendo il pannello corrispondente (Figura 39). In basso c’è la casella Ownertrust che dovrebbe contenere la parola unknown. Premendo Change e ottiene l’elenco delle scelte (Figura 40).

Supponiamo che Caio assegni a Pinco fiducia piena, selezionando I trust fully. Nel Key Manager ora c’è Full sotto la colonna Trust.

Perché la catena di certificazione, vista da Caio, sia funzionante, non è necessario che nessun altro nella catena assegni un livello di fiducia ai “vicini”: abbiamo visto che il livello di fiducia è un fatto privato. Quello che invece è necessario è che ognuno abbia apposto la firma di convalida della chiave pubblica del “vicino”, ossia lo abbia incontrato personalmente e verificato la sua identità.

Nella prossima sezione vedremo come si firmano e verificano i messaggi. Dopo aver familiarizzato un po’ con le procedure, simuleremo varie situazioni che coinvolgono i nostri amici, e certamente arriveremo a comprendere meglio il meccanismo.

Nella parte teorica abbiamo visto che una firma digitale è un hash, cifrato con la chiave privata, quindi una sequenza di pochi byte. Se il documento digitale che andiamo a firmare è un semplice file di testo puro, è possibile aggiungere la firma al messaggio stesso, in coda. Il problema sorge ad esempio con file di applicazioni che usano un loro formato specifico per memorizzare i documenti, come OpenOffice Writer™ o Microsoft Word™, il cui formato di salvataggio dei file non consente modifiche arbitrarie al file stesso, anche solo per inserire i pochi byte di una firma digitale.

Nasce quindi il concetto di detached signature, firma separata, che altri non è che un file di pochi byte che contiene la sola firma digitale. Questo file è strettamente associato al documento firmato, nel senso che un differente documento non possiederà la stessa firma.

Questo sistema permette di aggirare appunto situazioni, molto frequenti, in cui il documento digitale da firmare non prevede spazio e struttura interna per i sia pur pochi byte della firma digitale. Inoltre c’è il problema non indifferente che l’azione di firmare il documento modifica il documento stesso, per cui occorre identificare quale sia la firma e quale la parte firmata. Vediamo i due casi, la firma inglobata nel messaggio stesso, e la firma detached, applicata ad esempio a file generici.

Nel caso di un testo semplice, come può essere una e-mail, lo standard OpenPGP prevede tutto quello che serve, racchiudendo il testo del messaggio e la firma con intestazioni distinte. Potete verificarlo facilmente creando un messaggio di poche parole come questo:

salvandolo in un file dal nome messaggio.txt.

Per firmare il messaggio, mantenendolo leggibile, si usa questo comando:

Inserendo la password che sblocca la firma si ottiene un file in più dal nome messaggio.txt.asc che ha questo aspetto:

un tipo di messaggio che può capitare di vedere in giro per la Rete, per esempio nelle mailing list o sui newsgroup.

I campi “Version:” e “Comment:” possono cambiare, o essere assenti del tutto, dato che non rientrano fra i dati necessari. Chi riceve questo messaggio può verificarlo come segue:

Facciamo la parte di Trudy (cfr. sez. 1.5), e modifichiamo in una qualsiasi parte il messaggio. Dopo aver copiato il file messaggio.txt.asc in un altro file a piacere, per esempio falso.txt.asc, cambiamo all’interno la parola gpg con GPG nella seconda riga. Il risultato è questo:

Possiamo provare tutte le modifiche che ci vengono in mente, ma non c’è verso di avere un messaggio di firma valida, che si ottiene solo col messaggio originale. Se andiamo a toccare la parte della firma, va anche peggio:

Per non parlare di sostituire la firma originale con la firma di un altro messaggio a caso:

Notare che l’ID della firma non corrisponde, e non abbiamo la chiave pubblica relativa a quell’ID, indizio che non conosciamo chi ha generato quella firma. Se fosse qualcuno che conosciamo, e di cui abbiamo la chiave pubblica, il risultato sarebbe:

con il risultato di avere un messaggio che dice di provenire da Pinco, firmato da Mario, cosa già strana, per di più con una firma non valida. Insomma, molto poco credibile.

Caio si può anche avvalere di WinPT, e scrivere il messaggio come di consueto con il suo programma di posta preferito, ad esempio Outlook Express (Figura 41).

Appena completato il messaggio, Caio richiama il menù di WinPT nel solito modo, seleziona Current Window  Sign. Viene chiesta la password (Figura 42) e dopo pochi secondi il messaggio viene trasformato in modo simile a quanto visto nel funzionamento con il prompt dei comandi (Figura 43).

Passiamo dalla parte di Pinco che riceve il messaggio di Caio e vuole verificare la sua firma.

Se ha un programma di posta che lo prevede, verifica direttamente la validità della firma, altrimenti può salvare il messaggio su un file, ad esempio msg-da-caio.txt e verificarlo in questo modo:

ed avere la certezza che il messaggio viene proprio da Caio, perché ha la chiave pubblica di Caio controllata e firmata. Se non avesse la chiave pubblica di Caio otterrebbe invece un messaggio come questo:

Potrebbe scaricare la chiave pubblica con ID 596F0CF4 da un keyserver, ed otterrebbe allora il messaggio:

indicazione del fatto che non ha incontrato di persona chi ha fatto la firma, e non conosce nessuno di cui si fida che abbia verificato questa chiave.

Caio, nelle stesse situazioni otterrebbe gli avvisi mostrati sopra (Figura 44 e Figura 45) rispettivamente per l’assenza della chiave pubblica nel suo portachiavi e per la mancanza di firme fidate sulla chiave. Notare la differenza con il caso in cui la firma è verificata: sotto la colonna Trust c’è None invece di Full (cfr. più avanti, Figura 47) ed un avviso in testo grigio, poco visibile. Differentemente dalla versione a riga di comando, dove questa situazione è ben evidenziata, dalla interfaccia grafica passa un po’ inosservata.

Pinco vuole mandare a Caio un programma che ha fatto lui stesso. Vuole essere sicuro sia che il file arrivi integro, sia che alla ricezione il buon Caio non lo cestini pensando che sia il solito virus che si spedisce come allegato. Supponendo che il programma si chiami utile.exe, la prima operazione è di generare la firma:

dove le opzioni stanno a significare:

Al termine dell’esecuzione, molto rapida, avremo un file in più il cui contenuto sarà simile al seguente:

Pinco scrive il suo messaggio di posta per Caio, e allega sia il file del programma, utile.exe, che il file della firma, firma.asc.

Il buon Caio si vede arrivare il messaggio, e pur sapendo che Pinco è molto attento e non prende virus, si vuole cautelare e controlla se il file glielo manda proprio Pinco. Salva sul Desktop entrambi gli allegati del messaggio, poi dal menu di WinPT seleziona File Manager, ed esegue un drag&drop del file della firma dentro la finestra del File Manager (Figura 46). Può anche selezionare la voce Open…​ dal menù File, è la stessa cosa.

Dal menu File seleziona Verify, ed ottiene il pannello di scelta in cui indica a quale file si riferisce la firma, in questo caso utile.exe. Viene controllata la firma e il risultato è immediatamente mostrato: è firmato proprio da Pinco (Figura 47).

Se invece è Caio a voler spedire un file firmato, apre il File Manager di WinPT, trascina il file da firmare dentro la finestra, dal menu File seleziona Sign ed ottiene un pannello (Figura 48) su cui seleziona la chiave con cui firmare, sceglie Detached Signature e spunta Text Output. Dopo la solita richiesta di password, nella stessa directory del file da firmare ne viene creato un altro con aggiunta in coda l’estensione .asc, quindi se il file era utile.exe il nome del file della firma sarà utile.exe.asc, il cui contenuto sarà molto simile a quello generato da Pinco.

Pinco, per verificare la firma di Caio sul file, salverà gli allegati al messaggio da qualche parte, poi userà questo comando:

Ora possiedono entrambi un robusto sistema di verifica dell’identità, e possono farvi affidamento per lo scambio di messaggi e dati con la certezza di saperne sempre la provenienza.

Nonostante la robustezza e l’affidabilità di tutto il sistema di firma e verifica, usandolo in modo ingenuo o improprio si può facilmente e velocemente gettare al vento la propria sicurezza e riservatezza. Non c’è bisogno di perdere i file di GnuPG o mettere il proprio certificato di revoca in un circuito di scambio file, è sufficiente essere trascurati.

Supponiamo che il nostro Mallory (cfr. sez. 1.5), in vena di scherzi, trovi un messaggio di Caio ad un amico, debitamente firmato, il cui testo sia:

Il messaggio è di qualche mese prima, e non era originariamente diretto a Pinco. Incollando all’interno di un nuovo messaggio il testo compreso di firma, confeziona un falso in cui il mittente sembra proprio Caio, cosa piuttosto facile con molti servizi di posta elettronica, e lo spedisce a Pinco.

Questi, alla ricezione del messaggio, verifica la firma è effettivamente corretta. Rimane in ufficio fino alle 17, anche se normalmente termina il lavoro alle 15. Arrivate le 18 comincia a innervosirsi, e chiama Caio, che cade dalle nuvole.

Ci sono due ingenuità, una commessa da Caio, ed una commessa da Pinco:

Comprendo che può sembrare paranoico, e che l’esempio è in effetti un po’ esagerato. Chiaramente il contenuto reale dei messaggi firmati sarà di solito molto più articolato e certamente più specifico, ma un errore di questo tipo può essere commesso se ad esempio il documento vero è in allegato, firmato, e il messaggio di posta che lo trasporta, ugualmente firmato, è generico e sbrigativo come quello mostrato, cosa non infrequente.

Uno dei punti deboli del sistema è la certificazione della data e ora della generazione della firma. La data è cifrata insieme all’hash, e quindi non è falsificabile: anche supponendo che Mallory sia così in gamba da riuscire a separare l’hash dalla data e metterne una differente, non ha la chiave privata di Caio, e non può cifrare la sequenza hash+data per generare una nuova firma di Caio (cfr. sez. 1.4).

Però il riferimento temporale viene preso dal computer in cui viene eseguita l’operazione, e può succedere che sia errata, oltre al fatto che non è certificata da nessuno, a parte il firmatario. Mi sono capitati computer che per motivi vari perdevano le impostazioni dell’orologio interno, e ci si trovava facilmente in un altro mese o addirittura anno. Questa eventualità è purtroppo impossibile, al momento attuale, da verificare a posteriori su una firma, tranne casi estremi, ad esempio se la firma sia precedente alla data di generazione delle chiavi, per via dell’orologio che è saltato a qualche anno prima al momento della firma.

L’inconveniente della data può essere risolto in molti modi, per esempio tenendo sincronizzato l’orologio del proprio computer con uno dei tanti servizi di NTP (Network Time Protocol) gratuiti disponibili in rete. Linux include in praticamente tutte le distribuzioni il servizio ntpd che si occupa proprio di questo, come pure le ultime versioni di Windows.

Un’altra possibilità è l’uso della cifratura per impedire anche solo di leggere il contenuto del messaggio nel caso venga intercettato, ma lo vedremo più avanti.

Quello su cui ci interessa concentrare l’attenzione è che un uso improprio o ingenuo può mandare in malora anche il sistema di sicurezza più sofisticato e robusto. Il fattore umano, cioè noi ed il nostro comportamento, sono sempre la principale fonte a cui attingono i vari Mallory in giro per il mondo per le loro malefatte.

Fino ad ora abbiamo considerato soltanto persone che si conoscono e si sono incontrate per scambiarsi le chiavi. I problemi sorgono quando due persone non si sono mai incontrate, e non hanno possibilità di incontrarsi.

Arriva il giorno in cui Caio scrive a Tizio. Non si conoscono, e Caio dice nel messaggio che il suo indirizzo di posta elettronica lo ha avuto da Pinco. Tizio chiama al telefono Pinco e gli chiede di Caio, che tipo è, e se c’è da fidarsi. Però non basta: il messaggio è stato firmato con una chiave che appartiene veramente a Caio?

Il messaggio è del tipo con firma all’interno, ed al controllo con GnuPG risulta:

per cui prende dal keyserver la chiave di Caio, nel modo consueto:

Ecco intanto il primo effetto del livello di fiducia che Tizio aveva assegnato a Pinco (sez. 3.4): dato che era parziale, all’aggiunta di una nuova chiave che risulta firmata da Pinco, GnuPG avvia una verifica attraverso il database della Rete della Fiducia ed al primo livello (depth: 0) c’è la chiave di Pinco, firmata direttamente da Tizio, la cui firma ha valore di trust pari ad ultimate, dato che è la sua stessa firma. Al secondo livello (depth: 1) c’è la chiave di Caio, firmata da Pinco, ma la firma di Pinco ha fiducia parziale che in questo caso determina la non affidabilità della chiave di Caio, come andiamo a vedere.

Controlliamo le firme sulla chiave pubblica di Caio con il comando:

che mostra la firma di Pinco, come ci aspettavamo, ma alla verifica della firma di Caio sul messaggio ecco cosa succede:

Il messaggio è chiaro: l’unica firma di convalida sulla chiave pubblica di Caio è di Pinco, di cui Tizio ha deciso di non fidarsi completamente, quindi non c’è possibilità: Tizio non può accertare che quel messaggio venga proprio da Caio.

Siamo al punto di partenza: pur sapendo che Pinco ha incontrato Caio e si sono scambiati e certificati le chiavi, Tizio ha deciso che non si fida delle certificazioni di Pinco.

Decide di rispondere comunque a Caio, che invece si fida delle certificazioni fatte da Pinco. Caio riceve il messaggio di Tizio e lo passa alla verifica, usando il File Manager di WinPT. Per scrupolo controlla se la chiave di Tizio è effettivamente firmata da Pinco: usando il Key Manager, fa un clic col tasto destro del mouse sulla firma di Tizio e seleziona List Signatures (Figura 49).

Effettivamente la firma c’è, e procede a verificare la provenienza del messaggio: seleziona tutto il testo del messaggio e lo inserisce nella Clipboard con la consueta combinazione di tasti Ctrl+C, dal menù di WinPT seleziona Clipboard  Decrypt/Verify. Il messaggio di risposta reca sotto la colonna Trust la parola Full (Figura 50). La firma è corretta e certificata per tramite della fiducia che Caio ripone in Pinco.

È umano che appena ottenuta la nostra firma nuova, appena sfornata, si firmi qualsiasi cosa, anche messaggi che nella realtà non verrebbe mai in mente di firmare. Vale la pena soffermarci un attimo sulla effettiva utilità di una firma e indicare alcuni casi in cui la firma digitale può essere estremamente utile:

Il campo è piuttosto circoscritto, e passata l’euforia iniziale l’uso della firma sarà automatico solo quando effettivamente necessario. Poi ovviamente nessuno vieta di firmare ogni nostro messaggio e documento, ma è una fatica inutile.

Se non intendiamo percorrere tutta la procedura di generazione e convalida delle chiavi, ma abbiamo necessità di scambiare dati e informazioni riservate con qualcuno, o di proteggere i nostri affari da occhi indiscreti, possiamo usare la crittografia simmetrica messa a disposizione da GnuPG. Ricordiamo che con simmetrica si indica l’uso di una singola chiave, identica sia per cifrare che decifrare. Lo svantaggio è che la chiave diventa preziosa dato che permette di accedere al contenuto, e quindi deve essere comunicata tramite canali sicuri. Il vantaggio è che per accedere al contenuto basta il solo GnuPG senza necessità di generare alcuna coppia di chiavi.

Per cifrare un messaggio o un file usando la crittografia simmetrica basta impartire il comando giusto, supponendo che il file si chiami documento.txt:

La passphrase è la chiave di cifratura. Viene chiesta due volte per sicurezza, ed alla fine della cifratura viene generato un file con lo stesso nome con aggiunta in fondo l’estensione .gpg, nel nostro caso documento.txt.gpg. Il file è in binario, nel senso che contiene caratteri non stampabili a schermo. Se per qualche motivo occorre l’output in ASCII stampabile, per esempio volendo includerlo in un messaggio invece di allegarlo, possiamo aggiungere l’opzione -⁠-⁠armor come di consueto. Ad esempio se il contenuto di documento.txt è il seguente:

dopo averlo cifrato con il comando:

avremo un file dal nome documento.txt.asc il cui contenuto sarà:

che puo' essere inserito in un messaggio di posta elettronica senza creare allegati.

Per decifrarlo, il processo è ancora più semplice, dato che GnuPG individua automaticamente il formato del messaggio, che sia ASCII armored o binario:

si inserisce la password e si ottiene il messaggio originale stampato a video:

i messaggi indicano che si è usato l’algoritmo CAST5, con una singola password, e che l’integrità del messaggio non è assicurata.

L’algoritmo di cifratura si può cambiare, scegliendolo fra quelli conosciuti da GnuPG. Ricordiamo che la lista si ottiene con il comando:

nella riga Cifrari, in inglese Cypher. Se cambiamo algoritmo, dobbiamo tener presente che non tutte le versioni di GnuPG hanno lo stesso elenco, per cui, prima di inviare il messaggio a qualcuno, controlleremo che possa decifrarlo.

Si può cifrare un messaggio più volte in sequenza, usando differenti password, altrimenti non ha senso. Chi lo riceve dovrebbe applicare le decifrazioni in sequenza inversa rispetto a chi lo invia. In questo caso era cifrato una sola volta.

Non trovando firme digitali, la sola cifratura non è sufficiente a garantire l’integrità del messaggio, e viene dato il messaggio di avvertimento corrispondente.

Se ci viene inviato un file generico, il cui contenuto non è direttamente leggibile, come ad esempio un programma, è più utile che il file venga decifrato e salvato direttamente col nome che aveva in origine, per cui il comando di decifrazione diventa:

e dopo aver digitato due volte la password:

ottenendo il file originale documento.txt.

Lavorando con WinPT le procedure sono molto simili a quelle viste per firmare i messaggi. Una volta scritto il messaggio con il nostro programma di posta preferito (Figura 51), selezioniamo tutto il testo, lo copiamo nella clipboard e dal menù di WinPT selezioniamo Clipboard  Symmetric.

Viene chiesta due volte la password, ed appena terminata l’operazione possiamo incollare il messaggio cifrato nella finestra del programma di posta, che appare con il testo cifrato in modalità ASCII armored (Figura 52).

Questa procedura con il passaggio nella clipboard ci assicura che il tutto funziona indipendentemente dal programma che andiamo ad usare per la posta elettronica, ed anche se utilizziamo il browser per gestire la posta attraverso una applicazione di webmail.

Se invece vogliamo cifrare un file qualsiasi, basta richiamare il File Manager di WinPT e selezionare il file da cifrare con un drag&drop o dal menù File  Open…​ (Figura 53). Poi dal menù File scegliere Symmetric, digitare due volte la password quando viene chiesta, ed il file viene immediatamente cifrato, ottenendo un altro file con lo stesso nome ed estensione .gpg (Figura 54).

Per decifrare un messaggio ricevuto direttamente dentro la finestra dell’applicazione, ad esempio in webmail, selezioniamo tutto il testo, lo inseriamo nella clipboard con la solita sequenza Ctrl+C, poi dal menù di WinPT prendiamo Clipboard  Decrypt/Verify, ed avremo il vostro messaggio in chiaro. Per visualizzarlo lo possiamo incollare dentro il Notepad, oppure usare il visualizzatore di Clipboard di WinPT, alla voce Clipboard  Edit.

Se invece dobbiamo decifrare un file, la procedura con il File Manager di WinPT è identica alla cifratura: si seleziona il file da decifrare, dal menù File si sceglie Decrypt e dopo la digitazione della password corretta si ottiene il file originale in chiaro.

Visto che vogliamo pensarle proprio tutte, ci mettiamo dalla parte di Eve, Trudy e Mallory, e vediamo come si possano sfruttare ingenuità ed errori per creare confusione.

Supponiamo, ovviamente, che non sappiano la password usata per la cifratura. Se Eve intercetta il messaggio, può solo tentare un attacco brute force, con tutte le password possibili. L’unica salvezza è nella bontà della password. Se si usa una parola di senso compiuto, anche in altra lingua, la chiave viene trovata in poco tempo, questione di minuti, ed è sufficiente un semplice calcolo per provarlo.

Un dizionario standard di una qualsiasi lingua comprende da un minimo di cinquantamila parole ad un massimo di circa centocinquantamila. Supponendo per comodità che una lingua media contenga centomila parole, e sommando le cinque lingue principali (inglese, francese, spagnolo, tedesco, italiano), si ottengono mezzo milione di parole. Un programma lento di solito può tentare mille parole al secondo, ed il tempo medio di rottura della password sarebbe di duecentocinquanta secondi, poco più di quattro minuti.

Se invece si usa una sequenza casuale di sei caratteri, comprendendo maiuscole, minuscole, numeri e simboli per un totale di 95 differenti caratteri, i tentativi teorici per trovare la password salgono a seicentonovanta miliardi, ed occorrerebbero in media più di dieci anni, usando lo stesso programma di ricerca password.

Trudy può avere un po’ di successo sfruttando una debolezza nell’algoritmo di cifratura, comune a molti di essi: per cifrare efficientemente una qualsiasi sequenza di dati, la si suddivide in blocchi di lunghezza prefissata e si cifra un blocco alla volta. Se Trudy è abbastanza abile, può scambiare la posizione di due blocchi o fare altre modifiche che lascino inalterati i singoli blocchi, ed il messaggio risultante sarebbe illeggibile, pur essendo decifrabile senza problemi. Non otterrebbe grandi vantaggi, se non il fatto di rendere difficile la comunicazione e costringere a continue ritrasmissioni.

Il nostro Mallory non ha molte possibilità in più, oltre ai metodi di Eve e Trudy. Per nostra fortuna, i moderni algoritmi soffrono molto meno dei problemi di cui soffriva Enigma, e le risorse necessarie ad attaccarne uno sono decisamente al di fuori della portata di chiunque, almeno per ora.

Diventa però preponderante il problema della distribuzione delle chiavi, su cui tutto il castello della crittografia simmetrica cade, e soltanto per colpa del fattore umano. Tipicamente, si mandano due messaggi di posta elettronica, uno con la password, ed uno con il messaggio cifrato. Con tanti saluti al segreto, visto che se il nostro malefico terzetto può intercettare un messaggio, ne può intercettare due senza tanti problemi.

La precauzione minima è di usare due canali di comunicazione differenti, ad esempio telefono o un SMS per la password ed e-mail per il messaggio, oppure accordarsi prima, di persona.

Tutto questo in funzione del livello di segretezza richiesto. Se devo comunicare i dati del mio conto corrente a qualcuno, basta una telefonata per la password. Se invece sono una società di ricerca che sta per brevettare qualcosa di rivoluzionario, non è proprio il caso di affidarmi al telefono. In definitiva, tutto deve essere commisurato a quanto è importante il segreto per me e soprattutto quanto può far gola.

Un possibile uso del sistema di crittografia a chiave simmetrica è per la realizzazione dei backup dei file di lavoro di GnuPG, problema scottante che avevamo lasciato in sospeso.

Abbiamo due problemi distinti e contrastanti: salvaguardare i dati delle chiavi private e del database della fiducia, quindi averne più copie in luoghi differenti, ed impedire l’accesso non autorizzato ai file, quindi conservarli in un solo posto ben protetto. Una soluzione possibile è appunto di crearne un backup su singolo file, anche compresso, e poi cifrarlo con chiave simmetrica prima di salvarlo su un supporto a scelta, per esempio un CD registrabile.

Il vantaggio è che, anche a seguito della completa distruzione dei file di lavoro di GnuPG, per esempio a causa di un guasto al disco fisso, è possibile recuperare i file dal backup usando la sola chiave di cifratura, anche senza disporre delle chiavi private, che non sono necessarie con la cifratura a chiave simmetrica.

Da questo esempio ne discende la effettiva utilità di questo tipo di crittografia, impiegabile per difendere dati personali, la cui chiave di cifratura non deve essere trasmessa in alcun modo. In sostanza, se tutto rimane dentro le nostre mura, ed i dati da proteggere sono soltanto per i nostri occhi, abbiamo trovato lo strumento ideale.

Se, al contrario, vogliamo comunicare con qualcuno ed essere certi che solo lui possa leggere il messaggio, senza comunicare password e senza incontrarsi prima, dobbiamo tornare ad usare le coppie di chiavi pubbliche/private. Diversamente dalla firma digitale, dove usiamo la chiave privata per firmare e chi vuole controllare l’autenticità della firma stessa deve usare la chiave pubblica, quando vogliamo comunicare con qualcuno usiamo la sua chiave pubblica per cifrare, e alla ricezione questi userà la sua chiave privata per decifrare e leggere il messaggio, e solo chi possiede quella chiave può farlo.

Torniamo a chiedere aiuto ai nostri amici: Pinco deve mandare a Caio il numero della sua carta di credito, ed ovviamente non vuole che altri possano leggerlo. Inoltre, visto che si tratta di una transazione di denaro, vuole firmare il messaggio per attestare che è proprio suo. Il testo supporremo sia questo:

memorizzato in un file dal nome carta.txt. Il comando usato è:

Non avendo indicazioni, GnuPG ha bisogno di sapere quale sia il destinatario del messaggio, per poterlo cifrare con la chiave pubblica giusta, che ricordiamo deve essere quella di chi riceve il messaggio. Si può usare il nome, l’indirizzo di posta elettronica o proprio l’ID in esadecimale. Se ci sono ambiguità viene richiesto di specificare meglio. Si possono specificare più nomi, il messaggio conterrà una copia cifrata del messaggio per ogni destinazione, in un unico blocco, ed ogni destinatario decifrerà con la sua chiave privata.

Per semplificare le cose, si può anche specificare direttamente il destinatario nel comando, usando l’opzione -⁠-⁠recipient seguita dal nome, l’ID o l’indirizzo di posta.

Il messaggio è destinato a Caio, quindi:

ottenendo il file carta.txt.asc il cui contenuto è:

Visto che è composto da testo semplice, può incollarlo dentro un normale messaggio di posta elettronica e spedirlo a Caio.

Caio riceve il messaggio e lo apre col suo programma di posta preferito, (Figura 55). Dal menù di WinPT seleziona Current Window  Decrypt/Verify, ed ottiene il pannello di richiesta password, quella della sua chiave privata (Figura 56).

Appena sbloccata la chiave privata, Caio riceve per prima cosa la conferma che il messaggio viene proprio da Pinco (Figura 57), ma Outlook non permette modifiche ai messaggi ricevuti, quindi WinPT si trova con un problema: può decifrare il messaggio ma non sa dove visualizzarlo.

La questione viene risolta in modo intelligente: dato che molto probabilmente nel rispondere si citerà il messaggio originale, WinPT lo inserisce negli appunti, per permettere di incollare il testo in chiaro in un nuovo messaggio, o di leggerlo direttamente selezionando dal menù di WinPT la voce Clipboard  Edit (Figura 58). La finestra che appare ha delle funzioni per operazioni aggiuntive, come cifrare o decifrare il contenuto della Clipboard.

Caio esegue le operazioni presso la sua banca, e poi comunica a Pinco l’avvenuta transazione, con tutti i dati di riepilogo necessari (Figura 59). Seleziona tutto il testo e lo sposta nella clipboard con la consueta combinazione di tasti Ctrl+X, Poi dal menu di WinPT seleziona Clipboard  Sign & Encrypt. Gli viene chiesta la destinazione, cioè con quale chiave pubblica deve cifrare il messaggio, in questo caso quella di Pinco (Figura 60). Poi, dato che ha anche richiesto la firma del messaggio, gli viene anche chiesta la password per la sua chiave privata (Figura 61).

Il messaggio cifrato e firmato è ora nella clipboard: basta incollarlo all’interno del messaggio ed è pronto per l’invio, l’aspetto sarà simile a quelli già visti (Figura 62). Se per qualche motivo si selezionasse una chiave pubblica che non ha il livello di certificazione richiesto, viene visualizzato un avvertimento (Figura 63), che consente comunque di proseguire con l’operazione.

Vedremo che questo avvertimento è da prendere con la dovuta considerazione. In questo messaggio possiamo anche vedere un esempio di quanto dicevamo in precedenza (sez. 2.5), al momento della generazione delle chiavi: qui la mia chiave pubblica riporta il mio vecchio sito web ed un indirizzo di posta elettronica che non è più il mio principale. Ecco una dimostrazione del perché abbiamo tanto insistito sul fatto di scegliere accuratamente identificativi e indirizzi di posta: dopo nei keyserver rimarrà sempre traccia del primo scelto in origine, anche se poi nella gestione GnuPG utilizza la mia identità principale che ora è con un differente indirizzo di posta elettronica.

Torniamo ai nostri due eroi: il messaggio così cifrato e firmato arriva a Pinco, che se dispone di uno dei programmi di posta elettronica abilitati lo può verificare direttamente, altrimenti può salvare il contenuto del messaggio in un file, supponiamo risposta-caio.txt, e in un colpo solo verificare la firma di Caio e decifrare il messaggio:

Per ragioni di sicurezza il messaggio non viene memorizzato da nessuna parte, per cui, se lo vogliamo salvato su un file, possiamo usare la solita opzione -⁠-⁠output seguita dal nome del file di destinazione, in questo modo:

Il fatto che sia nella versione Windows che in quella Linux il messaggio in chiaro sia disponibile solo per l’immediata lettura, a meno di diverse indicazioni, è dovuto al ragionamento che se un messaggio è tanto importante da richiedere una cifratura “forte”, il semplice scriverlo in chiaro su un supporto per definizione insicuro come un normale file è un controsenso.

La cifratura di un file avviene allo stesso modo, usando il File Manager di WinPT. Per ragioni anche di spazio, non sempre conviene il formato ASCII armored, che aumenta la dimensione dei file cifrati di circa un trenta per cento, anche se durante il processo di cifratura viene anche applicata una forma di compressione per ridurre le dimensioni del file finale. Per dare una idea, il file XML da cui viene generato questo testo è ora di circa 228kbyte, una volta cifrato diventa di 68kbyte, se si forza il formato armored diventa di 92kbyte.

Il nostro malefico terzetto torna alla carica, e vuole a tutti i costi intercettare il messaggio di Pinco a Caio con i dati della carta di credito. Se riescono a metterci le mani sopra il conto in banca di Pinco subirà un tracollo, questo è certo.

Eve da sola non ha alcuna possibilità, almeno nell’immediato futuro. I computer quantici sono ancora allo stadio di esperimento nei laboratori, i prototipi ad oggi mostrati non hanno neanche lontamenente la potenza di calcolo necessaria, ed i nostri amici Pinco e Caio potrebbero utilizzare un algoritmo crittografico non attaccabile da tali computer (sez. 1.7). Per lei l’unica possibilità è un attacco brute force sul messaggio, ma probabilmente si estinguerà prima il Sistema Solare…​

Trudy può alterare il messaggio cifrato, il crittogramma, per renderlo illeggibile, ed ottenere l’effetto di una linea disturbata. Ma per far questo deve avere il controllo di un punto nella catena di comunicazione che non sia aggirabile, per esempio il server di posta di Caio o di Pinco, o la connessione a internet di uno dei due. Se ha soltanto il controllo di un server di transito, i due potrebbero accordarsi per usarne uno differente, o il messaggio potrebbe non transitare sempre dallo stesso server. Ovviamente stiamo sorvolando sulla trascurabile difficoltà insita nella frase “avere il controllo di un punto nella catena di comunicazione”…​

Mallory, un individuo veramente pericoloso, potrebbe compromettere un keyserver, il preferito di Pinco, e sostituire la chiave pubblica di Caio con una che sembri identica, ma generata da lui. Onestamente dubito che sia possibile generare una chiave con lo stesso ID esadecimale e gli stessi dati, ma se anche lo fosse, questa chiave non avrà mai le stesse firme di convalida della chiave originale di Caio, generate con le chiavi private di tutti i suoi amici, quindi non avrebbe neanche la firma di Pinco. Nel momento in cui Pinco aggiornasse le sue chiavi pubbliche dal keyserver, questo gli invierebbe la chiave contraffatta da Mallory, ma al momento della cifratura ci sarebbe qualche problema, perché questa chiave non avrebbe il livello di certificazione necessario, ed apparirebbe il pannello visto precedentemente (Figura 63). Per Mallory sarebbe tutta fatica sprecata, tranne nella sfortunata ipotesi che Pinco per disattenzione ignori il messaggio ed usi comunque la chiave contraffatta per cifrare il messaggio.

Ma non basta la sola disattenzione di Pinco: Mallory deve ancora intercettare il messaggio diretto a Caio, e valgono le stesse considerazioni viste per Trudy: deve prendere il controllo di uno dei server di posta usati da Pinco e Caio. Siamo a due reati commessi, ed ancora non ha messo le mani sul messaggio. Finalmente intercetta il messaggio, che deve anche bloccare, perché se giungesse a destinazione sarebbe evidente che qualcosa di strano è accaduto. Decifra il messaggio, lo legge, ma così facendo ha perso la firma di Pinco, che non può imitare. Per non insospettire i due, cifra con la chiave pubblica vera di Caio il messaggio e glielo spedisce, ma deve prima falsificare il mittente, spacciandosi per Pinco, forse la minore delle fatiche.

Caio riceve il messaggio e nota alla decifrazione che non c’è la firma di Pinco. Per scrupolo lo chiama e chiede come mai non ha firmato il messaggio. Pinco si ricorda benissimo di averlo fatto ed i due si insospettiscono. Caio controlla bene il messaggio di posta e vede che non proviene dal server di posta di Pinco, mentre questi si accorge che la chiave di Caio ha un differente fingerprint. Mallory è scoperto, ed anche se ha i dati della carta di credito di Pinco, probabilmente questi riuscirà a bloccarla prima che possa usarla.

Tutto questo tenendo presente che Mallory deve contare su tutta una serie di circostanze fortunate:

Per quanto possa essere fortunato ed abile, il castello su cui si basa questo tipo di attacco è estremamente fragile.

Le cose cambiano radicalmente se concentra il suo attacco su un altro fronte, infinitamente più debole e vulnerabile: i computer di Pinco e Caio. In questo caso è sufficiente che uno dei due abbia il computer poco sicuro, quale che sia la ragione, ed il gioco è fatto: infilare un malware nel computer, ed usarlo nel modo più economico, intercettando i messaggi prima che siano cifrati o dopo la decifrazione, e leggerli comodamente. L’unica salvezza in questo caso è il livello di sicurezza dei computer di Pinco e Caio, e la loro consapevolezza sui rischi in questo campo. Se le loro strategie di difesa sono quelle notoriamente improvvisate, acriticamente e meccanicamente applicate di un utente medio, nessun sistema di crittografia e nessun modello di certificazione potrà metterli al riparo dai sempre più agguerriti Mallory in giro per il mondo.

Ma questa, come spesso si suol dire, è un’altra storia…​

A chi vuole approfondire l’argomento crittografia in generale, consiglio il libro Codici e segreti di Simon Singh.

In Internet l’argomento è trattato fin nei dettagli più minuziosi, comprese le tecniche per spezzare le cifrature più disparate. Tanto per dare un punto di partenza, consiglio i link che seguono:

Per realizzare questo documento ho usato l’ambiente di creazione ed elaborazione testi di Fedora, aderente allo standard DocBook XML.

Per le immagini ho usato The Gimp (www.gimp.org), splendido programma di manipolazione di manipolazione grafica, disponibile sia in Windows che in Linux.

Il file XML sorgente di questo documento è stato realizzato con VIM (www.vim.org), usando alcuni file di personalizzazione ed un paio di script per la digitazione rapida dei tag XML più usati.

Un sentito ringraziamento a mia moglie, che tollera le ore passate dal sottoscritto al computer, e che per fortuna non si occupa di informatica.

Il team di sviluppo di GnuPG ed i curatori del sito web e di tutta la documentazione meritano incondizionata gratitudine, per il loro ottimo lavoro e prezioso contributo alla comunità.

Senza l’ottimo lavoro fatto dal team di sviluppo di Fedora, la mia distribuzione Linux di riferimento, questo documento non avrebbe potuto vedere la luce. Ovviamente la stessa gratitudine va a tutti gli innumerevoli individui che contribuiscono alla realizzazione di tutto il software open source che costituisce il corpo del sistema operativo Linux e il suo contorno di applicazioni adatte a tutte le esigenze.

Un grazie, si fa per dire, alla programmazione televisiva, in virtù della quale ho recuperato tante ore che passo in modi più piacevoli e costruttivi, almeno per me.

Questo documento è liberamente consultabile, stampabile e distribuibile, ma sotto le limitazioni di una Licenza Creative Commons, e citando chiaramente la fonte.

La versione originale di questo scritto è sul mio sito: http://www.ismprofessional.net/pascucci, dove saranno pubblicate le eventuali nuove versioni del testo che state leggendo, e dove potete trovare molto altro.

Venite a trovarmi, vi aspetto!