 |
|
Guida GnuPG Gentoo 1.Introduzione Cosa si troverà in questa guida Questa guida presuppone che l'utente abbia una certa familiarità con la crittografia a chiave pubblica e la firma digitale. Per un'introduzione a questi argomenti leggere il capitolo Crittografia a chiave pubblica o dare una occhiata al GnuPG handbook , capitolo 2, e ritornare qui. La guida descrive come installare GnuPG, come creare una coppia di chiavi, come aggiungere delle chiavi al proprio portachiavi, come inviare la propria chiave pubblica al KeyServer e come firmare/criptare e verificare/decriptare i messaggi inviati/ricevuti. Si imparerà anche come criptare i file del proprio pc per evitare che altre persone ne leggano il contenuto. Installazione del software necessario Al livello base è necessario installare il pacchetto principale con un emerge gnupg. Molte applicazioni oggi hanno qualche tipo di supporto per gpg, quindi avere crypt nella propria variabile USE è probabilmente una buona idea. Se si vuole un client email che utilizzi gnupg è possibile usare pine (installandolo mediante emerge pinepgp), mutt (installandolo mediante emerge mutt), Mozilla/Netscape Mail, Evolution (che è un clone di Microsoft Outlook per GNOME) oppure il client di KDE: KMail (Kmail fa parte del pacchetto kdepim). Se si utilizza KDE, potrebbe interessare Kgpg; questo piccolo programma permette di generare coppie di chiavi, importare chiavi da file ASCII, firmare le chiavi importate, esportare chiavi ed altro. 2.Generazione della propria chiave ed aggiunta delle chiavi al proprio portachiavi pubblico Creazione della propria chiave Per creare propria chiave, semplicemente basta eseguire gpg --gen-key. Il comando la prima volta che viene eseguito crea alcune directory, in seguito è necessario rilanciarlo per creare le chiavi:
A questo punto si ha la possibilità di scegliere il tipo di chiave. La maggior parte degli utenti può utilizzare il tipo predefinito, DSA e ElGamal. Il punto successivo riguarda la scelta della dimensione della chiave: una chiave grande è preferibile, ma è importante ricordare di non utilizzare chiavi più grandi di 2048 con DSA/ElGamal. Normalmente 1024 è più che sufficiente per una normale l'email. Dopo la dimensione viene richiesta la data di scadenza. Una chiave di breve durata è preferibile, ma la maggior parte degli utenti può sceglierne una che non scade mai, oppure con scadenza di 2 o 3 anni.
Ora è necessario inserire alcune informazioni personali. Se si ha intenzione di inviare la propria chiave pubblica ad altre persone si deve inserire qui il proprio vero indirizzo.
Ora è necessario inserire due volte la password per la propria chiave. E' buona norma utilizzare una password non banale. Se qualcuno dovesse mai entrare in possesso della chiave privata e forzare la vostra password, sarebbe in grado di inviare messaggi firmati a vostro nome, che chiunque potrebbe ritenere spediti da voi. GnuPG a questo punto creerà la vostra chiave. Muovere il mouse o ascoltare un mp3 in background velocizzerà il processo di generazione poichè verranno generati dati casuali. Creare un certificato di revoca
Dopo la creazione delle proprie chiavi dovreste creare un certificato di revoca. Fare questo vi permetterà di revocare le vostre chiavi nel caso in cui capiti qualcosa di spiacevole (qualcuno è entrato in possesso della vostra chiave/password).
Il comando gpg --list-keys elenca le chiavi presenti nel proprio portachiavi pubblico. E' possibile utilizzarlo per vedere l'ID della propria chiave così come è necessario per creare il certificato di revoca. Ora è una buona idea copiare l'intera directory .gnupg ed il certificato di revoca (in ASCII criptato - revoke.asc) in un dispositivo sicuro (due floppy o un CD-R da conservare in un luogo sicuro). Ricordate che revoke.asc può essere utilizzato per revocare le tue chiavi e renderle inutilizzabili in futuro.
Per esportare la propria chiave, digitate gpg --armor --output john.asc --export john@nowhere.someplace.flick. Si può usare quasi sempre l'ID della chiave o qualcos'altro che la identifichi (qui è usato un indirizzo email). Ora John ha a disposizione un john.asc che può mandare agli amici, o mettere nella sua home page in modo che le persone possano comunicare con lui in modo sicuro. Per aggiungere un file al proprio portachiavi pubblico, si deve prima importarlo, quindi controllare il fingerprint(impronta digitale) della chiave. Dopo averlo verificato si dovrebbe validarla.
Ora, come esempio, si aggiungerà la chiave pubblica di Luis Pinto (mio amico) al nostro portachiavi pubblico. Dopo averlo contattato per ottenere da lui il fingerprint della sua chiave, lo si confronterà con l'output del comando fpr. Poichè la chiave è autentica, la si aggiungerà al portachiavi pubblico. In questo caso, in particolare, la chiave di Luis scadrà il 2003-12-01, per cui viene richiesta la possibilità di fare in modo che la vostra firma sulla sua chiave scada lo stesso giorno.
3.Scambiare le chiavi con i KeyServer Invio delle chiavi ai KeyServer Ora che si possiede la propria chiave, è una buona idea inviarla ai KeyServer mondiali. Ci sono molti KeyServer nel mondo e la maggior parte si scambiano le chiavi tra loro. Ora si manderà la chiave di Luis al server subkeys.pgp.net. Questo server utilizza HTTP, quindi se si ha bisogno di utilizzare un proxy per il traffico HTTP non bisogna dimenticare di impostarlo (utilizzando il seguente comando export http_proxy=http://proxy_host:port/). Il comando per inviare la chiave è il seguente: gpg --keyserver subkeys.pgp.net --keyserver-options honor-http-proxy --send-key 75447B14 dove 75447B14 è l'ID della chiave. Se non si ha bisogno di un proxy HTTP si può rimuovere l'opzione --keyserver-options honor-http-proxy. E' inoltre possibile mandare al KeyServer anche le chiavi di altre persone dopo averle firmate. Si potrebbe mandare la chiave di Luis Pinto al KeyServer. In questo modo qualcuno che si fida della nostra chiave potrebbe usare la firma che è stata apposta per ritenere fidata anche la chiave di Luis. Recupero delle chiavi dai KeyServer Ora, per esempio, si andrà a cercare la chiave di Gustavo Felisberto e la si aggiungerà al portachiavi di John Doe (nel caso in cui non lo si avesse notato, Gustavo Felisbero è la persona che ha scritto questa guida :-) ).
Come si può vedere dalla risposta del server, sono state inviate diverse chiavi al KeyServer, ma al momento è utilizzata solo B9F2D52A. Ora John Doe può scaricarla e firmarla, se la ritiene fidata. 4.Utilizzo di un agente GPG Ci sono situazioni, quando si lavora con certe applicazioni, in cui l'utilizzo delle chiavi GPG è assai frequente, ciò significa che si dovrebbe digitare la propria password molto spesso. In passato molte applicazioni utilizzavano un meccanismo di cache per salvare temporaneamente la password. Questi meccanismi non era condivisi con le altre applicazioni per ragioni di sicurezza, e ogni programma doveva inventarsi il proprio meccanismo. Un Agente GPG è un'applicazione separata che GPG usa per salvare la password temporaneamente in cache in maniera standard e sicura. Esso permette a diverse applicazioni di usare GPG contemporaneamente: se si inserisce la password in un'applicazione non sarà necessario digitarla nuovamente per l' altra applicazione: ovviamente se l'agente è configurato in maniera tale da permetterlo. Gentoo fornisce diversi agenti GPG. app-crypt/gpg-agent può essere considerato come quello di riferimento, che verrà illustrato in questo documento. Installazione e configurazione di gpg-agent e pinentry E' ovviamente necessario installare gpg-agent, e inoltre pinentry, che è l'applicazione di supporto a gpg-agent per richiedere la password in una finestra grafica. Può lavorare in tre modi: con una finestra a popup che usa le librerie gtk+, le Qt, o curses (a seconda delle flag di USE attive al momento della sua compilazione).
Ora bisogna creare un file ~/.gnupg/gpg-agent.conf e inserite le seguenti righe che definiscono il tempo di timeout della password (ad esempio 30 minuti) e l'applicazione che deve essere richiamata quando viene richiesta la password (ad esempio la versione Qt di pinentry).
Ora si configuri GnuPG perchè utilizzi l'agente quando necessario. Modificare ~/.gnupg/gpg.conf aggiungendo la linea seguente:
Ora il sistema è quasi pronto per usare l'agente GPG. Se si utilizza KDE come ambiente grafico, modificate il file /usr/kde/3.x/env/agent-startup.sh (per l'intero sistema) o ~/.kde/env/gpgagent.sh (per il solo utente locale) e aggiungere il seguente comando per far in modo che KDE avvii automaticamente l'agente GPG:
Se si utilizza un altro ambiente grafico, inserire la stessa linea sopracitata in ~/.xinitrc (se si utilizza startx) o ~/.xsession (se si utilizza XDM/GDM/KDM/...). 5.Lavorare con documenti Adesso si supponga di avere un file che si desidera inviare a Luis. Lo si può criptare, firmare o criptare e firmare. Criptare significa che solo Luis sarà in grado di aprirlo. La firma conferma a Luis che siete stati proprio voi a creare il file. I seguenti comandi fanno esattamente questo: criptano, firmano e criptano/firmano.
Questa procedura crea file binari. Se si vuole creare file ASCII si aggiunga --clearsign all'inizio del comando. Decriptare e verificare le firme Supponiamo che si abbia ricevuto un file criptato con la propria chiave pubblica. Il comando per decriptarlo è gpg --output document --decrypt encrypted_doc.gpg. Questo decripterà il documento e verificherà la firma (se ne esiste una). Ci sono alcune utili caratteristiche avazate in GnuPG. Per trovarle, si apra il file ~/.gnupg/gpg.conf.
Si cerchino le due linee qui sopra e le si decommentino. Con queste opzioni, ogni volta che GnuPG dovrà verificare una firma e non troverà la corrispondente chiave pubblica nel portachiavi locale, contatterà il KeyServer all'indirizzo subkeys.pgp.net e cercherà di recuperarne una da quella locazione. Un'altro comando utile è gpg --refresh-keys. Il programma eseguito con tale opzione contatterà il KeyServer definito nel file di impostazioni ed aggiornerà le chiavi pubbliche presenti nel portachiavi locale, cercando chiavi revocate, nuovi id e nuove firme sulle chiavi. E' opportuno eseguire questo comando una o due volte al mese, in modo da sapere se qualcuno revoca la propria chiave. 6.Interfaccie a GnuPG Il 95% delle volte si userà GnuPG con l'email per firmare/criptare i messaggi in uscita e per leggere messaggi firmati/criptati. Quindi è sufficiente introdurre solo questi casi. Esistono due modi per firmare/criptare una email con GnuPG, il vecchio modo ed il nuovo modo :-). Con il primo metodo i messaggi appaiono in semplice testo, senza la possibilità di formattazione e con file allegati non firmati / non criptati. Ecco un esempio di un messaggio firmato in tale maniera:
Al giorno d'oggi, inviare messaggi in questo modo non è assolutamente una buona idea, visto che esistono ottime interfacce grafiche e client email che gestiscono i tag html. Per risolvere il problema è stata creata un'estensione a MIME (Multipurpose Internet Mail Extensions). Un nuovo campo dell'email indica al client che l'intero contenuto del messaggio è firmato e/o criptato. Il problema di questa soluzione è che non è supportata da tutti i client email: alcuni fanno persino pasticci con il contenuto, come Outlook di Microsoft, famoso per non funzionare bene con questo metodo. Kpgp è una interfaccia grafica carina per GNUPG. Nella schermata principale è possibile incollare il testo che si vuole firmare o criptare oppure incollare il testo ASCII criptato che si vuole decriptare.
In questa immagine si può vedere la schermata principale di Kgpg con del testo criptato incollato. Da qui è possibile decriptarlo (sarà richiesta la propria password), criptare altri file, incollare dell'altro testo da firmare...
Qui si può vedere la schermata di gestione delle chiavi. Vediamo la nostra bella chiave per John Doe, le due chiavi fidate per Gustavo e Luis e la chiave non fidata per Daniel Robbins (non è ancora stato chiamato per controllare il suo fingerprint :-) ). Seahorse aspira a diventare un frontend grafico di GnuPG per Gnome. Questo programma si sta evolvendo in fretta, ma non dispone ancora di importanti caratteristiche presenti in Kpgp o nella versione a riga di comando. Mozilla dispone, dalla versione 1.0, di Enigmail, un plugin per il client email che è molto semplice da configurare. Si deve semplicemente andare in Preferences -> Privacy & Security -> Enigmail, dove è necessario inserire la propria chiave per l'email. I messaggi che arrivano con una firma pgp o gpg non fidata vengono contrassegnati con una penna rotta. Quelli che hanno una firma valida appariranno con una penna tutta intera. Enigmail può anche recuperare le chiavi dai KeyServer, ma in caso di problemi, stampa alcuni strani messaggi di errore (ma in questo casi ci si ricorda ancora della linea di comando, giusto?). Se è stata impostata la USE flag crypt, KMail sarà compilato con il supporto per gpg, e sarà pronto per crittografare e decrittografare email con PGP automaticamente, oltre a offrire la possibilità di crittografare email OpenPGP/MIME. Se si vuole decrittografare email OpenPGP/MIME, si deve avere un agente GPG configurato. (Si veda Utilizzo di un agente GPG) Si può verificare che KMail sia correttamente configurato entrando in Impostazioni, Configura KMail, Sicurezza, Backend Crittografici. Si dovrebbe vedere un backend basato su GpgME e si dovrebbe poter attivare la casella su OpenGPG. Se il suddetto backend è presente ma è segnato in grigio, si faccia click su Riesegui scansione. Se il backend GpgME resta grigio vuole dire che KMail non sta funzionando a dovere. Questo è il client email che utilizza l'autore. E' molto veloce con caselle di posta grandi, dispone di tutte le caratteristiche desiderabili in un client e funziona perfettamente con gpg. L'unico problema è dato dal fatto che non funziona con le vecchie firme PGP, quindi se si riceve una mail di quel tipo si dovrà verificare a mano la firma. Per usare la propria chiave gpg con Sylpheed-Claws bisogna entrare nella configurazione dell'account ed cliccare sulla casella privacy. Da lì è possibile scegliere quale chiave utilizzare. Probabilmente la maggior parte degli utenti dovrà scegliere la chiave di default. 7.Crittografia a chiave pubblica Le basi della crittografia a chiave pubblica Il concetto di crittografia a chiave pubblica fu originariamente dovuto a Whitfield Diffie e Martin Hellman (1976). Quando l'autore senti per la prima volta, nel '93, le parole "chiave pubblica" e "crittografia" nella stessa frase, pensò che una cosa del genere fosse impossibile. A quei tempi non esisteva Internet (in realtà esisteva, ma non era alla portata di tutti), quindi andò in biblioteca e chiese alcuni libri sulla crittografia. All'epoca aveva 16 anni e l'addetto allo sportello lo guardò con stupore e gli portò alcuni libri per bambini sui cifrari per sostituzione (quelli in cui avvengono semplici sostituzioni di lettere, come il famoso Cifrario di Cesare o il ROT-13 (Tragbb Ebpxf, naq lbh xabj vg vf tbbq orpnhfr lbh ner ernqvat guvf qbp.), (Si faccia emerge rotix se non si è in grado di decifrare questa frase)). Essendo frustrato per l'accaduto, cominciò a ricercare maggiori informazioni. E' bello avere matematici in famiglia, perchè appena ebbe l'occasione di parlare con uno di loro, fu proiettato in un nuovo mondo. Ed ora un po' di matematica:
Se si da il numero 35 e si afferma che questo numero è il prodotto di due numeri primi, è facile scoprire che tali numeri sono 5 e 7. Ma se si chiede la stessa cosa per 1588522601 ci vorrà un bel po' di tempo (o di cicli di CPU) per scoprire che si tratta del prodotto di 49811*31891. E se il numero è davvero grande, questo compito diventa "impossibile". A questo punto se si comunica al mondo il proprio grande numero, che si sa essere il prodotto di due primi, si sa qualcosa di quel numero che non è noto a nessun'altro. Questa è la base delle moderne implementazioni di Crittografia a Chiave Pubblica (PKC). Come (irrealistico) esempio, si dia a chiunque il proprio numero e qualcuno lo userà per cifrare un messaggio per voi. Tutti possono vedere il messaggio cifrato perchè voi siete gli unici a conoscere la scorciatoia per leggerlo; gli altri dovrebbero prima "scomporre" quel grande numero per essere in grado di leggere il messaggio, ed è un "fatto" l'impossibilità di farlo in un lasso di tempo ragionevole (con i metodi odierni e i più veloci computer al mondo ci vorrebbero migliaia di anni). In questa ipotesi, i due grandi numeri primi sono chiamati la CHIAVE PRIVATA, mentre il grande numero non primo è la CHIAVE PUBBLICA. Questo non corrisponde al 100% con quanto avviene in realtà, ma può rendere bene l'idea ad un nuovo utente. Per maggiori informazioni si veda hack.gr per quanto riguarda il protocollo Diffie-Hellman. Per approfondire ulteriormente andate in biblioteca e prendete una copia di "Handbook of Applied Cryptography" di Alfred J. Menezes, Paul C. van Oorschot e Scott A. Vanstone, disponibile anche gratuitamente online all'indirizzo qui sopra. Una conseguenza di quanto detto fino a questo punto è che se si cifra un messaggio per voi e si perde il messaggio originale non cifrato, non si sarà in grado di risalire all'originale dalla versione cifrata. Abbiamo già visto come chiunque in possesso della nostra chiave pubblica possa mandare un messaggio cifrato. Ma come possiamo verificare che l'autore del messaggio è veramente chi dice di essere? O, in altre parole: se si riceve una email da voi come si può sapere davvero che è stata inviata da voi e non da qualcun altro che sostiene di essere voi? Ricordate quando si è detto che la PKC non è così semplice? L'idea è che quando si cifra un messaggio per una persona, lo si può anche firmare con la propria chiave privata in modo che, quando lo si riceve, la persona possa a sua volta utilizzare per prima cosa la vostra chiave pubblica per verificare la firma e, quindi, la sua chiave privata per decifrare il messaggio. Come si può vedere non sarebbe possibile fare questo nell'ipotesi di prima. Altra cosa molto importate: per firmare i messaggi non è necessario cifrarli. Si può creare un messaggio leggibile da chiunque, ma con il proprio "marchio". E se un solo carattere del messaggio viene modificato, tale manomissione può essere rilevata. Ora supponiamo che si non abbia avuto contatti con voi fino a quando non avete mandato un messaggio a una persona: come può questa persona avere la vostra chiave pubblica, e come può sapere se è veramente la vostra? Per risolvere questo problema sono stati creati i key server pubblici. Quando si crea la propria coppia di chiavi (pubblica e privata), si può inviare la propria chiave pubblica al key server. A questo punto tutti possono scaricare la vostra chiave da lì. Ma come si può sapere che quella chiave è la chiave dell'autore del messaggio? Per questo bisogna introdurre un altro concetto: la firma della chiave. Firmare la chiave significa che, se si ha la chiave pubblica di un'altra persona e si sa con certezza che è davvero la chiave di quella persona (perchè è un amico, qualcuno che conosco di persona, ecc.) si può firmare quella chiave pubblica e mandarla ai Key Kerver, in modo da dire al mondo: "Questa chiave appartiene davvero alla persona che sostiene gli appartenga". In questo modo le persone che hanno la vostra chiave pubblica e si fidano di voi possono usare questa fiducia per ritenere fidate le chiavi di altri. Questo meccanismo può confondere, quindi vediamo un esempio reale. Immaginiamo una situazione con 3 persone: John, Mary e Lisa. John è un buon amico di Mary, ma non conosce Lisa; Lisa è una buona amica di Mary, ma non conosce John. Un giorno Lisa manda a John una email firmata. John recupererà la chiave pubblica di Lisa dal KeyServer, verificherà il messaggio e, se è tutto a posto, saprà che chiunque abbia scritto quel messaggio ha anche creato quella chiave. Ma come può sapere che è effettivamente la persona che dice di essere? A questo punto John vede la firma di Mary sulla chiave, che può verificare perchè dispone già della chiave di Mary e la ritiene fidata. Grazie a questo anello di fiducia egli conclude che l'email ricevuta è stata realmente scritta da Lisa. Ora si è veramente pronti per leggere questa guida, tornate indietro al capitolo 1 ed imparate a usare gpg. 8.Epilogo e ringraziamenti Si sono avuti alcuni problemi con foto inserite nelle chiavi. Controllate la versione che state utilizzando. Se si ha GnuPG 1.2.1-r1 e superiori non ci dovrebbero essere problemi. In ogni caso, la maggior parte dei KeyServer non gradisce chiavi con foto, quindi meglio non utilizzarle. L'ultima versione di GnuPG sembra non funzionare con il comando gpg --send-keys, che viene utilizzato per mandare tutte le chiavi presenti nel portachiavi al server pubblico. Gpg è uno strumento molto complesso e permette di fare molto di più rispetto a quanto è stato trattato qui. Questo documento è stato concepito per i nuovi utenti GnuPG. Per maggiori informazioni, si veda il sito di GnuPG. Non sono stati trattati altri strumenti come pgp4pine, gpgpine, Evolution e gli strumenti per Windows; probabilmente si amplierà questo documento in futuro. Il GnuPG Handbook di John Michael Ashley è un ottimo libro per i principianti. Swift (Sven Vermeulen) per aver spinto a ri-scrivere questo documento. I fantastici ragazzi del canale #gentoo-doc. Tiago Serra per avermi riportato sulla via della privacy. |
|
