I comandi Linux: la crittografia: GPG | ALTRI capitoli | ||||||
Il comando
( RFC 4880: OpenPGP Message Format ). Naturalmente, è necessario che sia il mittente, sia il destinatario del messaggio abbiano installato
Questo comando chiede a
La chiave primaria, ID 6D7F10C5, nel nostro esempio, è una chiave pubblica RSA ( R per RSA, D per DSA, g per ElGamal, utilizzabile solo per la cifratura, G per ElGamal, utilizzabile sia per la cifratura, sia per la firma digitale ), di 2048 bit, così come la chiave subordinata, ID A6EBAA33. Naturalmente, per ogni chiave pubblica ( primaria o subordinata ), esisterà una corrispondente chiave privata ( secret ):
Utilizzare una singola coppia di chiavi RSA, sia per la codifica dei dati, sia per la firma digitale, non è consigliato, vista la possibile esposizione della coppia di chiavi a particolari tipi di attacco. Normalmente, in fase di generazione di una nuova coppia di chiavi, la selezione di default, proposta da
dove RSA ( dai cognomi dei ricercatori che lo hanno inventato: Ron Rivest, Adi Shamir, Leonard Adleman ) e ElGamal ( Taher Elgamal ) sono algoritmi a chiave pubblica, mentre DSA ( Digital Signature Algorithm ) è un algoritmo per la firma digitale. Scelto il tipo di chiavi che si desidera generare, dobbiamo, ora, deciderne le dimensioni:
Anche in questo caso, selezionate il valore di default ( 2048 ): più lunga è la chiave, più è sicura. Se la chiave è troppo lunga, l'elaborazione si rallenta. La lunghezza ottimale di una chiave è correlata anche ai mezzi a disposizione: se 2048 bit, oggi, possono essere considerati sicuri, potrebbero non esserlo più tra una decina di anni. Tutto dipende dalle capacità computazionali delle macchine in uso. Come già detto, esiste una relazione matematica tra la chiave pubblica e la chiave privata. Anche se non è un compito semplice, è sempre possibile risalire alla chiave privata, a partire dalla chiave pubblica: quello che serve è: tempo e computer potenti. Oggi, comunque, 2048 bit sono un ottimo compromesso. Al programma
vi verrà chiesto di inserire una "passphrase", che proteggerà le vostre chiavi private, primaria e subordinata. Una "passphrase" altro non è che una password più lunga di otto caratteri: è possibile inserire intere frasi, spazi compresi. Tenete bene a mente la "passphrase" scelta, visto che vi verrà chiesta ad ogni tentativo di usare le vostre chiavi di codifica/decodifica. Nessuno potrà utilizzare il vostro file keyring privato, senza immettere questa passphrase. Non perdete la passphrase: non c'è modo di recuperarla, in caso di smarrimento! Inoltre, ricordate ciò che viene riportato, giustamente, in Wikipedia: "la sicurezza di ogni algoritmo è subordinata alla sicurezza della passphrase con cui si protegge la propria chiave privata. Premesso questo se si usa come passphrase "pippo" un attacco di forza bruta sul nostro computer impiegherà pochissimi istanti per fornire all'NSA ( National Security Agency ) i dati cercati. Diversamente una passphrase più robusta farebbe dormire sonni più tranquilli ( o notti più insonni, a seconda del ruolo che si interpreta )". Il processo di acquisizione dei dati, ora, è completato. E' possibile che
Le chiavi vengono memorizzate, in forma criptata, in due file, chiamati file keyring:
Il primo è riservato alle chiavi pubbliche, il secondo alle chiavi private. I file del programma
dove il simbolo
L'output di questo comando non è di facile lettura. Per comprenderlo, è necessario fare riferimento alla RFC 4880: OpenPGP Message Format. Esiste anche un programma, chiamato
Per ottenere la lista delle chiavi pubbliche presenti nel vostro file keyring, eseguite uno dei due comandi seguenti:
Per verificare, invece, la presenza della chiave pubblica appena generata, specificarne, anche solo parzialmente, l'ID:
Per ottenere le chiavi private, presenti nel vostro file keyring, utilizzate il comando:
Grazie alla firma digitale, la chiave pubblica, appena generata, viene indissolubilmente legata ai dati del proprietario della chiave, appena inseriti. La firma digitale, in GnuPG (
Per calcolare l'impronta digitale sia della chiave pubblica primaria, sia della sottochiave, è sufficiente ripetere il comando
Per calcolare l'impronta digitale o le impronte digitali di ciascuna coppia di chiavi, presente nel proprio file delle chiavi pubbliche:
Chiunque, a questo punto, potrà decriptare la firma digitale, utilizzando la chiave pubblica del firmatario, per recuperare l'impronta digitale originale, per poi confrontarla con l'impronta digitale, ricalcolata sui dati appena ricevuti. Se le due impronte digitali coincidono, i dati ricevuti sono identici ai dati originariamente inviati ( integrità del messaggio ). Seguiamo David E. Ross, nel suo Pretty Good Privacy: "L'autocertificazione ( Self-signing ) avviene quando il proprietario di una chiave utilizza la propria chiave privata per firmare la propria chiave pubblica. L'autocertificazione ( Self-signing ) apposta ad una chiave assegna una qualche autenticità alla chiave stessa, quanto meno per gli ID utente ( nome e/o indirizzo di posta elettronica ). Lo ID utente della firma digitale deve corrispondere allo ID utente della chiave. Dove troviamo più ID utente, lo ID della firma digitale deve corrispondere allo ID primario della chiave. Allo stesso modo, lo ID della chiave, presente nella firma digitale, deve corrispondere allo ID della chiave, presente nella chiave stessa. Questo meccanismo garantisce, infatti, che chiunque abbia piazzato uno ID utente in una chiave pubblica, possiede anche la corrispondente chiave privata e la necessaria passphrase". La firma digitale garantisce che i dati ricevuti siano stati inviati dal detentore della chiave privata con la quale è stata generata. I dati veri e propri, a loro volta, potranno viaggiare in chiaro, oppure criptati, utilizzando, nel caso di GnuPG (
Per poter scrivere, in forma criptata, al signor Juliusz Chroboczek, occorrerà, quindi, importare il suo certificato ( ID: EADB5526 ) nel proprio file delle chiavi pubbliche ( keyring ) e verificarne l'impronta digitale:
Nel file delle chiavi pubbliche dovremo importare le chiavi pubbliche di tutti i destinatari ai quali vogliamo inviare messaggi criptati. Allo stesso modo, il file delle chiavi pubbliche potrà essere inviato ai vostri amici, affinchè lo includano ( import ) nel loro file delle chiavi pubbliche. Se ne serviranno ogni qualvolta desidereranno scrivervi, in forma riservata ( criptata ). Naturalmente, il file delle chiavi private dovrà essere conservato nel proprio computer, senza mai essere trasmesso a chichessia. Il file delle chiavi private deve essere tenuto sotto stretto controllo fisico, senza mai salvarlo su una macchina condivisa, tantomeno su un server internet. Per inviare il vostro file delle chiavi pubbliche agli amici ed ai colleghi, sarà necessario eseguirne un backup:
Le chiavi pubbliche verranno salvate nel file binario
Le chiavi pubbliche verranno salvate nel file ASCII
Se si omettesse l'indicazione del file di output, le chiavi pubbliche verrebbero stampate a video ( STDOUT ):
Questa è la chiave pubblica del certificato digitale con ID AD741727, in formato ASCII. Per aggiungere chiavi al proprio file keyring pubblico ( per esempio, il file
Se la chiave ( o le chiavi ), contenuta nel file
salvando le chiavi private in un file temporaneo ( "
Completata l'operazione, non dimenticate di eliminare il file temporaneo:
Il comando
L'opzione
Esistono diversi keyserver, tra i quali, i più noti sono:
La gran parte dei keyserver si sincronizzano, automaticamente, tra loro: inviare la propria chiave pubblica ad uno solo di essi, quindi, comporta l'inserimento automatico della propria chiave pubblica in tutti gli altri server. Prima di inviare la propria chiave pubblica ad un server di chiavi pubbliche, tenete a mente quanto segue:
Prima di eliminare una propria coppia di chiavi dai propri file keyring ( pubblico e privato ), è necessario revocare il relativo certificato digitale, creando un certificato di revoca, importando il certificato di revoca nel proprio file keyring, per poi reinviare l'intero certificato digitale, comprensivo del certificato di revoca, al keyserver. Una volta inviata la revoca al keyserver, dovrete, prima, eliminare la chiave privata della coppia di chiavi revocate:
per poi eliminare la corrispondente chiave pubblica ( certificato digitale ):
Per eliminare una chiave pubblica di terzi ( non vostra ) dal vostro file keyring, eseguite il comando:
Ora sappiamo come generare nuovi certificati e come revocarli. Non ci resta che capire come usarli. Se desiderate inviare un messaggio criptato ad Alice, occorre criptare il messaggio utilizzando la chiave pubblica di Alice. Per utilizzare la chiave pubblica di Alice, dovrete, prima, importarla nel vostro file keyring. Alice potrà decriptare il vostro messaggio, utilizzando la sua chiave privata. Se Alice vorrà rispondere al vostro messaggio, inviandovi un messaggio criptato, dovrà criptare il suo messaggio, utilizzando la vostra chiave pubblica, così che voi possiate decriptarlo, utilizzando la vostra chiave privata. Per criptare un file (
dove
In questo caso, il file di output avrà una estensione
E' possibile criptare un file, specificando più destinatari:
In questo caso, il file
che eseguirà la decifratura del file
riceve l'input dal file specificato, oppure, se non viene specificato alcun file, dallo STDIN; se non viene indicato alcun file di output, inoltre, l'output verrà stampato a video ( STDOUT ). Se il file criptato è anche firmato, verrà eseguita la verifica della firma digitale. E' possibile criptare un file, utilizzando una più semplice chiave simmetrica, fermo restando che abbiate concordato con il vostro destinatario la chiave di cifratura / decifratura da usare:
Vi verrà chiesto di inserire un passphrase, diversa, ovviamente, dalla passphrase che usate per proteggere la vostra chiave privata. Il vostro destinatario, per decriptare il file criptato
Ricordate che, se deciderete di eliminare il file originale:
non vi sarà più possibile recuperarlo, nel caso dimenticaste la passphrase di codifica / decodifica. Il problema: quanto sono affidabili le informazioni contenute in un certificato digitale? Grazie alla verifica dell'impronta digitale ( fingerprint ), io posso assicurarmi che il certificato digitale che ho ricevuto sia identico al certificato digitale originale, quello stilato direttamente dal suo proprietario. Avendo, poi, decriptato l'impronta digitale, contenuta nel certificato, usando la chiave pubblica di colui che ritenevo essere il proprietario del certificato, posso affermare che quell'impronta era stata criptata con la chiave privata di quest'ultimo. Ma, da qui a dire che tutte le informazioni che il proprietario del certificato digitale vi ha inserito siano vere ... ne passa! Il certificato digitale, per esempio, mi dice che il proprietario si chiama Gianfranco Gianfranchi, è residente a Roma ed è dipendente di una multinazionale molto nota. Sarà vero? Inoltre, anche se queste informazioni fossero vere, come posso sapere se quel Gianfranco Gianfranchi è davvero il proprietario del certificato digitale che ho appena ricevuto? Un altro signore, infatti, potrebbe avere generato quel certificato, utilizzando i dati di Gianfranco Gianfranchi ed io invierei le mie comunicazioni a quel signore, nella convinzione di inviarle a Gianfranco Gianfranchi. La soluzione: io vado a Roma, cerco il sig. Gianfranco Gianfranchi, lo incontro personalmente e gli chiedo se la firma digitale e l'impronta digitale che ho ricevuto siano di sua proprietà e se le informazioni contenute nel certificato digitali siano vere. La soluzione alternativa: visto che a Roma vive mio fratello, di cui mi fido ciecamente, chiedo a quest'ultimo di recarsi, lui, dal sig. Gianfranco Gianfranchi, per verificare di persona, al posto mio, la corretteza delle informazioni in mio possesso. Sarà, poi, mio fratello a confermarmi l'affidabilità del certificato digitale che ho ricevuto. Questa soluzione alternativa rappresenta l'essenza del cosiddetto "web of trust", o rete di fiducia. Ecco cosa accadrebbe nel nostro caso specifico: io apporrei la mia firma digitale al certificato digitale di mio fratello, dichiarando la mia piena fiducia nel suo certificato digitale. Mio fratello apporrebbe la sua firma digitale al certificato digitale di Gianfranco Gianfranchi, dichiarando la sua piena fiducia nel suo certificato digitale. La conseguenza di tutto ciò sarebbe che il certificato digitale di Gianfranco Gianfranchi verrebbe, da me, considerato degno di fiducia, perchè controfirmato da un utente, mio fratello, al quale io ho riconosciuto la mia piena fiducia, controfirmandone il certificato digitale. Una rete di fiducia si fonda sulla firma digitale apposta, da un utente, al certificato digitale di un altro utente, al fine di certificare di aver conosciuto personalmente il proprietario del certificato digitale e di averne potuto verificare le informazioni. Una volta controfirmato digitalmente il certificato digitale di un utente, è necessario inviare la firma al keyserver, in modo da renderla pubblica. Quella firma digitale avrà valore per tutti coloro che ne conoscono personalmente l'autore. Il grado di valore di quella firma digitale, inoltre, dipenderà dal grado di fiducia che ciascuno degli utenti riconoscerà al suo autore. Se sapessimo che il proprietario della chiave pubblica o l'autore di una firma digitale che ne attesti l'autenticità è noto per la facilità con cui rilascia firme digitali, senza verificare l'identità del proprietario della chiave pubblica che sta certificando, potremmo assegnargli un grado di affidabilità pari a zero: " nessuna ". Se, invece, conoscessimo il proprietario della chiave pubblica o l'autore di una firma digitale che ne attesti l'autenticità come un soggetto che conosce il meccanismo della firma di una chiave pubblica e lo utilizza in modo appropriato, potremmo assegnargli un grado di affidabilità " marginale ", a meno che si consideri la sua firma digitale al pari della nostra stessa firma, nel qual caso potremmo assegnargli un grado di affidabilità assoluto: " Completo ". E' possibile modificare il livello di affidabilità assegnato ad un utente, importando il certificato digitale dell'utente nel nostro file keyring ed utilizzando il sottocomando
All'interno del proprio file keyring, un certificato verrà considerato valido solo in due casi:
La fiducia esprime il grado di affidabilità che noi assegniamo all'autore di una firma digitale o al proprietario di un certificato digitale. Esistono 4 gradi di fiducia:
Il più alto grado di affidabilità ( definitiva ), naturalmente, viene assegnato ai propri certificati, la cui firma digitale è stata apposta da noi stessi. Si tratta dei nostri stessi certificati digitali, contenenti le chiavi pubbliche di cui noi conserviamo le corrispondenti chiavi private. Nel caso di chiavi pubbliche di altri, l'affidabilità assegnata al proprietario della chiave pubblica o all'autore di una firma digitale che ne attesti l'autenticità è, almeno inizialmente, " sconosciuta ". Senza un adeguato numero di firme digitali affidabili, una chiave ( ed il certificato che la contiene ) non è considerata valida. Affinchè una chiave pubblica venga considerata valida, da
oppure:
che, oltre a stampare a video le firme digitali apposte a ciascun certificato, le verifica:
I numeri da 0 a 3, quando presenti, nel secondo campo dell'output, indicano il grado di accuratezza applicato, dall'autore della firma digitale, al controllo sul possessore del certificato. E' un valore che può essere impostato in fase di creazione di una firma digitale:
Il simbolo "punto esclamativo" ( ! ) indica che la firma digitale è stata verificata con successo. Il simbolo "trattino" ( - ) indica che la firma digitale non è valida. Il simbolo "percentuale" ( % ) indica che la firma digitale non è stata verificata, a causa di un qualche problema intercorso ( per esempio: un algoritmo non riconosciuto ). Nel nostro esempio, le sole firme digitali presenti nel certificato di Juliusz Chroboczek sono le firme dello stesso proprietario, Juliusz Chroboczek. Quindi, in questo caso, o si conosce direttamente il sig. Juliusz Chroboczek, oppure non si dovrebbe prestare una grande attenzione al suo certificato digitale. Nel caso in cui il sig. Juliusz Chroboczek fosse il nostro vicino di casa, di cui ci fidassimo ciecamente, potremmo desiderare di apporre la nostra firma digitale al suo certificato digitale, per far sapere al mondo che noi ci fidiamo di lui e del suo certificato digitale. Per farlo abbiamo a disposizione il comando:
oppure la coppia di comandi interattivi:
Se volessimo impostare anche il livello di verifica che abbiamo potuto eseguire sul certificato che stiamo per firmare, utilizzeremmo l'ulteriore opzione:
Se il certificato contenesse più ID, come nel caso di Juliusz Chroboczek:
GPG vi chiederebbe se desiderate apporre la vostra firma digitale su tutti gli ID presenti. Potete decidere di firmare tutti gli ID del certificato, in un solo atto, oppure di attraversare ogni singolo ID e decidere, volta per volta, se apporre la vostra firma digitale a ciascuno di essi. In questo secondo caso, la procedura sarebbe leggermente diversa da quella usuale, ma la vedremo in seguito. Che fare, subito dopo aver apposto la propria firma digitale ad un certificato digitale di un altro utente? Invece di inviare il certificato digitale firmato al keyserver, come faremmo con un nostro certificato digitale, lo invieremo al proprietario del certificato digitale, in modo che possa essere lui ad inviarlo, aggiornato, al keyserver. Per poter inviare il certificato digitale appena firmato, dovremo, prima, esportarlo:
Se, invece, fossimo noi a ricevere, da un altro utente, il nostro certificato digitale, firmato dall'altro utente, dovremmo, prima, importarlo nel nostro file keyring:
e poi reinviarlo al keyserver:
Quando, in un certificato digitale, troviamo più ID, possiamo scegliere di apporre la nostra firma digitale solo su alcuni ID. Ciascun ID potrebbe essere identificato da un particolare indirizzo email. Il problema è il seguente: a ciascun ID, io dovrei inviare una copia del certificato digitale, che abbia la mia firma digitale solo in corrispondenza del suo ID specifico. Ciascun ID, infatti, ricevendo ciascuno la propria copia del certificato digitale, invierà quest'ultima al proprio keyserver di default. Il risultato finale sarà un certificato digitale con tutte le mie firme digitali. Per ottenere questo risultato, quindi, dovrò firmare un primo ID, inviare il certificato digitale, con la mia firma digitale, a questo primo ID, eliminare, dal mio file keyring, il certificato digitale appena firmato, scaricare, dal keyserver, una copia vergine dello stesso certificato digitale, che non contenga la mia prima firma digitale appena apposta, per poi apporre la mia firma digitale al secondo ID. E così via. In questo modo, il secondo ID non riceverà il certificato digitale con due mie firme digitali, la prima e la seconda, ma con la sola firma di sua competenza. Repetita iuvant: quando decidete di firmare digitalmente un certificato digitale di un terzo soggetto, tenete a mente che tutti coloro che vi conoscono e vi accreditano un elevato grado di affidabilità tenderanno a fidarsi del vostro giudizio e tratteranno il certificato digitale da voi controfirmato come se si trattasse del vostro certificato digitale. L'intera rete di fiducia di PGP si regge su questo assunto. Quindi, da una parte occorre ricordare che una firma digitale può essere apposta solo ed esclusivamente se si è conosciuto direttamente l'intestatario del certificato digitale che si desidera firmare e se si è potuto verificare, fisicamente ( facendoselo stampare, per esempio ) il valore dell'impronta digitale da lui detenuta, dall'altra che una firma digitale apposta ad un certificato digitale può avere senso, per ciascuno di noi, solo ed esclusivamente se siamo certi che si tratti della firma digitale di qualcuno che noi conosciamo direttamente e di cui ci fidiamo ciecamente. Su queste basi, è possibile costruire una comunità internet che abbia, nel suo insieme, un elevato grado di affidabilità, una comunità all'interno della quale si sarà sempre certi dell'identità del proprio interlocutore. Il comando
In questo esempio,
crea una firma digitale non esportabile ( locale ) e non utilizzabile da altri.
crea una firma non revocabile.
crea una firma " affidabile " ( trust ).
aggiunge un ID utente ( un nome, un indirizzo email, un commento ) ad una coppia di chiavi.
aggiunge una chiave subordinata ( subkey ) ad una coppia primaria di chiavi.
Mentre cancellare ID o chiavi subordinate dai certificati di soggetti terzi può essere utile, farlo sui propri certificati può complicare le cose per quanto riguarda la distribuzione delle chiavi. Quando un utente eseguirà l'importazione della vostra chiave pubblica aggiornata, infatti, il nuovo certificato scaricato dal server verrà fuso con il vecchio certificato, contenuto nel file keyring dell'utente. In questo modo, le informazioni che avete cancellato, verranno ripristinate, almeno nel file keyring dell'utente. A meno che l'utente, prima di recuperare, dal keyserver, il vostro nuovo certificato, elimini il vostro vecchio certificato dal suo file keyring. Per questi motivi, più che eliminare un ID o una chiave subordinata, è meglio revocarli. Per revocare una chiave subordinata, occorre prima selezionarla:
Per eliminare una o più firme digitali:
Non è possibile eliminare una firma digitale, quando è stata resa pubblica. Una firma digitale pubblica potrà solo essere revocata. Nel caso non aveste ancora inviato ai keyserver la vostra firma digitale, apposta ad un certificato digitale, è possibile eliminarla editando la chiave sulla quale si desidera operare:
selezionando, poi, l'utente su cui si desidera operare. Nel caso il certificato utente contenesse più utenti, ciascun utente sarà preceduto da un numero. Per selezionare un utente particolare, è sufficiente inserire quel numero. Nel caso il certificato digitale contenesse un solo utente, il numero utente da selezionare sarebbe 1:
A questo punto,
Ancora una volta: non eliminate le firme digitali che avete già inviato ad un keyserver, poichè sarebbe assolutamente inutile, visto che la vostra firma digitale sta già attraversando il mondo.
Per ciascuna firma digitale generata da una delle chiavi private, GnuPG chiede se generare un certificato di revoca.
Compatta gli ID utente non utilizzabili e rimuove le firme non utilizzabili dalla chiave.
Compatta gli ID utente non utilizzabili e rimuove tutte le firme dalla chiave. Per modificare la data di scadenza di una coppia di chiavi:
Se non viene selezionata alcuna sottochiave, viene modificata la data di scadenza della chiave primaria. Per passare dalle chiavi pubbliche alle corrispondenti chiavi private e viceversa, eseguire l'opzione:
dove " sec " indica la chiave privata primaria, mentre " ssb " indica le chiavi private subordinate.
Per eseguire la firma digitale di un documento, eseguite:
oppure:
oppure:
Attenzione: oltre alla creazione del valore di hash ( che verrà criptato con la vostra chiave privata ) del contenuto del file, verrà eseguita anche una compressione del file stesso, che sarà, poi, salvato, nel file di output, in formato binario. Se desiderate indicare una chiave privata diversa, utilizzate uno dei due comandi:
Se non si desidera la compressione, usare:
per salvare la firma in formato ASCII.
Per ottenere la firma digitale in un file separato ( detached ) dal documento da firmare, usare:
per il formato binario, oppure:
per il formato ASCII. Se, oltre alla firma digitale, si desidera la cifratura del file, con chiave pubblica oppure chiave simmetrica:
Nel caso della cifratura a chiave pubblica, è possibile selezionare l'ID della chiave privata da utilizzare per la firma digitale (
Per farlo, naturalmente, dovremo avere importato la chiave pubblica del mittente, con la chiave privata del quale è stato criptato il valore di hash del contenuto del file. Per verificare una firma digitale, distinta dal file ( detached ):
Se il file è stato anche criptato e lo si vuole decifrare e verificare:
|
|||||||
I comandi Linux: la crittografia: GPG | Le guide di .bit: contenuto originale |