Keyserver PGP
Da Security e-Book.
Indice |
Introduzione
La privacy e la confidenzialità delle informazioni sta diventando sempre più un argomento importante all'interno delle aziende, siano esse piccole o grandi. Nella prima parte di questo articolo, adatto anche ad un pubblico non tecnico, l'autore paragona brevemente l'architettura PGP ed i certificati SSL (X.509). Nella seconda parte vengono dati spunti su come realizzare un archivio centralizzato di chiavi PGP (Keyserver) nella propria azienda.
Parlando con i clienti si riscontrano spesso problemi relativi alla privacy, ad esempio delle e-mail aziendali o dei files su disco. Sebbene la crittografia SSL ed in particolare i certificati X.509 si stiano largamente diffondendo, essi rimangono comunque legati ad un concetto gerarchico basati sulla “fiducia” di una Certification Authority che mette “il bollino di garanzia” sui certificati. Non sempre però le Certification Autorities verificano l'identità del richiedente e spesso in alcune realtà aziendali l'utilizzo di forme gerarchiche aumenta la complessità di gestione. Sebbene inventato nel 1991 prima di X.509, PGP adotta un concetto di peer-2-peer che -a mio avviso- semplifica spesso la gestione della crittografia non solo all'interno della propria azienda, ma anche tra individui e entità diverse tra loro, pur mantenendo alti standard di sicurezza. PGP si basa infatti sullo stesso meccanismo a chiave pubblica/privata (RSA, IDEA e altri) su cui è basato anche la crittografia X.509.
Personalmente apprezzo in PGP la possibilità di criptare un testo o un file con più di una chiave, ad esempio utilizzando -oltre alla propria- anche una chiave di sicurezza che viene tenuta in un CD in cassaforte (o un key recovery agent). Prendiamo il seguente esempio complesso che mi è stato sottoposto da un importante ente pubblico. Il presidente vuole criptare alcuni files, ma vuole contemporaneamente farne un backup in caso di smarrimento/furto del portatile, e vuole far si che se viene persa la smartcard possa sempre recuperare il file. L'utilizzo della crittografia del disco non proteggerebbe il file in caso di backup su un server, e lo smarrimento della smart card o della password renderebbe inutilizzabile il portatile e i documenti in essa contenuti. PGP può aiutarci in questo esempio perche la crittografia viene applicata a livello di file (quindi protegge anche il file sul server) e un eventuale smarrimento della smartcard può essere sopperita utilizzando il CD di emergenza in cassaforte. L'utilizzo quindi di una infrastruttura basata su PGP permette a tutte le aziende, dalla più piccola alla più grande, di mantenere un alto standard di qualità di sicurezza. Qualora l'azienda cominci ad avere un numero significativo di utenti che utilizzano la tecnologia PGP, conviene creare un repository interno di chiavi, che nella terminologia PGP si chiama keyserver.
Realizzeremo un keysever PGP utlilizzando Linux (Fedora) e OpenLDAP. Questa stessa configurazione può essere implementata con qualsiasi distribuzione Linux (o Unix) e un directory server. Per gli utilizzatori di Fedora Directory Server, esistono degli script1 in grado di convertire i formati qui proposti nel formato LDIF accettato dal programma.
Configurazione del server
Non ci soffermeremo sull'installazione dei pacchetti e del software di base, incluso il sistema operativo. Una volta installato il server OpenLDAP, dovremmo agire sul file di configurazione slapd.conf. Nell'esempio di seguito, manterremo inalterato lo scheletro del file di configurazione così come appare in Fedora, ma ne modificheremo le sezioni di inclusione di file di schema, il database che conterrà i dati LDAP e le Access Control List (ACL). Prima di procedere, è necessario scaricare lo schema che utilizzeremo nel server LDAP dal seguente link: http://www.gpaterno.com/publications/2007/pgp-keyserver.schema.
Il file pgp-keyserver.schema va copiato nella directory dove già si trovano gli schema files (/etc/openldap/schema) e successivamente incluso nel file di configurazione slapd.conf come segue:
include /etc/openldap/schema/pgp-keyserver.schema
Il passo successivo è impostare in slapd.conf il database del server LDAP, il suffisso dello schema LDAP e l'account di Management del server LDAP. Ad esempio, ammettiamo di avere il dominio “azienda.it”, definiremo il suffisso di LDAP come “dc=azienda, dc=it” e come account di management “cn=Manager,dc=azienda,dc=it” con password “password”:
database bdb suffix "dc=azienda,dc=it" rootdn "cn=Manager,dc=azienda,dc=it" rootpw password
La password specificata in “rootpw” e' stata inserita in chiaro. In un ambiente di produzione è suggeribile usare una password protetta, che va generata con il comando slappasswd. L'output di questo comando (es: {SSHA}xxxxxxxxxx) va inserito nel campo “rootpw”. Inseriamo quindi gli indici appositi per il keyserver PGP come dall'esempio successivo:
index pgpCertID,pgpKeyID,pgpKeyType,pgpUserID,pgpKeyCreateTime sub,eq index pgpSignerID,pgpSubKeyID,pgpKeySize,pgpKeyExpireTime sub,eq index pgpDisabled,pgpRevoked eq
Qualora sia già disponibile un LDAP con un database esistente, queste stesse vanno aggiunte a quelle indicate nel file di configurazione. Come accennato in precedenza, è suggeribile proteggere il database da scritture anonime impostando della ACL. Di default, infatti, un utente qualsiasi -senza registrarsi- può mandare le chiavi PGP. In un'azienda sarebbe preferibile controllare chi possa inviare le chiavi PGP nel keyserver. Un esempio potrebbe essere abilitare tutti gli utenti che abbiamo inserito nella Organizational Unit (OU) “Users”:
access to dn.subtree="ou=PGP Keys,dc=azienda,dc=it" by dn.regex="cn=([^,]+),ou=Users,dc=azienda,dc=it" write by * read
Un altro esempio potrebbe essere l'abilitazione del Directory Manager o la persona che svolge la funzione di Security Officer ad inserire e modificare le chiavi:
access to dn.subtree="ou=PGP Keys,dc=azienda,dc=it" by dn="cn=Manager,dc=azienda,dc=it" write by dn=”cn=Security Officer, ou=Users, dc=azienda, dc=it” write by * read
Ovviamente le Access Control List vanno adattate alle esigenze della propria azienda e non esiste una “ricetta magica” che vale per tutti. Continuando nel nostro setup, dobbiamo inizializare il database di OpenLDAP prima di avviare il server stesso. Utilizzeremo il comando slapadd che permette di inserire dati direttamente nel database berkley senza passare dal server. Di solito si inseriscono almeno due entries: una che caratterizza il Base DN (dc=azienda, dc=it) e una che caratterizza il Manager del database. Nell'esempio sottostante si riferiscono alle prime due entries. Le seconde due, invece, sono relative al keyserver PGP. Rispettivamente la prima è l'Organizational Unit che ospiterà le chiavi PGP, la seconda serve ai client GPG/PGP per ottenere informazioni sul keyserver stesso. Per comodità creeremo un file di appoggio /tmp/init.ldif che conterrà lo scheletro del database:
dn: dc=azienda,dc=it objectClass: dcObject objectClass: organization o: azienda dc: azienda dn: cn=Manager,dc=azienda,dc=it objectClass: organizationalRole cn: Manager dn: ou=PGP Keys,dc=azienda,dc=it objectclass: organizationalUnit ou: PGP Keys dn: cn=PGPServerInfo,ou=PGP Keys,dc=azienda,dc=it cn: PGPServerInfo objectclass: pgpserverinfo pgpSoftware: OpenLDAP pgpVersion: 2.2.29 pgpBaseKeyspaceDN: ou=PGP Keys,dc=azienda,dc=it
A questo punto possiamo inizializzare il database con il comando slapadd -l /tmp/init.ldif. Il comando slapcat ci sarà utile per visualizzare le entries che abbiamo immesso e controllarne la correttezza. Possiamo avviare il servizio LDAP con il comando service ldap start. Guardiamo i messaggi di syslog nel file /var/log/messages per vedere se il servizio sia stato inizializzato correttamente. A questo proviamo il nostro nuvo server ldap, ad esempio con la query LDAP:
$ ldapsearch -h keyserver -b "dc=azienda,dc=it" -s sub -x -W -D "cn=Manager,dc=azienda,dc=it" objectclass=*
Il risultato del comando visualizza il contenuto dell'intero database di slapd (objectClass=*), comando che ci potrà essere di aiuto in caso di troubleshooting. Il parametro -h determina il nome dell'host, -b il Base DN, -s indica lo scopo della ricerca (in questo caso è subtree, ovvero in tutta l'alberatura LDAP), -x è un autenticazione di tipo base, -W (maiuscolo!) indica che deve essere richiesta la password e infine -D indica l'utente con cui effettuare il collegamento
Invio delle chiavi PGP/GPG
Possiamo già provare a inviare le nostre chiavi PGP attraverso la riga di comando. Negli esempi successivi utilizzeremo il programma GnuPG, ma per differenti implementazioni di PGP è necessario consultare il manuale del proprio vendor. Da un utente proveremo quindi ad effettuare il comando:
$ gpg --keyserver ldap://keyserver --keyserver-option verbose \ --keyserver-option "binddn=cn=Manager,dc=azienda,dc=it" \ --keyserver-option bindpw=password \ --send-keys ABCD1234
Il comando precedente indica di inviare la chiave PGP con l'identificativo “ABCD1234” collegandosi al keyserver LDAP “keyserver” utilizzando le credenziali LDAP di “cn=Manager,dc=azienda,dc=it” e la password password.
L'utilizzo della riga di comando potrebbe essere utile per l'invio delle chiavi da parte di una persona di fiducia (il “Security Officer”) che verifica la corrispondenza tra persona fisica e chiavi digitali.
Configurare il client
Una volta inviate le chiavi, possiamo configurare il client in modo che vada ad interagire con il nostro server LDAP in maniera automatica. Sulla riga di comando Linux, è sufficiente inserire le seguenti righe nel file ~/.gnupg/gpg.conf:
keyserver ldap://keyserver keyserver-options tls=try keyserver-options basedn="cn=PGPServerInfo,ou=PGP Keys,dc=garl,dc=it"
Da un altro utente, una volta configurato il gpg.conf, possiamo provare a scaricare la chiave che abbiamo appena inviato. Assumendo che abbiamo inviato la chiave del sig. Mario Rossi con e-mail mario.rossi@azienda.it, eseguiremo il seguente comando:
$ gpg --search-keys mario.rossi@azienda.it
gpg: searching for "mario.rossi@azienda.it" from ldap server keyserver
(1) Mario Rossi <mario.rossi@azienda.it>
1024 bit RSA key ABCD1234, created: 2006-12-16
Keys 1-1 of 1 for "mario.rossi@azienda.it". Enter number(s), N)ext, or Q)uit > 1
gpg: requesting key ABCD1234 from ldap server keyserver
gpg: key ABCD1234: public key "Mario Rossi <mario.rossi@azienda.it>" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
Et voilà, il nostro nuovo keyserver è pronto. Adesso possiamo configurare Thunderbird o Microsoft Outlook con l'apposito plugin per poter utlizzare la crittografia delle e-mail, o utilizzare altri applicativi -come l'estensione per Windows Explorer- per criptare i files su disco. Vediamo qualche esempio su come configurare il nostro nuovo Keyserver su GNOME, Thunderbird e Windows (con WinPT). GNOME incorpora un'applicazione di gestione chiavi PGP e SSH, cui nome è Seahorse. Se installata, si presenta nel menù sotto “Accessories->Password and Ecnryption Keys”. Per configurare il nostro keyserver usare “Edit->Preferences” e nel tab “Key Servers” inserire il nuovo keyserver con il pulsante “Add” e poi selezionare “LDAP Key Server”, inserire il nome host (nel nostro caso “keyserver”) e la porta, ovvero 389 come in Figura 1.
Thunderbird
Per configurare Thunderbird, è necessario scaricare il plugin Enigmail dal sito http://enigmail.mozdev.org ed installarlo come un normale add-on di Thunderbird. Questo add-on funziona sia con Linux, Windows, Mac e molte altre piattaforme, rappresentando un ottimo tool per la posta elettronica. Dal menù “OpenPGP->Preferences” selezioniamo la checkbox “Display Expert Settings”. Questa opzione abiliterà ulteriori tabs, tra cui anche il tab “Keyserver”. Inseriamo quindi il nostro server LDAP nella forma “ldap://keyserver” come da Figura 2.
Possiamo ora provare a ricercare una chiave dal menù “OpenPGP->Key Management” e poi selezionando “Keyserver->Search for keys”. Un esempio di risultato di ricerca è presente in Figura 3
.
Microsoft Windows e Outlook
L'ultimo esempio che voglio proporvi è quello reallizzato con gpg4win, un'ottima distribuzione di GPG per Windows, ma che ha una particolarità. Anche se il programma GPG per l'ambiente Windows funziona come l'analogo programma per Linux, l'applicativo WinPT -che funge da keymanager- non riesce a riconoscere in modo corretto le entries PGP nel nostro LDAP. E' necessario aggiungere una entry in più nel nostro LDAP in caso si voglia interagire con l'ambiente WinPT. Utilizzeremo la stessa tecnica usata per inizializzare il server ldap, ovvero usando il comando slapadd. Fermiamo il servizio ldap con service ldap stop e creiamo un file temporaneo, es: /tmp/winpt.ldif. Lo popoliamo come segue:
dn: cn=PGPServerInfo,dc=azienda,dc=it cn: PGPServerInfo objectclass: pgpserverinfo pgpSoftware: OpenLDAP pgpVersion: 2.2.29 pgpBaseKeyspaceDN: ou=PGP Keys,dc=azienda,dc=it
Come potrete notare, si tratta dell'ultima entry immessa durante l'inizializzazione del database, senza l'Organizational Unit. Questo perchè WinPT fa la ricerca dell'objectclass pgpserverinfo solamente nel suffix (nel nostro caso dc=azienda,dc=it) e non effettua una ricerca nei sottoalberi di LDAP. Si inserisce nel database con il comando slapadd -l /tmp/winpt.ldif. Riavviamo il servizio LDAP con service ldap start e a questo punto possiamo configurare WinPT. Doppio click sull'icona nel tray di WinPT e selezionare la voce di Menù keyserver. Nella finestra di dialogo, tasto destro nell'elenco dei server e selezionare “Add”, “LDAP Keyserver”, hostname del keyserver (nel nostro caso keyserver) e porta 389. Il risultato è in Figura 4
.
Voci correlate
- La storia di PGP su Wikipedia
- Pacchetto GPG per Windows, con i plugin per Outlook e per Explorer
- Enigmail, plugin GPG per Thunderbird
- Il sito di GnuPG
- Smartcard GPG
- GNOME Seahorse
- The SKS OpenPGP Key Server
