Diario delle Revisioni

Revisione 0.5.0

2007-04-11

MP

Revisione totale per la pubblicazione sul web

Revisione 0.4.0

2005-10-10

MP

Revisione del primo capitolo per la pubblicazione

Revisione 0.3.0

2005-09-09

MP

Completato aggiungendo il glossario

Revisione 0.2.0

2005-08-31

MP

Ampliamento alla crittografia e alla versione Windows

Revisione 0.1.0

2005-06-08

MP

Prima versione, contenente solo la parte relativa alla firma digitale per Linux

Presentazione

In questi anni la richiesta di riservatezza, contemporaneamente alla crescita esplosiva di attività professionali in Rete, ha portato alla luce alcuni dei limiti del “sistema Internet” e delle applicazioni normalmente utilizzate nel lavoro quotidiano.

Semplici concetti come identità del mittente, riservatezza delle comunicazioni, certezza della fonte, che nei consueti canali della realtà fisica sono dati per scontati, nel mondo virtuale si scontrano con difficoltà spesso insormontabili. Nel tentativo di rispondere almeno parzialmente a questi inconvenienti, sono stati introdotti strumenti noti come “firma digitale” e “crittografia forte”, che permettono di raggiungere un buon livello di affidabilità e sicurezza.

Non sempre l’uso è reso semplice ed alla portata di tutti, e quello che spesso manca è una indicazione sulle possibili difficoltà e sui limiti di questi strumenti, pur potenti. Questo testo è un tentativo di sopperire a queste mancanze, portando progressivamente il lettore dalle basi teoriche della crittografia forte all’installazione ed all’uso di strumenti open source, disponibili per tutti i sistemi operativi più usati.

Attenzione particolare è riservata anche agli aspetti di protezione di questi strumenti, e sono forniti esempi di quelle che sono le debolezze introdotte dall’inevitabile fattore umano.

Il testo è scritto pensando sia agli utenti Windows che agli utenti Linux e, quando presenti, sono discusse le differenze fra i due sistemi.

1. Introduzione

Crittografia e realtà

Nel leggere un testo specialistico di crittografia ci si imbatte in un gergo molto particolare, e per chi si avvicina la prima volta a questo mondo è certamente fonte di difficoltà, come se l’argomento non fosse già abbastanza complicato di suo. Questo capitolo è una breve introduzione alla crittografia ed alle sue applicazioni reali, con l’intento di fornire al lettore le basi di conoscenza sufficienti a comprenderne il resto. Ci si propone di fare un po’ di chiarezza sull’argomento, vittima spesso di spettacolarizzazioni cinematografiche che poco hanno di reale, e che sono fonte di leggende persistenti a danno della realtà delle cose.

Altra fonte di “rumore” nell’informazione è il fatto che l’argomento sta diventando attuale e pressante per le innumerevoli implicazioni legali, e molti hanno capito che si tratta di una fonte di guadagno. Ecco spuntare dal nulla una miriade di prodotti, che promettono tutto, ed il contrario di tutto, ma non spiegano quali siano gli effetti collaterali e le controindicazioni, per non parlare dei pericoli insiti nell’uso di una tecnologia poco conosciuta e per nulla compresa.

Quando usare la crittografia, come usarla, e soprattutto perché usarla sono domande che ottengono risposte insoddisfacenti, o nessuna risposta.

Basti pensare che uno dei cliché cinematografici più abusati è quello dell’adolescente che con un congegno costruito con le proprie mani, o un software sviluppato in proprio, o peggio ancora “a mani nude”, in pochi secondi viola un codice sofisticatissimo e segretissimo, o si intrufola in una rete di computer di qualche Agenzia nota (e spesso maltrattata dagli sceneggiatori), svalutando profondamente una tecnologia che invece può essere fonte di sicurezza. La crittografia nel mondo reale è profondamente differente, ed i suoi punti di forza, come le sue vulnerabilità, sono in direzione totalmente inaspettata e impensabile.

Come diceva un famoso scrittore, la realtà spesso supera la fantasia. E di molto, aggiungo io.

1.1. Qualche definizione

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:

autenticità

intesa come “quella è proprio la mia firma”

integrità

intesa come “il documento che ho firmato è proprio questo”

non ripudio

inteso come “è firmato da te, non puoi dire che non è tua la firma”

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.

1.2. Digitale equivale a reale?

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:

  • il mittente e il destinatario possono essere falsificati e cambiati senza troppa difficoltà sia in partenza che durante il trasferimento

  • con la stessa facilità, il messaggio può essere letto durante tutto il percorso, senza alterarne in alcun modo il contenuto o l’aspetto

  • non è previsto un meccanismo di verifica dell’integrità del messaggio, che può essere modificato in un momento qualsiasi del trasferimento fra mittente e destinatario, senza lasciare tracce evidenti

  • possono essere fatte copie assolutamente identiche del messaggio senza che si noti differenza alcuna

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.

1.3. Crittografia alla portata di tutti

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.

1.4. Crittografia simmetrica e asimmetrica

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:

  • non può essere invertita, cioè dall’hash non si può ricavare il messaggio originale

  • non deve essere possibile generare in tempi ragionevoli due messaggi differenti che restituiscano lo stesso hash

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.

1.5. Eve la spiona, Trudy l’impicciona, Mallory il guastafeste

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:

  • Eve intercetta un messaggio privato che qualcuno mi ha spedito cifrato con la mia chiave pubblica. Non può decifrarlo con la stessa chiave, perché non funziona, occorre quella privata. Trudy potrebbe provare a modificarlo, ma alla decifrazione mi verrebbe notificata la incongruenza. Può solo impedirmi di leggerlo, ma otterrebbe soltanto di insospettirmi.

  • Trudy potrebbe cambiare totalmente il messaggio, mantenendo la firma. Al momento della verifica, l’hash del messaggio falso sarebbe sicuramente differente da quello presente nella firma, e verrei immediatamente avvertito che la firma non corrisponde al messaggio.

  • Mallory può sostituirlo con un altro messaggio, sempre cifrato con la mia chiave pubblica, spacciandosi per uno dei miei amici. Se però questi firma i propri messaggi con la sua chiave privata, oltre a cifrarli con la mia chiave pubblica, cosa perfettamente possibile, io posso controllare che il messaggio sia effettivamente suo verificandone la 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.

1.6. Decifrare un codice

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…​

1.7. Ma quanto è sicura questa crittografia?

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.

1.8. Il fattore umano

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.

1.9. I modelli di certificazione

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:

  • Il modello ad Autorità di Certificazione (Certification Authority), in cui una organizzazione ha il compito di rilasciare sistemi di firma accertando l’identità delle persone e garantendo nei confronti degli altri. Per verificare la firma digitale fatta in questo modo devo riferirmi all’Autorità che ha rilasciato la firma e garantisce per il firmatario, certificando appunto l’identità e il possesso.

  • Il modello a Rete della Fiducia (Web Of Trust), un po’ più complesso. L’idea di base si appoggia sul concetto dei sei gradi di separazione ed alla Teoria del Mondo Piccolo. In sostanza, ipotizzando di costruire una catena di amici degli amici degli amici, sembra che sia necessaria una catena di sole sei persone per arrivare a qualsiasi altro essere umano attualmente vivente sulla Terra. Questo concetto viene sfruttato dal modello a Rete di Fiducia in questo modo: se mi giunge un messaggio firmato da qualcuno che non conosco, potrei però conoscere un suo amico di cui mi fido. Sulla base di questa idea, ognuno può convalidare l’associazione fra una chiave pubblica e la persona che la detiene quando la conosca di persona o quando l’abbia incontrata almeno una volta in una occasione particolare (un Key Signing Party). Di conseguenza, chi non conosca di persona colui che ha mandato il messaggio, potrebbe però conoscere qualcuno che lo ha incontrato, e quindi fidarsi di riflesso.

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…​

1.10. Conclusioni

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.

2. Gettiamo le fondamenta

Caio e Pinco

Entriamo nel vivo con la presentazione del software open source per la crittografia e la firma digitale. Per non essere da meno, anche noi useremo personaggi di fantasia, tenendo a mente che ogni dato è inventato e ogni riferimento a persone realmente esistenti è casuale e non voluto. Ci riferiremo a Pinco, utente Linux, e Caio, che usa Windows per il suo lavoro di tutti i giorni, ed ai loro amici e conoscenti.

2.1. GNU Privacy Guard

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ì.

Riga di comando per Linux, GUI per Windows

Per mia comodità riporterò sempre la versione Linux negli esempi pratici. Per Windows, in aggiunta, mostrerò come eseguire le stesse operazioni da una interfaccia grafica che semplifica di parecchio la vita a chi non si sente a suo agio con il prompt.

Per rendere utilizzabile e relativamente sicuro il nostro sistema di crittografia e firma digitale, occorre però considerare bene alcuni aspetti, volti a massimizzare sia la praticità che la certezza che nessuno possa facilmente appropriarsi della nostra identità digitale.

2.2. Mantenere un segreto

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:

  • Protezione dei file da accessi non autorizzati, quindi conservazione in un unico posto, al sicuro. Se qualcuno riesce ad averne una copia, può applicare un tentativo di decifrazione brute force sulla password che usiamo per l’accesso alla chiave privata, operazione che come abbiamo visto può essere infinitamente più agevole che trovare la chiave stessa. Inoltre potrebbe alterare in qualche modo i nostri file, per esempio inserendo la sua chiave privata al posto della nostra. Le possibilità di far danni sono limitate solo dalla fantasia, e gli esseri umani ne hanno molta in questi casi.

  • Protezione dalla eventuale perdita o cancellazione dei file, quindi copie di riserva in più supporti, conservati in posti differenti. Se a causa di un guasto hardware perdo i file di lavoro e non ho copie, ho perso la mia chiave privata, oltre a molto altro che la rende valida e credibile, e non posso recuperarla in alcun modo. Se ne genero una nuova, pur usando gli stessi dati, sarà per forza di cose differente dalla precedente, anche perché altrimenti chiunque potrebbe generare una chiave identica alla mia.

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.

I database di GnuPG tendono a crescere

Usando il nostro sistema di sicurezza conosceremo nuove persone e le aggiungeremo, sotto forma di chiavi pubbliche, alla nostra Rete della Fiducia, ed i file di lavoro crescono. Alle chiavi vengono aggiunti dati, le chiavi vengono revocate, scadono, cambiano di livello di affidabilità, e il nostro database ne deve tenere conto. Non saremo quindi troppo spartani con lo spazio riservato al nostro sistema di crittografia.

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:

  • Dati di GnuPG memorizzati su un supporto removibile comodo da trasportare.

  • Backup dei dati su supporto a scelta.

  • Uso di filesystem cifrati (opzionale).

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:

  • Qualcosa che so: una password, il PIN del Bancomat

  • Qualcosa che ho: una smartcard, il disco USB, la carta Bancomat

  • Qualcosa che sono: una mia caratteristica, il mio DNA, la mia faccia, le mie impronte digitali

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.

2.3. Installazione in Linux

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:

[pinco@pclinux ~]$ mkdir /media/usb/.miafirma

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

[pinco@pclinux ~]$ ln -s /media/usb/.miafirma .gnupg

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.

2.4. Installazione in Windows

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:

  • GnuPG, il cuore di tutto il sistema di crittografia.

  • WinPT (Windows Privacy Tray), una applicazione che permette la gestione completa di firma, crittografia e chiavi pubbliche e private, con una integrazione semplice ed efficace con il desktop.

  • GPA (GnuPG Privacy Assistant), un differente programma per la gestione delle chiavi, con la possibilità di cifrare e firmare file. Semplicemente una differente interfaccia per le funzioni di GnuPG. Lo stesso programma è disponibile per Linux.

  • GPGol (GnuPG OutLook plugin), per firmare e cifrare i messaggi di posta elettronica. Funziona solo con Outlook 2003, e non funziona con Outlook Express.

  • GPGee (GnuPG Explorer Extension), per mettere le funzioni di GnuPG nel menù di contesto di Windows Explorer.

  • Sylpheed-claws, un programma completo di posta elettronica, integrato con GnuPG.

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.

Perché questo e non altri?

È certamente vero che esistono parecchie alternative al programma scelto, cioé WinPT (GnuPG deve esserci per forza). Ma tutte richiedono un cambio del modo di gestione della posta elettronica. In Linux esiste Evolution, il gestore di posta, calendario, contatti ed altro, molto simile ad OutLook; per chi usa Thunderbird esiste l’estensione Enigmail che aggiunge l’integrazione con GnuPG, sia per Windows che per Linux; Sylpheed Claws è un gestore di posta elettronica sia per Windows che per Linux, integrato con GnuPG. Ma la maggior parte di noi usa altro, o si è abituata ad usare interfacce webmail, oppure usa programmi per la posta elettronica che non prevedono l’integrazione con GnuPG, e quindi l’uso di un altro programma, solo per aggiungere firma elettronica e crittografia, impone una migrazione ed un cambio di abitudini che per la mia modesta esperienza è solo fonte di disagi, a fronte di un modesto vantaggio per le poche volte che utilizzeremo una firma digitale o un messaggio cifrato. E vedremo che le occasioni non sono poi così frequenti.

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

GnuPG si installa anche senza diritti amministrativi

Se non abbiamo diritti amministrativi sul computer in cui vogliamo utilizzare GnuPG, potremmo installare solo GnuPG, ma non possiamo installarlo da GPG4Win, e non avremo più le comodità messe a disposizione dalle varie interfacce di gestione, occorrerà utilizzare la riga di comando come in Linux.

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.

La presentazione
Figura 1. La presentazione
Licenza GNU GPL
Figura 2. Licenza GNU GPL
Solo un amministratore può…​
Figura 3. Solo un amministratore può…​

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.

Scelta dei componenti
Figura 4. Scelta dei 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.

Directory di destinazione per le applicazioni
Figura 5. Directory di destinazione per le applicazioni
Dove vogliamo le icone di avvio
Figura 6. Dove vogliamo le icone di avvio
Posizione in Start Menù
Figura 7. Posizione in Start Menù

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

L’installazione vera e propria
Figura 8. L’installazione vera e propria
Fine della fase di copia dei file
Figura 9. Fine della fase di copia dei file

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

Fine installazione
Figura 10. Fine installazione

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.

2.5. Generazione delle chiavi

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

[pinco@pclinux ~]$ gpg --version
gpg (GnuPG) 1.4.7
Copyright (C) 2006 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Home: ~/.gnupg
Algoritmi gestiti:
A chiave pubblica: RSA, RSA-E, RSA-S, ELG-E, DSA
Cifrari: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compressione: Non compresso, ZIP, ZLIB, BZIP2

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:

[pinco@pclinux ~]$ gpg --gen-key
gpg: ATTENZIONE: si sta usando memoria insicura! (1)
gpg: visitare http://www.gnupg.org/faq.html per ulteriori informazioni
gpg: directory `/home/pinco/.gnupg' created (2)
gpg: creato un nuovo file di configurazione `/home/pinco/.gnupg/gpg.conf'
gpg: ATTENZIONE: le opzioni in `/home/pinco/.gnupg/gpg.conf' non sono ancora
attive durante questa esecuzione del programma
gpg: portachiavi `/home/pinco/.gnupg/secring.gpg' creato (3)
gpg: portachiavi `/home/pinco/.gnupg/pubring.gpg' creato
Per favore scegli che tipo di chiave vuoi:
   (1) DSA e ElGamal (default) (4)
   (2) DSA (firma solo)
   (4) RSA (firma solo)
Cosa scegli?

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

1 In qualche caso GnuPG non può usare un particolare meccanismo per impedire che la memoria impiegata per la generazione delle chiavi possa essere paginata su disco, col risultato (molto improbabile ma non impossibile) che una chiave possa essere scritta prima di essere cifrata sul disco nell’area di swap. È una eventualità piuttosto remota, ma per correttezza si viene avvertiti. Per maggiori informazioni possiamo riferirci al link che diligentemente GnuPG suggerisce, che contiene notizie più particolareggiate su questo messaggio.
2 Questi messaggi indicano che si sta creando la base per il funzionamento di GnuPG, la directory di lavoro ed il file di configurazione generale. Si può interrompere l’esecuzione in questo momento e cambiare le opzioni nel file gpg.conf, per adeguarle alle nostre esigenze. Al successivo avvio di GnuPG verranno utilizzate le nuove impostazioni. Di solito non serve, i valori predefiniti sono validi per la maggior parte dei casi.
3 Questi file conterranno le chiavi private e pubbliche. Sono chiamati keyring, portachiavi, perché in effetti di questo si tratta. Il file denominato secring.gpg conterrà le chiavi private per la firma e per la crittografia. Il file con nome pubring.gpg conterrà le chiavi pubbliche nostre e dei nostri amici e conoscenti. Insieme al file trustdb.gpg, contenente il dabasase della fiducia, di cui parleremo successivamente, costituiscono il cuore del sistema crittografico, e sono i file che vanno protetti ad ogni costo da letture e manomissioni.
4 La lista può variare, in funzione degli algoritmi di cifratura disponibili nella versione di GnuPG usata. Il valore predefinito va bene per la maggior parte delle esigenze, dato che permette sia la firma che la cifratura di dati generici.

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.

Cosa scegli? 1
DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

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:

What keysize do you want? (2048) Invio
La dimensione richiesta della chiave è 2048 bit
Per favore specifica per quanto tempo la chiave sarà valida.
         0 = la chiave non scadrà
      <n>  = la chiave scadrà dopo n giorni
      <n>w = la chiave scadrà dopo n settimane
      <n>m = la chiave scadrà dopo n mesi
      <n>y = la chiave scadrà dopo n anni
Chiave valida per? (0)

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.

Chiave valida per? (0) 30y
Key expires at ven 13 mar 2037 14:25:47 CET
Is this correct? (y/N) y

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.

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Nome e Cognome: Pinco
Indirizzo di Email: pinco@mail
Commento: uno qualsiasi
Hai selezionato questo User Id:
    "Pinco (uno qualsiasi) <pinco@mail>"

Modifica (N)ome, (C)ommento, (E)mail oppure (O)kay/(Q)uit?

È 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:

Modifica (N)ome, (C)ommento, (E)mail oppure (O)kay/(Q)uit? o

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

Scelta della password

Ricordando quanto detto (cfr. sez. 1.7), è fondamentale che non sia una password banale, che non sia usata anche per altre cose, che abbia una lunghezza adeguata e sia costituita da lettere, numeri e simboli, insomma una password degna di questo nome. Eviteremo parole di senso compiuto, nomi propri, combinazioni di date di nascita, numeri di telefono e targhe di auto con nomi di amici e parenti. E ancora, non useremo la stessa della posta elettronica, né il PIN del bancomat, né altre invenzioni dello stesso tipo.

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.

Ti serve una passphrase per proteggere la tua chiave segreta.

Inserisci la passphrase: inseriamo la password
Ripeti la passphrase: la inseriamo di nuovo per verifica

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:

Dobbiamo generare un mucchio di byte casuali. È una buona idea eseguire
qualche altra azione (scrivere sulla tastiera, muovere il mouse, usare i
dischi) durante la generazione dei numeri primi; questo da al generatore di
numeri casuali migliori possibilità di raccogliere abbastanza entropia.
++++++++++.+++++.++++++++++....++++++++++.+++++...+++++.+++++.++++++++++.++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.+++++++++++++++++++
+>+++++..+++++>+++++...........+++++^^^

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:

gpg: /home/pinco/.gnupg/trustdb.gpg: creato il trustdb (1)
gpg: key E4F4B420 marked as ultimately trusted
chiavi pubbliche e segrete create e firmate. (2)

gpg: controllo il trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: il prossimoi controllo del trustdb sarà fatto il 2037-03-13
pub   1024D/E4F4B420 2007-03-21 [expires: 2037-03-13] (3)
      Key fingerprint = 9294 2CD5 02E3 7C21 7C19  F6D3 7372 A61F E4F4 B420 (4)
uid                  Pinco (uno qualsiasi) <pinco@mail>
sub   2048g/5B514DF0 2007-03-21 [expires: 2037-03-13] (5)

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

1 Il trustdb è il database della fiducia, il cui contenuto è la base del Web of Trust.
2 L’armamentario delle chiavi è a questo punto generato, cifrato e memorizzato.
3 Questa riga informa sulla chiave pubblica principale, da 1024 bit, con algoritmo DSA, identificativo (key id) E4F4B420, creata il 21 marzo 2007 da Pinco, con il commento e l’indirizzo di posta elettronica scelti. Questi dati compariranno sempre insieme alla nostra chiave pubblica, quindi conviene sceglierli con cura.
4 Il fingerprint, l’impronta digitale della chiave, è unico e strettamente associato con la chiave stessa. Se qualcuno manomettesse una delle nostre chiavi il fingerprint sarebbe differente, avvertendoci della manomissione.
5 Questa è la chiave generata con algoritmo ElGamal, ed utilizzata per la cifratura, dato che la chiave DSA può essere usata solo per generare firme, non per cifrare. La scadenza è identica alla chiave di firma, e può essere cambiata. Si possono generare più chiavi ElGamal per la cifratura, ma non ha molto senso tenerne più di una, dato che se qualcuno deve mandarci un messaggio cifrato si troverebbe nell’imbarazzo di quale chiave usare per la cifratura, e noi dovremmo individuare quale usare per decifrare. È più pratico assegnare una scadenza inferiore rispetto alla chiave di firma DSA e cambiarla più spesso.

2.6. Generazione delle chiavi con WinPT

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).

Avviso all’avvio di WinPT
Figura 11. Avviso all’avvio di WinPT
Ci siamo dimenticati di inserire il pen drive
Figura 12. Ci siamo dimenticati di inserire il pen drive

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).

Per accedere alle impostazioni generali
Figura 13. Per accedere alle impostazioni generali
Le preferenze di GnuPG
Figura 14. Le preferenze di GnuPG

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.

Scelta della posizione delle chiavi
Figura 15. Scelta della posizione delle chiavi

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.

Abbiamo scelto il drive E:
Figura 16. Abbiamo scelto il drive E:

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).

L’identità digitale
Figura 17. L’identità digitale

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.

La password di protezione
Figura 18. La password di protezione
Avvertimento per password troppo semplice
Figura 19. Avvertimento per password troppo semplice
Ripetere la password per sicurezza
Figura 20. Ripetere la password per sicurezza

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).

Generazione delle chiavi
Figura 21. Generazione delle chiavi
Le chiavi sono pronte
Figura 22. Le chiavi sono pronte

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

Suggerimento relativo al backup
Figura 23. Suggerimento relativo al backup

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

Salvataggio delle chiavi pubbliche
Figura 24. Salvataggio delle chiavi pubbliche
Salvataggio delle chiavi private
Figura 25. Salvataggio delle chiavi private

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).

Icona nella barra dei menù
Figura 26. Icona nella barra dei menù
Il Key Manager di WinPT
Figura 27. Il Key Manager di WinPT

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

2.7. Il certificato di revoca

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.

Attenzione alle date

Come spiegato in un capitolo successivo (cfr. sez. 4.4), la data può essere contraffatta, per cui il discorso fatto sopra vale per le firme verificate prima che sia usato il certificato di revoca. Se ho verificato un mese fa la firma ad un messaggio, ed oggi ne viene revocata la validità, per me quel messaggio rimane autentico. Ovvio che se mi arriva un messaggio che risulta essere firmato un mese dopo la revoca di validità della chiave, la cosa è piuttosto sospetta.

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:

[pinco@pclinux ~]$ gpg --output revoca.asc --gen-revoke Pinco

sec  1024D/E4F4B420 2007-03-21 Pinco (uno qualsiasi) <pinco@mail>

Create a revocation certificate for this key? (y/N)

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.

Formato dell’ID

GnuPG comprende perfettamente che intendete un numero esadecimale, anche se non usiamo nessuna notazione particolare, ma non con tutti i programmi e servizi è così. In qualche caso, soprattutto con servizi su Internet, per far capire che intendiamo un ID di chiave occorre farlo precedere dalla stringa “0x”, il numero zero seguito dalla lettera “x” minuscola, ad esempio: 0xE4F4B420

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.

Create a revocation certificate for this key? (y/N) y
Per favore scegli il motivo della revoca:
  0 = Nessuna ragione specificata
  1 = Questa chiave è stata compromessa
  2 = Questa chiave è stata sostituita
  3 = La chiave non è più usata
  Q = Cancella
(Probabilmente volevi scegliere 1)
Cosa hai deciso?

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:

Cosa hai deciso? 1
Inserisci una descrizione opzionale; terminala con una riga vuota:
>

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

> Chiave compromessa, non usare!
>
Motivo della revoca: Questa chiave è stata compromessa
Chiave compromessa, non usare!
Is this okay? (y/N)

Supponendo che tutto sia a posto diamo risposta affermativa:

Is this okay? (y/N) y

You need a passphrase to unlock the secret key for
user: "Pinco (uno qualsiasi) <pinco@mail>"
1024-bit DSA key, ID E4F4B420, created 2007-03-21

Inserisci la passphrase:

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:

Forzato l'output con armatura ASCII.
Creato un certificato di revoca.

Per favore spostalo su un media che puoi nascondere; se l'uomo nel mezzo
riuscirà ad accedere a questo certificato potrà usarlo per rendere
inutilizzabile la tua chiave. È una buona idea stamparlo ed archiviarlo,
nel caso il media diventasse illeggibile. Ma fai attenzione: il sistema di
stampa della tua macchina potrebbe immagazzinare i dati e renderli disponibili
ad altri!

Quest’ultimo messaggio nella versione inglese diventa:

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!

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:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: A revocation certificate should follow

iGcEIBECACcFAkYCr3kgHQJDaGlhdmUgY29tcHJvbWVzc2EsIG5vbiB1c2FyZSEA
CgkQc3KmH+T0tCAsywCfRYAvJzR0hU/RsmmDzgOlaIuyv0EAnjCVteultuelWm/Z
cFMsui7XdL5T
=GYEU
-----END PGP PUBLIC KEY BLOCK-----
L’uso del certificato di revoca è definitivo

Se viene inviato ad un keyserver la nostra chiave verrà immediatamente resa inutilizzabile, senza alcuna possibilità di annullare la revoca, quindi conserviamolo in un posto sicuro. Essendo in effetti solo pochi dati, si può usare il suggerimento dato, ossia stamparlo e archiviarlo.

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).

Generare un certificato di revoca da WinPT
Figura 28. Generare un certificato di revoca da WinPT

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).

Dati per il certificato di revoca
Figura 29. Dati per il certificato di revoca

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

Il certificato non deve cadere in mani sbagliate
Figura 30. Il certificato non deve cadere in mani sbagliate

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.

3. Gestione delle chiavi

Un portachiavi ben fornito

Come utilizzare le chiavi pubbliche, cosa sono e come si usano i keyserver e le regole per fare lo scambio di chiavi in modo corretto e sicuro. Seguiremo i nostri amici Caio e Pinco nelle varie operazioni di gestione.

3.1. Chiavi e keyserver

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.

La lista dei keyserver in WinPT
Figura 31. La lista dei keyserver in WinPT

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:

[pinco@pclinux ~]$ gpg --output chiave.asc --armor --export Pinco

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:

[pinco@pclinux ~]$ gpg --keyserver subkeys.pgp.net --send-key Pinco
gpg: inviata con successo a `subkeys.pgp.net' (status=200)

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.

Richiesta di conferma per invio chiave
Figura 32. Richiesta di conferma per invio chiave
Chiave inviata con successo
Figura 33. Chiave inviata con successo

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:

keyserver hkp://subkeys.pgp.net

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:

armor

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.

3.2. Scambiarsi le chiavi pubbliche

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:

  • Nome e cognome a cui è associata la chiave

  • Indirizzo di posta elettronica con cui viene utilizzata la chiave (anche più di uno)

  • Identificatore della chiave, il numero esadecimale a otto cifre

  • Il fingerprint, l’impronta digitale della chiave, un numero esadecimale di 40 cifre generato dalla chiave stessa, quindi assolutamente unico e non riproducibile.

Ottenere questi dati è piuttosto semplice, usando il comando:

[pinco@pclinux ~]$ gpg --fingerprint Pinco
pub   1024D/E4F4B420 2007-03-21 [expires: 2037-03-13]
      Key fingerprint = 9294 2CD5 02E3 7C21 7C19  F6D3 7372 A61F E4F4 B420
uid                  Pinco (uno qualsiasi) <pinco@mail>
sub   2048g/5B514DF0 2007-03-21 [expires: 2037-03-13]

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).

WinPT: proprietà di una chiave
Figura 34. WinPT: proprietà di una chiave

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.

3.3. Convalida delle chiavi

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:

[pinco@pclinux ~]$ gpg --keyserver pgp.mit.edu --recv-key 0x3d739f0d
gpg: key 3D739F0D: public key "Caio <caio@server>" imported
gpg: Numero totale esaminato: 1
gpg:              importate: 1

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:

[pinco@pclinux ~]$ gpg --import 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:

[pinco@pclinux ~]$ gpg --fingerprint Caio
pub   1024D/3D739F0D 2007-03-21
      Key fingerprint = 1A50 D735 18A5 AA5B 2F65  0D76 BB51 4ED0 3D73 9F0D
uid                  Caio <caio@server>
sub   2048g/32F7C2EE 2007-03-21

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:

gpg: Signature made mar 27 mar 2007 16:53:16 CEST using DSA key ID 3D739F0D
gpg: Good signature from "Caio <caio@server>"
gpg: ATTENZIONE: questa chiave non è certificata con una firma fidata!
gpg:          Non ci sono indicazioni che la firma appartenga al proprietario.
Impronta digitale della chiave primaria: 1A50 D735 18A5 AA5B 2F65  0D76 BB51 4ED0 3D73 9F0D

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:

  • firmare (crittograficamente parlando) la chiave pubblica di Caio

  • inviare al keyserver la chiave pubblica di Caio aggiornata con la sua firma di convalida

La prima operazione si esegue con il comando:

[pinco@pclinux ~]$ gpg --sign-key Caio

pub  1024D/3D739F0D  created: 2007-03-21  expires: mai         usage: SC
                     trust: sconosciuto   validity: sconosciuto
sub  2048g/32F7C2EE  created: 2007-03-21  expires: mai         usage: E
[ unknown] (1). Caio <caio@server>


pub  1024D/3D739F0D  created: 2007-03-21  expires: mai         usage: SC
                     trust: sconosciuto   validity: sconosciuto
 Impronta digitale della chiave primaria: 1A50 D735 18A5 AA5B 2F65  0D76 BB51 4ED0 3D73 9F0D

     Caio <caio@server>

Are you sure that you want to sign this key with your
key "Pinco (uno qualsiasi) <pinco@mail>" (E4F4B420)

Really sign? (y/N)  y

You need a passphrase to unlock the secret key for
user: "Pinco (uno qualsiasi) <pinco@mail>"
1024-bit DSA key, ID E4F4B420, created 2007-03-21

Inserisci la passphrase:

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:

[pinco@pclinux ~]$ gpg --list-sigs Caio
gpg: controllo il trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   1  signed:   0  trust: 1-, 0q, 0n, 0m, 0f, 0u
gpg: il prossimoi controllo del trustdb sarà fatto il 2037-03-13
pub   1024D/3D739F0D 2007-03-21
uid                  Caio <caio@server>
sig 3        3D739F0D 2007-03-21  Caio <caio@server>
sig          E4F4B420 2007-03-29  Pinco (uno qualsiasi) <pinco@mail>
sub   2048g/32F7C2EE 2007-03-21
sig          3D739F0D 2007-03-21  Caio <caio@server>

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:

Con quanta attenzione hai verificato che la chiave che stai per firmare
appartiene veramente alla persona indicata sopra?
Se non sai cosa rispondere digita "0".

   (0) Preferisco non rispondere. (default)
   (1) Non l'ho controllata per niente.
   (2) L'ho controllata superficialmente.
   (3) L'ho controllata molto attentamente.

Your selection? (enter `?' for more information):

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.

Risultato di una ricerca su keyserver
Figura 35. Risultato di una ricerca su keyserver

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).

Elenco chiavi pronte per l’importazione
Figura 36. Elenco chiavi pronte per l’importazione
Riepilogo dell’importazione
Figura 37. Riepilogo dell’importazione

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.

Firma di una chiave
Figura 38. Firma di una chiave

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:

[pinco@pclinux ~]$ gpg --keyserver pgp.mit.edu --send-keys Caio
gpg: inviata con successo a `pgp.mit.edu' (status=200)

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:

[pinco@pclinux ~]$ gpg --refresh-keys Pinco
gpg: refreshing 1 key from hkp://subkeys.pgp.net
gpg: key E4F4B420: "Pinco (uno qualsiasi) <pinco@mail>" 1 new signature
gpg: Numero totale esaminato: 1
gpg:            nuove firme: 1
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: il prossimoi controllo del trustdb sarà fatto il 2037-03-13

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 esporta la sua chiave pubblica su un file e lo spedisce a Pinco

  • Pinco importa la chiave di Caio, controllando che il fingerprint e i dati corrispondano

  • Pinco firma la chiave pubblica di Caio

  • La esporta su un file che manda a Caio

  • Caio riceve il file e lo importa, acquisendo la nuova firma di convalida

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.

Qui si parla solo di chiavi pubbliche!

Tutte le operazioni viste di firma, esportazione, invio ai keyserver, importazione, coinvolgono soltanto le chiavi pubbliche. Mai e per nessun motivo deve essere esportata la chiave privata, né tanto meno inviato il file che la rappresenta a qualcuno. Sui keyserver esistono solo chiavi pubbliche, come specificato dallo standard.

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.

3.4. Fidarsi degli amici

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:

pub   1024D/D3241B83 2005-08-19
      Key fingerprint = 326B 9AC0 6B8C 80A6 5BFC  FFD2 F571 D04F D324 1B83
uid                  Tizio (uno pignolo) <tizio@posta>
sub   2048g/331B1726 2005-08-19

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:

[tizio@miopc ~]$ gpg --edit pinco

pub  1024D/E4F4B420  created: 2007-03-21  expires: 2037-03-13  usage: SC
                     trust: sconosciuto   validity: full
sub  2048g/5B514DF0  created: 2007-03-21  expires: 2037-03-13  usage: E
[  full  ] (1). Pinco (uno qualsiasi) <pinco@mail>

Comando>

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:

Comando> trust
pub  1024D/E4F4B420  created: 2007-03-21  expires: 2037-03-13  usage: SC
                     trust: sconosciuto   validity: full
sub  2048g/5B514DF0  created: 2007-03-21  expires: 2037-03-13  usage: E
[  full  ] (1). Pinco (uno qualsiasi) <pinco@mail>

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Cosa hai deciso?

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?

La fiducia è soggettiva e privata

Non dobbiamo avere remore ad esprimere quello che pensiamo: la fiducia è una informazione privata e soggettiva, e non viene inclusa in nessun caso con i dati che vengono esportati con le chiavi pubbliche di nessuno, quindi non viene pubblicata sui keyserver. Solo noi sappiamo quanto fidarci di una persona, e nessuno deve sindacare su questo.

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:

  • Se una chiave è firmata da qualcuno in cui si ha fiducia piena, è attendibile.

  • Se la chiave è firmata da almeno tre persone in cui si ha fiducia parziale, è considerata attendibile.

  • La profondità massima di una catena di firme convalidate con le due regole precedenti è di cinque salti.

  • Dal sesto in poi le firme saranno considerate inattendibili, indipendentemente dal numero e dalla fiducia riposta nelle firme che possiede la chiave in esame.

La costruzione della catena non è automatica

Attenzione: l’attendibilità e la fiducia non sono assegnate automaticamente. Siamo sempre noi a decidere, GnuPG si ferma al primo anello della catena a cui non abbiamo esplicitamente assegnato fiducia o attendibilità, e non prende iniziative di alcun tipo. Quindi se abbiamo una catena di cinque persone dobbiamo aver assegnato fiducia ad ognuno esplicitamente, ed ognuno deve aver convalidato la chiave del successivo nella catena, altrimenti si interromperà alla prima eccezione.

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:

Caio - Pinco - Tizio - Amico di Tizio

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.

Marginale o parziale?

La parola marginal utilizzata nella versione inglese è da intendere con il significato di parziale, appena sufficiente, e viene tradotta con marginale che non è del tutto corrispondente, visto che in italiano significa poco importante. Quindi non me ne vorrete se nel seguito userò preferibilmente il termine parziale invece del meno corretto marginale.

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

Cosa hai deciso? 3

pub  1024D/E4F4B420  created: 2007-03-21  expires: 2037-03-13  usage: SC
                     trust: marginal      validity: full
sub  2048g/5B514DF0  created: 2007-03-21  expires: 2037-03-13  usage: E
[  full  ] (1). Pinco (uno qualsiasi) <pinco@mail>
Nota che la validità della chiave indicata non sarà necessariamente corretta
finchè non eseguirai di nuovo il programma.

Comando> quit

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

Fiducia nella persona e fiducia nella chiave

Ci può essere un po’ di confusione fra questi due aspetti. La fiducia nella chiave in realtà andrebbe sempre denominata attendibilità della chiave, e riguarda l’aspetto di appartenenza alla persona che dichiara di usarla. Se la chiave pubblica l’abbiamo verificata e firmata di persona, il significato è ovvio, se invece la chiave è verificata tramite la Rete della Fiducia, entra in gioco l’altra fiducia, quella sul livello di comprensione ed attenzione che la persona mette, sempre secondo noi, nella verifica delle chiavi che firma. Purtroppo nel parlare comune è difficile separare i due aspetti, l’importante è tener presente che i due tipi di fiducia, pur differenti, sono strettamente collegati fra loro. Una cosa che deve essere chiara è che la fiducia nella persona non è generica: posso fidarmi di un mio amico al punto di prestargli metà dei miei risparmi senza formalità, ma essere nel contempo convinto che non capisca quanto sia importante la verifica dell’identità delle persone prima di firmarne le chiavi pubbliche, per cui continuerò a prestargli i miei risparmi, ma nella mia Rete della Fiducia gli assegnerò fiducia parziale, o nessuna fiducia.

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).

Le proprietà della chiave di Pinco
Figura 39. Le proprietà della chiave di Pinco
Il livello di fiducia scelto
Figura 40. Il livello di fiducia scelto

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.

4. Uso della firma

Ho le chiavi…​ Firmo?

L’uso della firma digitale nel mondo reale: firmare messaggi e documenti, verificarne le firme.

4.1. Vari tipi di firma

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.

4.2. La firma dentro il messaggio

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:

Messaggio di prova.
Questo messaggio viene firmato con gpg
usando una firma internamente al messaggio.
Ciao
Pinco

salvandolo in un file dal nome messaggio.txt.

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

[pinco@pclinux ~]$ gpg --clearsign messaggio.txt

You need a passphrase to unlock the secret key for
user: "Pinco (uno qualsiasi) <pinco@mail>"
1024-bit DSA key, ID E4F4B420, created 2007-03-21

Inserisci la passphrase:

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Messaggio di prova.
Questo messaggio viene firmato con gpg
usando una firma internamente al messaggio.
Ciao
Pinco

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGEOqic3KmH+T0tCARAl5JAJ9vYc2juhsgskIgJcQtXyTp1Zhl/wCfWlal
vy5wqAnDpD//Aivr4cAarjA=
=9Hi+
-----END PGP SIGNATURE-----

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:

[pinco@pclinux ~]$ gpg --verify messaggio.txt.asc
gpg: Signature made lun 02 apr 2007 13:36:02 CEST using DSA key ID E4F4B420
gpg: Good signature from "Pinco (uno qualsiasi) <pinco@mail>"

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:

[pinco@pclinux ~]$ gpg --verify falso.txt.asc
gpg: Signature made lun 02 apr 2007 13:36:02 CEST using DSA key ID E4F4B420
gpg: BAD signature from "Pinco (uno qualsiasi) <pinco@mail>"

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:

gpg: CRC error; 7C3687 - F478BE
gpg: no signature found
gpg: non è stato possibile verificare la firma.

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

gpg: Signature made lun 02 apr 2007 13:46:57 CEST using DSA key ID 5F0AC7D3
gpg: Impossibile controllare la firma: chiave pubblica non trovata

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:

gpg: Signature made lun 02 apr 2007 13:46:57 CEST using DSA key ID 5F0AC7D3
gpg: BAD signature from "Mario Pascucci <mpascucci@gmail.com>"

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).

Formato dei messaggi di posta

È necessario che il messaggio sia scritto in formato testo semplice, quindi niente RTF né HTML. Potrebbero funzionare, ma le impostazioni del tipo di carattere, del colore, dell’impaginazione in questi formati contengono dei caratteri nascosti che concorrono a generare l’hash, che poi diventerà la firma. Chi li riceve potrebbe avere un programma diverso, o semplicemente in versione differente e non è assolutamente detto che funzioni allo stesso modo. Solo testo semplice e niente altro. Ci interessa il contenuto del messaggio, non gli abbellimenti.

C’è una ragione ulteriore, molto più forte: recentemente si è dimostrato che si può generare una sequenza di dati che abbia un determinato hash. Ricordando come funziona la firma digitale, il riuscire a generare un altro messaggio con identico hash significa che si può cambiare il contenuto del messaggio lasciando valida la firma.

Detto in questo modo sembra un disastro, ma, indagando meglio, si scopre che le sequenze necessarie sono costituite con dati binari che nulla hanno di sensato, non essendo neanche rappresentabili come caratteri alfabetici; quindi, modificare un messaggio in questo modo lo renderebbe molto probabilmente illeggibile, o al più con l’apparenza di essere rovinato, mostrando appunto una lunga sequenza di caratteri e simboli apparentemente casuali. Se però il messaggio è in un formato che permetta di nascondere “sotto” il testo qualsiasi cosa, come succede con HTML, RTF, DOC, PDF, PS (insomma con praticamente tutti i formati diversi dal testo semplice), un malintenzionato potrebbe intercettare un nostro messaggio, modificarne a piacere il contenuto visibile, ed aggiungere i dati nascosti per far combaciare l’hash con quello del messaggio originale. Chiunque riceva il messaggio non solo non si accorgerebbe di nulla, ma troverebbe la firma digitale valida, e non avrebbe alcun motivo di dubitare dell’autenticità del messaggio. A titolo di curiosità, è possibile reperire su un sito web (in inglese) due documenti di esempio in formato PostScript, con contenuto assolutamente differente ed hash MD5 identico. Esaminando attentamente i file si nota una sequenza di dati binari all’inizio che non appare quando si stampano o si visualizzano. È un fenomeno noto chiamato collisione degli hash, e il meccanismo di firma digitale ne tiene conto.

Proprio per evitare l’uso di trucchi di questo tipo, trattandosi di messaggi molto importanti, tanto da richiedere una firma digitale di convalida, usiamo e pretendiamo che si usi il testo semplice. Una protezione non aggirabile verrà poi quando, oltre a firmare un messaggio, lo cifreremo per renderlo illeggibile da chiunque tranne il destinatario: in questo caso, prima di pensare a truccare la firma, occorre risolvere il problema della decifrazione, ben più complesso.

In ogni caso lo sfruttamento di questo tipo di debolezze negli hash non è proprio banale, ed a oggi la quantità di calcoli necessaria per “aggiustare” un hash è astronomica e certamente non alla portata di chiunque: il numero di tentativi per ricavare un hash SHA1 “addomesticato” è dell’ordine di 2 elevato 69 operazioni: 590.295.810.358.705.651.712 è il numero corrispondente, per chi vuole arrischiarsi a leggerlo. Inoltre, fatto non trascurabile, quanto detto vale solo per gli algoritmi di hash SHA1 e MD5: se andiamo ad usare un algoritmo come SHA256 o peggio SHA384, entrambi supportati da GnuPG, le cose si fanno infinitamente più difficili per un eventuale Mallory in vena di scherzi.

Messaggio in Outlook Express
Figura 41. Messaggio in Outlook Express

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).

Richiesta password
Figura 42. Richiesta password
Messaggio firmato
Figura 43. Messaggio firmato
WinPT e la clipboard

Può succedere che per qualche motivo, connesso strettamente a come è realizzata l’applicazione che contiene il testo da firmare, WinPT lamenti che non trova nessun testo nella finestra indicata. Non è un problema, dato che può operare sul testo contenuto nella clipboard: basta selezionare il testo su cui operare, copiarlo nella clipboard con la combinaizone di tasti Ctrl+C, ed operare prendendo dal menù di WinPT la voce Clipboard invece di Current window. Per ottenere il risultato dell’operazione basta incollarlo dalla clipboard con la combinazione Ctrl+V o esaminare il contenuto della clipboard stessa selezionando dal menù di WinPT Clipboard  Edit. Più avanti ci saranno degli esempi, ma basti sapere che WinPT opera indifferentemente nei due modi.

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:

[pinco@pclinux ~]$ gpg --verify msg-da-caio.txt
gpg: Signature made lun 02 apr 2007 12:40:14 CEST using DSA key ID 3D739F0D
gpg: Good signature from "Caio <caio@server>"

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:

gpg: Signature made lun 02 apr 2007 12:40:14 CEST using DSA key ID 3D739F0D
gpg: Impossibile controllare la firma: chiave pubblica non trovata

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

gpg: Signature made lun 02 apr 2007 12:40:14 CEST using DSA key ID 3D739F0D
gpg: Good signature from "Caio <caio@server>"
gpg: ATTENZIONE: questa chiave non è certificata con una firma fidata!
gpg:          Non ci sono indicazioni che la firma appartenga al proprietario.
Impronta digitale della chiave primaria: 1A50 D735 18A5 AA5B 2F65  0D76 BB51 4ED0 3D73 9F0D

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.

Non si dispone della chiave pubblica
Figura 44. Non si dispone della chiave pubblica
La chiave non è certificata
Figura 45. La chiave non è certificata

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.

4.3. La firma a parte

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:

[pinco@pclinux ~]$ gpg --detach-sign --armor --output firma.asc utile.exe

You need a passphrase to unlock the secret key for
user: "Pinco (uno qualsiasi) <pinco@mail>"
1024-bit DSA key, ID E4F4B420, created 2007-03-21

Inserisci la passphrase:

dove le opzioni stanno a significare:

-⁠-⁠detach⁠-⁠sign

fai una firma separata

--armor

il formato sarà ASCII-armored, ossia in testo stampabile protetto da due righe, una all’inizio ed una alla fine.

--output

è seguito dal nome del file dove deve mettere la firma. Se non c’è questa opzione la firma viene stampata a video.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBGEQGEc3KmH+T0tCARAu5NAJ9Q6qtsqwXIVXPZVUebOJLDNByxwwCfWN1H
9oxL5/L/Mpw5ENUyJizwoWY=
=rtjQ
-----END PGP SIGNATURE-----

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.

Il File Manager con il file della firma dentro
Figura 46. Il File Manager con il file della firma dentro

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).

La firma è corretta
Figura 47. La firma è corretta

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.

Scelta del tipo di firma
Figura 48. Scelta del tipo di firma

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

[pinco@pclinux ~]$ gpg --verify utile.exe.asc utile.exe
gpg: Signature made lun 02 apr 2007 14:10:56 CEST using DSA key ID 3D739F0D
gpg: Good signature from "Caio <caio@server>"

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.

4.4. Aiutare Mallory a far danni

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:

Devo parlarti di una cosa importante,
passo da te alle 17, aspettami.

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:

  • Caio ha messo all’interno del messaggio pochissimi dettagli ed indicazioni sul destinatario. Il messaggio è troppo generico e Mallory ha potuto utilizzarlo senza destare sospetti.

  • Pinco non ha controllato la data in cui la firma è stata apposta al messaggio. Se lo avesse fatto, avrebbe notato che la firma era generata giorni o mesi prima, comunque in data molto antecedente alla data di spedizione del messaggio.

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.

4.5. La Rete della Fiducia

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:

[tizio@miopc ~]$ gpg --verify msg-da-caio.txt
gpg: Signature made lun 02 apr 2007 12:40:14 CEST using DSA key ID 3D739F0D
gpg: Impossibile controllare la firma: chiave pubblica non trovata

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

[tizio@miopc ~]$ gpg --recv-key 0x3D739F0D
gpg: key 3D739F0D: public key "Caio <caio@server>" imported
gpg: Numero totale esaminato: 1
gpg:              importate: 1
gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
gpg: depth: 0  valid:   1  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   1  signed:   1  trust: 0-, 0q, 0n, 1m, 0f, 0u
gpg: il prossimoi controllo del trustdb sarà fatto il 2037-03-13

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:

[tizio@miopc ~]$ gpg --list-sigs Caio
pub   1024D/3D739F0D 2007-03-21
uid                  Caio <caio@server>
sig 3        3D739F0D 2007-03-21  Caio <caio@server>
sig          E4F4B420 2007-03-29  Pinco (uno qualsiasi) <pinco@mail>
sub   2048g/32F7C2EE 2007-03-21
sig          3D739F0D 2007-03-21  Caio <caio@server>

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

[tizio@miopc ~]$ gpg --verify msg-da-caio.txt
gpg: Signature made lun 02 apr 2007 12:40:14 CEST using DSA key ID 3D739F0D
gpg: controllo il trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
gpg: depth: 0  valid:   1  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   1  signed:   1  trust: 0-, 0q, 0n, 1m, 0f, 0u
gpg: il prossimoi controllo del trustdb sarà fatto il 2037-03-13
gpg: Good signature from "Caio <caio@server>"
gpg: ATTENZIONE: questa chiave non è certificata con firme abbastanza fidate!
gpg:          Non è sicuro che la firma appartenga al proprietario.
Impronta digitale della chiave primaria: 1A50 D735 18A5 AA5B 2F65  0D76 BB51 4ED0 3D73 9F0D

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).

Lista delle firme
Figura 49. Lista delle firme

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.

Firma valida e certificata
Figura 50. Firma valida e certificata

4.6. Quando usare la firma digitale

È 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:

  • Quando il messaggio o il documento ha un impatto economico di qualsiasi genere. Ad esempio le fatture o i documenti fiscali, le ricevute di pagamento in formato elettronico, sempre più spesso anticipate per e-mail, possono essere rese più attendibili con una firma digitale.

  • Quando si intende provare sia la provenienza che l’integrità di un qualsiasi file o documento. Se sviluppiamo software, i file dei programmi possono essere accompagnati da una firma digitale, aggiungendo una notevole dose di sicurezza per chi li dovesse scaricare dal nostro sito web, o riceverli per posta elettronica.

  • Diminuire l’incidenza dei virus. Se ci giunge un allegato da qualcuno che conosciamo, spesso ci troviamo nell’imbarazzo di capire se è un messaggio vero o siamo davanti ad un virus che cerca di ingannarci per far aprire l’allegato. Se i messaggi fossero firmati, allegato compreso, la verifica è immediata. Il virus non può firmare i messaggi, anche se ha accesso ai file di GnuPG, perché non conosce la password che protegge la nostra chiave privata.

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.

5. Uso della crittografia

Dopo la firma…​ la riservatezza.

Dopo aver preso confidenza con le chiavi pubbliche e private, la firma digitale, e imparato ad usare i principali programmi di gestione, vediamo come sfruttare le ulteriori possibilità che GnuPG mette a disposizione.

5.1. Crittografia simmetrica

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:

[pinco@pclinux ~]$ gpg --symmetric documento.txt
Inserisci la passphrase:

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:

Messaggio di prova
da sottoporre a cifratura
la password sara' "test"
Ciao

dopo averlo cifrato con il comando:

[pinco@pclinux ~]$ gpg --armor --symmetric documento.txt

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

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.7 (GNU/Linux)

jA0EAwMCFEeD1Sk8GFhgyWqbyuWH8XI2v95M1vZEtfHbD5rA6USmOS3PN+kti0yr
DHfgEYpbSq9Zp878MykeaMJOXosGs3Srl75kTQrYuWRdrqrX8/DwOUvP6/JzOdUb
Hi2Un6GapeqF6GRSx8CvFHHBgffyIaunQ0E2
=nEIp
-----END PGP MESSAGE-----

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

Ogni messaggio cifrato è diverso

Se proviamo a cifrare due volte lo stesso messaggio con la stessa password otterremo due risultati totalmente differenti: questo perché il processo di cifratura coinvolge anche l’uso di numeri casuali, in modo da dare ogni volta messaggi differenti in presenza dello stesso testo e della stessa password.

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

[pinco@pclinux ~]$ gpg --decrypt documento.txt.gpg
gpg: dati cifrati con CAST5
Inserisci la passphrase:

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

gpg: cifrato con 1 passphrase
Messaggio di prova
da sottoporre a cifratura
la password sara' "test"
Ciao
gpg: ATTENZIONE: l'integrità del messaggio non era protetta

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:

[pinco@pclinux ~]$ gpg --version
gpg (GnuPG) 1.4.7
Copyright (C) 2006 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Home: ~/.gnupg
Algoritmi gestiti:
A chiave pubblica: RSA, RSA-E, RSA-S, ELG-E, DSA
Cifrari: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compressione: Non compresso, ZIP, ZLIB, BZIP2

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:

[pinco@pclinux ~]$ gpg --decrypt-files documento.txt.gpg
Inserisci la passphrase:

e dopo aver digitato due volte la password:

gpg: dati cifrati con CAST5
gpg: cifrato con 1 passphrase
gpg: ATTENZIONE: l'integrità del messaggio non era protetta

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.

Il messaggio da cifrare
Figura 51. Il messaggio da cifrare

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).