gnupg &mdash; Cyberdyne Systems https://noblogo.org/aytin/tag:gnupg "Fare o non fare. Non c'è provare!" Thu, 30 Apr 2026 10:05:08 +0000 Gestire la tua chiave GPG https://noblogo.org/aytin/gestire-la-tua-chiave-gpg <![CDATA[gpg tools Esistono numerose gui che semplificano la gestione di una chiave gpg. Questo articolo ha lo scopo di semplificare la creazione di una chiave gpg attraverso la cli di GnuPG, senza entrare nel suo mare magnum di opzioni. !--more-- Indice a href="#premessa"Premessa/a a href="#gestione-della-chiave"Gestione della chiave/a a href="#come-proteggere-il-nostro-keyring"Come proteggere il nostro keyring/a a href="#cos-e-un-keyserver"Cos'è un keyerver/a ---- a id=premessa"Premessa/a Cosa NON è una chiave gpg? Una coppia di chiavi, una pubblica e una privata basate sulla crittografia asimmetrica. Cos'è una chiave gpg? Non è solo una coppia di chiavi asimmetriche ma è un certificato. Dal punto di vista delle informazioni, una chiave gpg contiene: informazioni identificative (nome, commento, email, foto, ecc) informazioni non identificative (dati tecnici che fanno parte delle chiavi: scadenza, keyserver, algoritmi di hash e cifratura, revoker ecc.) Una chiave gpg, in definitiva, è costituita da: una chiave primaria (detta anche secret key o master key) da una o più sottochiavi da una serie di informazioni personali. Ognuna di queste "chiavi" è in realtà una coppia di chiavi asimmetriche dotate delle seguenti autorizzazioni: Certificazione: capacità della chiave di firmare, e quindi validare, le chiavi gpg di altri utenti. Firma: capacità di firmare documenti. Cifratura: capacità di cifrare documenti. Autenticazione: capacità di autenticare l'utente su alcuni protocolli come TLS o SSH. La certificazione, ossia la capacità di validare altre chiavi oltre la propria, è esclusiva della master key. Le altre autorizzazioni possono essere delegate alle sottochiavi. Certificazioni e firma, garantiscono autenticazione, integrità e non ripudio del mittente. La cifratura garantisce confidenzialità. Le prime due sono da considerarsi più critiche e normalmente assegnate alla master key. Una chiave può avere una o più proprietà. Di default, gpg crea una master key con autorizzazioni per firma e certificazione e una sottochiave con autorizzazioni per cifratura. a id="gestione-della-chiave"Gestione della chiave/a Per la creazione e la gestione della chiave nei suoi elementi principali, vedremo: come creare la chiave primaria come aggiungere sottochiavi, uid come modificare password o scadenza come si certifica un'altra chiave con la nostra (firma di chiave) come si cancellano localmente uid, sottochiavi e firme come si revoca un certificato, una sottochiave, un uid o una certificazione come si usa un keyserver per la pubblicazione e la ricerca delle chiavi Creazione della chiave primaria gpg --quick-gen-key uid algo auth expire, dove - uid: "uidname (comment) e-mail" - algo: uno fra 'gpg --with-colons --list-config' - auth: cert|encr|sign - expire: 0 = illimitato, ny|nm|nd = n anni|mesi|giorni gpg --quick-gen-key gandalf ed25519 cert 0 Crea una chiave gpg la cui secret key può solo certificare, l'uid è composto dal solo nome gandalf e ha scadenza illimitata. gpg -K /home/gandalf/.gnupg/pubring.kbx -------------------------------- sec ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C] 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B uid [ultimate] gandalf Ecco la chiave appena creata, nella prima riga distinguiamo: "sec", sta per secret key algoritmo/KeyID data di creazione capability ([C]=certify). Nella riga successiva è visibile il fingerprint e nella terza, l'uid (gandalf). Questi elementi, come il KeyID, servono per indirizzare la chiave. Una sintassi più completa sarebbe: gpg --quick-gen-key "nome (commento) e-mail" algo cert|sign|encr scadenza Per avere una lista degli algo: gpg --with-colons --list-config Aggiungere una sottochiave Aggiungiamo le chiavi di firma e di cifratura con scadenza 5 anni e 1 anno rispettivamente gpg --quick-addgen-key fpr algo auth expire gpg --quick-add-key 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B ed25519 sign 5y gpg --quick-add-key 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B cv25519 encr 1y Come prima, oltre alla secret key, ora sono visibili le sottochiavi (ssb, Secret SubKey) di firma e cifratura con le evidenze per: algoritmo, KeyID, creazione, capability ([S] per sign e [E] per encrypt) e scadenza. gpg -K /home/gandalf/.gnupg/pubring.kbx -------------------------------- sec ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C] 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B uid [ultimo] gandalf ssb ed25519/0xA391F0548FB542DB 2024-11-05 [S] [scadenza: 2029-11-04] ssb cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [scadenza: 2025-11-05] Meccanismi di indirizzamento per una chiave Una chiave può essere riferita attraverso l'uid, il key ID o il fingerprint. Il riferimento è importante nelle operazioni di manipolazione della chiave. gpg --with-subkey-fingerprint -K /home/gandalf/.gnupg/pubring.kbx -------------------------------- sec ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C] 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B uid [ultimate] gandalf uid [ultimate] Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) gandalf@lotr.org ssb ed25519/0xA391F0548FB542DB 2024-11-05 [S] [expires: 2029-11-04] 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB ssb cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [expires: 2025-11-04] 4DD33D36C54E2247486C9DC7AAEF649D51D832E8 0xE01BDCB6A3C6778B è il key ID della master key 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B è il fingerprint della master key gandalf è uno degli uid Aggiungere un uid Aggiunge un nuovo uid in termini di nome-commento-email e lo battezza come primario. gpg --quick-add-uid primaryuid newuid gpg --quick-add-uid gandalf "Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) gandalf@lotr.org" gpg --quick-set-primary-uid primaryuid newuid gpg --quick-set-primary-uid "gandalf" "Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) gandalf@lotr.org" Firmare una chiave Ossia riconoscere una chiave gpg come valida attraverso la certificazione. Pubblicare questa chiave sul keyserver, comunica al mondo che riconosciamo quella chiave come valida. Convalida tutti gli uid della chiave identificata da fpr gpg --quick-sign-key fpr gpg --quick-sign-key AD59879E1CB5D63E98F05FB9204621DACB1296E0 Convalida un uid specifico della chiave identificata da fpr gpg --quick-sign-key fpr uid gpg --quick-sign-key AD59879E1CB5D63E98F05FB9204621DACB1296E0 frodo Modificare la password Inserisce la password con cui tutte le chiavi private (master key e subkey) relative all'uid indicato, vengono cifrate. Se la password viene lasciata vuota, la chiave non viene cifrata. gpg --passwd uid|KeyID|fpr gpg --passwd gandalf Modificare la scadenza Modifico le scadenze delle chiavi come segue: la master key da illimitata a 10 anni la sottochiave di firma da 5 anni a 4 anni la sottochiave di cifratura da 1 anno a 2 anni gpg --quick-set-expire fpr expire gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 10y gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 4y 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 2y 4DD33D36C54E2247486C9DC7AAEF649D51D832E8 gpg --with-subkey-fingerprint -K /home/gandalf/.gnupg/pubring.kbx -------------------------------- sec ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C] [expires: 2034-11-04] 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B uid [ultimate] gandalf uid [ultimate] Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) gandalf@lotr.org ssb ed25519/0xA391F0548FB542DB 2024-11-05 [S] [expires: 2028-11-04] 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB ssb cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [expires: 2026-11-04] 4DD33D36C54E2247486C9DC7AAEF649D51D832E8 Cancellazione di elementi dal keyring La cancellazione di elementi come uid, firme o sottochiavi ha effetto solo sul keyring locale. Se la chiave è stata pubblicata su un repository, le cancellazioni non avranno alcun effetto. Se si vuole inibire uno di questi elementi, si deve ricorrere alla revoca che è esportabile sui keyserver. Cancellare una sottochiave Cancella la sottochiave di firma gpg --delete-secret-and-public-keys KeyID|fpr gpg --delete-secret-and-public-keys 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB! o, equivalentemente gpg --delete-secret-and-public-keys 0xA391F0548FB542DB! Cancellare un uid Cancella la seconda identità della chiave gandalf (0xA391F0548FB542DB) gpg --edit-key [KeyID|fpr|uid] gpg --edit-key gandalf uid 2 deluid save Cancellare una firma Cancella tutte le firme del 2° uid che non siano self-signature. gpg --edit-key [KeyID|fpr|uid] gpg --edit-key gandalf uid 2 delsig save Operazioni di revoca Per quel che riguarda le chiavi gpg (i certificati) di cui si possiede la chiave privata, l'operazione di revoca può avvenire su uno degli elementi della chiave o sull'intero certificato. Revocare un uid Revoco l'uid (gandalf il grigio), gpg --quick-revuid primaryuid uid gpg --quick-revuid gandalf "gandalf il grigio" Revocare una sottochiave gpg --edit-key [KeyID|fpr|uid] gpg --edit-key 0xA391F0548FB542DB key 1 revkey save Revocare una nostra certificazione Così come validiamo le chiavi altrui con la nostra firma di certificazione, allo stesso modo possiamo revocarla. Revoco la mia firma su tutti gli uid di una chiave pubblica gpg --quick-revoke-sig KeyID|fpr del firmato KeyID|fpr del firmante gpg --quick-revoke-sig 0x204621DACB1296E0 0xE01BDCB6A3C6778B Posso anche revocare la mia firma su un uid specifico gpg --quick-revoke-sig KeyID|fpr del firmato KeyID|fpr del firmante uidi gpg --quick-revoke-sig 0x204621DACB1296E0 0xE01BDCB6A3C6778B frodouid2 Revocare l'intero certificato Va a revocare non solo tutti gli uid e tutte le sottochiavi, ma anche la masterkey. gpg --import 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB.rev Il certificato di revoca viene generato all'atto della creazione della chiave. Se non ci fosse, conviene sempre crearlo così che, se la master key venisse compromessa, saremmo almeno in grado di revocare l'intero certificato. gpg -o file --gen-rev fpr gpg -o 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB.rev --gen-rev 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB Le operazioni di revoca, nel mondo gpg, corrispondono alle maledizioni senza perdono, nel mondo di Harry Potter. Non si torna indietro a meno di un backup, e se le revoche vengono pubblicate su un keyserver, diventano irreversibili. Operazioni sul keyserver Il caricamento delle chiavi su un keyserver costituisce la finalizzazione delle operazioni svolte finora. Il keyserver pubblica al mondo le nostre chiavi, la configurazione avviene nel file dirmngr.conf aggiungendo una riga (ad es. per keys.openpgp.org): vi dirmngr.conf ... keyserver hkps://keys.openpgp.org ... e ricaricando la configurazione: gpgconf --reload dirmngr Cerca Cerca nel keyserver le chiavi con uid specificato. In caso di successo, chiede se possono essere aggiunte al keyring. gpg --search-keys uid gpg --search-keys 0xE01BDCB6A3C6778B 0x204621DACB1296E0 Per gli utilizzatori di keys.openpgp.org: gpg --auto-key-locate keyserver --locate-keys uid Invia Invia una lista di chiavi al keyserver gpg --send-keys KeyIDs|fpr gpg --send-keys 0xE01BDCB6A3C6778B 0x204621DACB1296E0 Per gli utilizzatori di keys.openpgp.org: Il classico send non è sufficiente perché non sarebbe possibile validare la mail di conferma. Si consiglia, non volendo usare l'interfaccia web, di usare il seguente comando: gpg --export KeyID|fpr|uid | curl -T - https://keys.openpgp.org gpg --export 0xE01BDCB6A3C6778B | curl -T - https://keys.openpgp.org che restituisce un link diretto alla pagina di verifica. Ricevi Scarica dal keyserver le chiavi gpg --keyserver-options honor-keyserver-url --receive-keys KeyIDs|fpr gpg --keyserver-options honor-keyserver-url --receive-keys 0xE01BDCB6A3C6778B 0x204621DACB1296E0 Scarica dal keyserver la chiave indicata dall'uri gpg --fetch-keys uri gpg --fetch-keys https://keyserver.ubuntu.com/pks/lookup?search=0xE01BDCB6A3C6778B&fingerprint=on&op=index Aggiorna Per rinnovare tutte le chiavi pubbliche del keyring. gpg --keyserver-options honor-keyserver-url --refresh-keys a id="come-proteggere-il-nostro-keyring"Come proteggere il nostro keyring/a Come visto in precedenza, suggerisco di creare la master key per la sola certificazione e le due sottochiavi per firma e cifratura (anche quando la chiave primaria dovesse contenere altre autorizzazioni). Questo permetterebbe, volendo ma non è necessario, di ruotare più agevolmente le chiavi di firma e cifratura svincolandole dalla certificazione. Inoltre, così è più semplice rendere le chiavi gpg "partially stripped", chiavi la cui sola secret key sia mancante della chiave privata, cosicché, se queste venissero smarrite o trafugate, la secret key in nostro possesso ci permetterebbe immediatamente di generare un certificato di revoca per le sottochiavi compromesse, generare delle nuove sottochiavi di firma e cifratura e di distribuire il tutto ad un keyserver. Chiavi gpg siffatte permetterebbero di svolgere le consuete operazioni di firma e cifratura documentale (quello che potremmo definire "utilizzo giornaliero") ma impedirebbero qualunque operazione critica sulla propria chiave gpg (impossibilità di aggiungere, revocare sottochiavi o uid, di alterare scadenza o password ecc.) e su quelle altrui (certificare e quindi validare altre chiavi) upoichè è la chiave privata della master key a sigillare self-signed le informazioni della chiave gpg/u. In generale, posso estrarre la chiave privata da qualunque coppia di chiavi, siano esse sottochiavi o master key, ma non è uno scenario molto comune. Per estensione, eliminandole tutte otterremo un insieme di chiavi pubbliche (quella che otterrei anche con gpg --export uid|KeyID|fpr). Quello che invece ci interessa è eliminare la chiave privata della sola master key. L'eliminazione della chiave privata dalla master key, di per sè, non è un'operazione particolarmente onerosa. La vera "difficoltà" risiede nel cambio di paradigma per l'utente che l'utilizzo di master key stripped comporta, perché avremo a che fare con un keyring da proteggere accuratamente e dei keyring da "trincea" da usare liberamente sui nostri device. Realizzare un keyring per l'uso quotidiano Per farlo dobbiamo eliminare le chiavi private di tutte le master key del nostro keyring e per farlo dobbiamo fare un po' di assunzioni. Come primo passo, bisogna spostare, se non è stato già fatto, il keryring dal pc/laptop/device ad un luogo sicuro (ad es. pendrive cifrata) quindi si devono estrarre le chiavi private dalle master key e distribuirle dove possano servire in caso di emergenza o se vi è necessità di modificare le chiavi, importare le chiavi gpg dal dispositivo sicuro, effettuare le modifiche, rigenerare e ridistribuire le nuove chiavi stripped Eliminazione della chiave privata dalla master key La cancellazione della chiave privata impedisce alla master key o alla sottochiave di esercitare pienamente le funzioni indicate dalle proprie autorizzazioni ossia certificazione, firma o decifratura. Per intervenire sulla singola chiave privata, occorre individuare il suo fingerprint o il suo keyid e usarlo per cancellare postponendo il carattere "!". Ad es. sulla master key di gandalf: gpg --delete-secret-keys 0x055D271BD85313D0! Il carattere "#" (accanto a sec) vuol dire che la chiave privata è stata eliminata gpg -K /home/gandalf/ramfsgpg/pubring.kbx ----------------------------------- sec# ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C] 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B uid [ultimo] gandalf ssb ed25519/0xA391F0548FB542DB 2024-11-05 [S] [scadenza: 2029-11-04] ssb cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [scadenza: 2025-11-05] Generalizzando, per realizzare il nostro keyring di lavoro si può agire, una tantum, in questo modo: 1\. spostiamo il keyring di lavoro sul dispositivo sicuro KEYRINGRAMFS=pathramfs KEYRINGVAULT=pathpendrivecifrata KEYRINGWORK=pathgpgdaily export GNUPGHOME=${KEYRINGWORK}; cd $GNUPGHOME rsync -avp ${KEYRINGWORK}/ ${KEYRINGVAULT}/ 2\. rendiamo il keyring stripped cancellando le chiavi private di tutte le master key. for FPR in $(gpg --with-colons -K|grep sec -A 1|grep fpr|cut -d ":" -f 10); do gpg --batch --yes --delete-secret-keys "${FPR}!" done In seguito, come detto in precedenza, per lavorare sul keyring occorrerà ripristinarlo dal dispositivo sicuro, ad es. una pendrive cifrata. Per non lasciare tracce su altri device che non sia la pendrive cifrata, si possono seguire due strade. usare una distribuzione live (più sicura) montare una partizione in ram su ramfs (non usa lo swap) su cui caricare il keyring. La prima via è certamente preferibile. Non c'è alcun uso dei dispositivi di storage fisici della macchine, solo quelli volatili, ma presuppone che si possa avviare un SO da pendrive. La seconda è più accessibile per certi versi ma presuppone che si possiedano i privilegi per montare una partizione su ram. Mostrerò la seconda via che è più articolata. Lavorare con un keyring effimero La strategia è quella di avere un keyring effimero montato su ramfs che farà da tramite fra il keyring master (su pendrive cifrata) e il keyring di lavoro. L'obiettivo finale è quello di rendere strutturale il fatto di riuscire a compiere operazioni sul keyring usando il meno possibile i dispositivi di storage. 0\. Init KEYRINGRAMFS=pathramfs KEYRINGVAULT=pathpendrivecifrata KEYRINGWORK=pathgpgdaily 1\. Monto la partizione effimera mkdir -p ${KEYRINGRAMFS} sudo mount -t ramfs -o size=10M ramfs ${KEYRINGRAMFS} sudo chown $(logname):$(logname) ${KEYRINGRAMFS} 2\. Esporto chiavi pubbliche e trust dal keyring di lavoro gpg -o ${KEYRINGRAMFS}/keyringpubkeys.gpg --export gpg --export-ownertrust ${KEYRINGRAMFS}/keyringownertrust.txt 3\. Copio il keyring master sulla partizione effimera, modifico GNUPGHOME in modo che gpg lavori direttamente sulla partizione effimera. Su questo keyring effimero, completo l'allineamento importando le chiavi pubbliche e il trust provenienti dal keyring di lavoro. rsync -avp ${KEYRINGVAULT}/ ${KEYRINGRAMFS}/ export GNUPGHOME=${KEYRINGRAMFS}; cd $GNUPGHOME gpg --import keyringpubkeys.gpg gpg --import-ownertrust keyringownertrust.txt 4\. Eseguo le mie manipolazioni sul keyring effimero: uid, key, passwd, firme, revoche ecc. ... [operazioni gpg] ... 5\. Copio il keyring master dalla partizione effimera alla pendrive cifrata rsync -avp ${KEYRINGRAMFS}/ ${KEYRINGVAULT}/ 6\. Rendo il keyring effimero di nuovo stripped for FPR in $(gpg --with-colons -K|grep sec -A 1|grep fpr|cut -d ":" -f 10); do gpg --batch --yes --delete-secret-keys "${FPR}!" done 7\. Ripristino il keyring di lavoro escludendo i certificati di revoca e cancellando la partizione effimera rsync -avp --exclude openpgp-revocs.d ${KEYRINGRAMFS}/ ${KEYRINGWORK}/ export GNUPGHOME=${KEYRINGWORK}/ sudo umount ${KEYRINGRAMFS}; rmdir ${KEYRINGRAMFS} La complessità di questa gestione può essere ridotta rendendo scriptabili i due blocchi (1,2,3) e (5,6,7), ad es. immaginando di avere a disposizione delle funzioni come gpg-vault [open|close|status], avendo la consapevolezza che, se usate male, possono essere delle operazioni distruttive. a id="cos-e-un-keyserver"Cos'è un keyerver/a Il keyserver è il luogo in cui pubblichiamo le nostre chiavi per renderle disponibili agli altri utenti. Inizialmente i keyserver avevano una logica p2p, distribuita e decentralizzata ottenuta con un'implementazione chiamata SKS (Synchronizing Key Server) basata sulla rapida diffusione delle chiavi fra keyserver. I keyserver inizialmente servivano anche a realizzare il WOT (Web Of Trust) per la convalida delle chiavi. Col tempo, la mancanza di aggiornamenti del protocollo sks e la suscettibilità ad attacchi di tipo "key poisoning", che possono rendere indisponibili interi certificati (ad es. riempiendo la chiave con innumerevoli firme contenenti tonnellate di dati tali da far crashare i client) o gli stessi keyserver (pubblicando quantitivi enormi di certificati non validi), amplificata dalle caratteristiche di sincronizzazione dei server, ne hanno decretato la fine. La realizzazione del WOT, tra l'altro, offriva pubblicamente una tale quantità di chiavi che permetteva, da un lato, di tracciare interi social network basati sulle firme che vi venivano apposte, dall'altro, di essere un formidabile serbatoio di email e altri dati sensibili a disposizione di attori malevoli, spammer e altro. Inoltre leggi recenti sulla privacy come GDPR, cozzavano contro la natura immutabile dei keyserver che, by design, aggiungono chiavi e non permettono la cancellazione. Modelli recenti I modelli di keyserver successivi mitigano (ma non risolvono completamente) queste debolezze: rinunciando alla federazione e alla distribuzione sposando un modello basato sul controllo dell'email prima dell'accettazione della chiave ricorrendo a limitazioni, filtri e valutazioni sulla bontà delle chiavi prima che queste vengano accettate. I principali modelli di keyserver sono: Hagrid Mailvelope HockeyPuck Sono stati tutti creati per sopperire ai limiti dei server SKS. Hagrid Il primo, basato su SequoiaPGP, ha una natura centralizzata (non sarà mai federato), è GDPR compliant ed ha dato luogo a keys.openpgp.org. I keyserver di questo tipo non aderiscono al modello WOT per ragioni di privacy e di efficienza. Sono quindi rifiutate le chiavi di terze parti, essenziali nel modello WOT, l'accettazione della chiave pubblica è vincolata dalla verifica dell'email, è possibile rimuovere le chiavi. Sono più resistenti agli attacchi di key poisoning. Mailvelope Ha dato luogo al keyserver keys.mailvelope.com, molto simile al primo e ne condivide la politica: no federazione, niente firme di terze parti e verifica dell'email vincolante per l'accettazione della chiave. A differenza di altri keyserver, il focus di Mailvelope è la semplificazione dell'utilizzo della crittografia sull'e-mail, che sia webmail, con i provider e i browser che supportano Mailvelope, o client, quando si integrino con le sue api. Hockeypuck È un ritorno alle origini, ha una natura federata ed è considerato l'alternativa robusta ai server SKS. Uno fra i più noti server hockeypuck è certamente: keyserver.ubuntu.com il keyserver gestito dalla comunità Ubuntu che contiene le chiavi per i suoi pacchetti ma è anche aperto al pubblico. Un altro keyserver hockeypuck più di nicchia perché legato ad una specifica realtà tecnologica olandese è: pgp.surf.nl Sebbene possa essere meno aggiornato del primo, può essere usato liberamente per pubblicare le proprie chiavi. I keyserver di questo tipo, come il pool di server sks, anche se con un filtraggio più stringente, abbracciano il modello WOT con tutto quello che ne consegue. Altri keyserver Infine, per dovere di cronaca, bisogna citare due decani dei keyserver apparsi all'alba di pgp e ormai non più utilizzabili per motivi di obsolescenza e di abbandono. pgp.mit.edu: uno dei primi repository a permettere la pubblicazione e la distribuzione di chiavi pubbliche, facente anche parte della rete SKS. global.pgp.com: l'alternativa proprietaria, appartenente a PGP Corporation prima e Symantec dopo, era il repository centralizzato per la distribuzione di chiavi usato dall'applicazione pgp. In conclusione, se la necessità è di utilizzare il WOT, allora la scelta è senza dubbio Hockeypuck quindi keyserver.ubuntu.com. Se invece la privacy è prioritaria, Hagrid quindi keys.openpgp.org diventa la scelta obbligatoria, tanto che è il default sia di GPG che di OpenKeyChain #gpg #gnupg #crittografia #keyserver #hagrid #hockeypuck #mailvelope]]> gpg tools

Esistono numerose gui che semplificano la gestione di una chiave gpg.

Questo articolo ha lo scopo di semplificare la creazione di una chiave gpg attraverso la cli di GnuPG, senza entrare nel suo mare magnum di opzioni.

Indice

  1. Premessa
  2. Gestione della chiave
  3. Come proteggere il nostro keyring
  4. Cos'è un keyerver

Premessa

Cosa NON è una chiave gpg? Una coppia di chiavi, una pubblica e una privata basate sulla crittografia asimmetrica.

Cos'è una chiave gpg? Non è solo una coppia di chiavi asimmetriche ma è un certificato. Dal punto di vista delle informazioni, una chiave gpg contiene:

  • informazioni identificative (nome, commento, email, foto, ecc)
  • informazioni non identificative (dati tecnici che fanno parte delle chiavi: scadenza, keyserver, algoritmi di hash e cifratura, revoker ecc.)

Una chiave gpg, in definitiva, è costituita da:

  • una chiave primaria (detta anche secret key o master key)
  • da una o più sottochiavi
  • da una serie di informazioni personali.

Ognuna di queste “chiavi” è in realtà una coppia di chiavi asimmetriche dotate delle seguenti autorizzazioni:

  • Certificazione: capacità della chiave di firmare, e quindi validare, le chiavi gpg di altri utenti.
  • Firma: capacità di firmare documenti.
  • Cifratura: capacità di cifrare documenti.
  • Autenticazione: capacità di autenticare l'utente su alcuni protocolli come TLS o SSH.

La certificazione, ossia la capacità di validare altre chiavi oltre la propria, è esclusiva della master key. Le altre autorizzazioni possono essere delegate alle sottochiavi.

Certificazioni e firma, garantiscono autenticazione, integrità e non ripudio del mittente. La cifratura garantisce confidenzialità. Le prime due sono da considerarsi più critiche e normalmente assegnate alla master key.

Una chiave può avere una o più proprietà. Di default, gpg crea una master key con autorizzazioni per firma e certificazione e una sottochiave con autorizzazioni per cifratura.

Gestione della chiave

Per la creazione e la gestione della chiave nei suoi elementi principali, vedremo:

  • come creare la chiave primaria
  • come aggiungere sottochiavi, uid
  • come modificare password o scadenza
  • come si certifica un'altra chiave con la nostra (firma di chiave)
  • come si cancellano localmente uid, sottochiavi e firme
  • come si revoca un certificato, una sottochiave, un uid o una certificazione
  • come si usa un keyserver per la pubblicazione e la ricerca delle chiavi

Creazione della chiave primaria

# gpg --quick-gen-key <uid> <algo> <auth> <expire>, dove
# - <uid>: "uid_name (comment) <e-mail>"
# - <algo>: uno fra 'gpg --with-colons --list-config'
# - <auth>: cert|encr|sign
# - <expire>: 0 => illimitato, ny|nm|nd => n anni|mesi|giorni
gpg --quick-gen-key gandalf ed25519 cert 0

Crea una chiave gpg la cui secret key può solo certificare, l'uid è composto dal solo nome gandalf e ha scadenza illimitata.

gpg -K
/home/gandalf/.gnupg/pubring.kbx
--------------------------------
sec   ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C]
	  8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid                   [ultimate] gandalf

Ecco la chiave appena creata, nella prima riga distinguiamo:

  • “sec”, sta per secret key
  • algoritmo/KeyID
  • data di creazione
  • capability ([C]=certify).

Nella riga successiva è visibile il fingerprint e nella terza, l'uid (gandalf). Questi elementi, come il KeyID, servono per indirizzare la chiave.

Una sintassi più completa sarebbe:

gpg --quick-gen-key "nome (commento) <e-mail>" algo cert|sign|encr <scadenza>

Per avere una lista degli algo:

gpg --with-colons --list-config

Aggiungere una sottochiave

Aggiungiamo le chiavi di firma e di cifratura con scadenza 5 anni e 1 anno rispettivamente

# gpg --quick-addgen-key <fpr> <algo> <auth> <expire>
gpg --quick-add-key 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B ed25519 sign 5y
gpg --quick-add-key 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B cv25519 encr 1y

Come prima, oltre alla secret key, ora sono visibili le sottochiavi (ssb, Secret SubKey) di firma e cifratura con le evidenze per: algoritmo, KeyID, creazione, capability ([S] per sign e [E] per encrypt) e scadenza.

gpg -K
/home/gandalf/.gnupg/pubring.kbx
--------------------------------
sec   ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C]
	  8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid                   [ultimo] gandalf
ssb   ed25519/0xA391F0548FB542DB 2024-11-05 [S] [scadenza: 2029-11-04]
ssb   cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [scadenza: 2025-11-05]

Meccanismi di indirizzamento per una chiave

Una chiave può essere riferita attraverso l'uid, il key ID o il fingerprint. Il riferimento è importante nelle operazioni di manipolazione della chiave.

gpg --with-subkey-fingerprint -K
/home/gandalf/.gnupg/pubring.kbx
--------------------------------
sec   ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C]
	  8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid                   [ultimate] gandalf
uid                   [ultimate] Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) <gandalf@lotr.org>
ssb   ed25519/0xA391F0548FB542DB 2024-11-05 [S] [expires: 2029-11-04]
	  87EF9CF3D5A4D78ADA80E364A391F0548FB542DB
ssb   cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [expires: 2025-11-04]
	  4DD33D36C54E2247486C9DC7AAEF649D51D832E8
  • 0xE01BDCB6A3C6778B è il key ID della master key
  • 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B è il fingerprint della master key
  • gandalf è uno degli uid

Aggiungere un uid

Aggiunge un nuovo uid in termini di nome-commento-email e lo battezza come primario.

# gpg --quick-add-uid <primary_uid> <new_uid>
gpg --quick-add-uid gandalf "Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) <gandalf@lotr.org>"

# gpg --quick-set-primary-uid <primary_uid> <new_uid>
gpg --quick-set-primary-uid "gandalf" "Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) <gandalf@lotr.org>"

Firmare una chiave

Ossia riconoscere una chiave gpg come valida attraverso la certificazione. Pubblicare questa chiave sul keyserver, comunica al mondo che riconosciamo quella chiave come valida.

Convalida tutti gli uid della chiave identificata da <fpr>

# gpg --quick-sign-key <fpr>
gpg --quick-sign-key AD59879E1CB5D63E98F05FB9204621DACB1296E0

Convalida un uid specifico della chiave identificata da <fpr>

# gpg --quick-sign-key <fpr> <uid>
gpg --quick-sign-key AD59879E1CB5D63E98F05FB9204621DACB1296E0 frodo

Modificare la password

Inserisce la password con cui tutte le chiavi private (master key e subkey) relative all'uid indicato, vengono cifrate. Se la password viene lasciata vuota, la chiave non viene cifrata.

# gpg --passwd <uid|KeyID|fpr>
gpg --passwd gandalf

Modificare la scadenza

Modifico le scadenze delle chiavi come segue:

  • la master key da illimitata a 10 anni
  • la sottochiave di firma da 5 anni a 4 anni
  • la sottochiave di cifratura da 1 anno a 2 anni
# gpg --quick-set-expire <fpr> <expire>
gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 10y
gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 4y 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB
gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 2y 4DD33D36C54E2247486C9DC7AAEF649D51D832E8

gpg --with-subkey-fingerprint -K
/home/gandalf/.gnupg/pubring.kbx
--------------------------------
sec   ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C] [expires: 2034-11-04]
	  8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid                   [ultimate] gandalf
uid                   [ultimate] Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) <gandalf@lotr.org>
ssb   ed25519/0xA391F0548FB542DB 2024-11-05 [S] [expires: 2028-11-04]
	  87EF9CF3D5A4D78ADA80E364A391F0548FB542DB
ssb   cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [expires: 2026-11-04]
	  4DD33D36C54E2247486C9DC7AAEF649D51D832E8

Cancellazione di elementi dal keyring

La cancellazione di elementi come uid, firme o sottochiavi ha effetto solo sul keyring locale. Se la chiave è stata pubblicata su un repository, le cancellazioni non avranno alcun effetto. Se si vuole inibire uno di questi elementi, si deve ricorrere alla revoca che è esportabile sui keyserver.

Cancellare una sottochiave

Cancella la sottochiave di firma

# gpg --delete-secret-and-public-keys <KeyID|fpr>
gpg --delete-secret-and-public-keys 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB!
# o, equivalentemente
gpg --delete-secret-and-public-keys 0xA391F0548FB542DB!

Cancellare un uid

Cancella la seconda identità della chiave gandalf (0xA391F0548FB542DB)

# gpg --edit-key [KeyID|fpr|uid]
gpg --edit-key gandalf
    uid 2
    deluid
    save

Cancellare una firma

Cancella tutte le firme del 2° uid che non siano self-signature.

# gpg --edit-key [KeyID|fpr|uid]
gpg --edit-key gandalf
    uid 2
    delsig
    save

Operazioni di revoca

Per quel che riguarda le chiavi gpg (i certificati) di cui si possiede la chiave privata, l'operazione di revoca può avvenire su uno degli elementi della chiave o sull'intero certificato.

Revocare un uid

Revoco l'uid (gandalf il grigio),

# gpg --quick-revuid <primary_uid> <uid> 
gpg --quick-revuid gandalf "gandalf il grigio"

Revocare una sottochiave

# gpg --edit-key [KeyID|fpr|uid]
gpg --edit-key 0xA391F0548FB542DB
    key 1
    revkey
    save

Revocare una nostra certificazione

Così come validiamo le chiavi altrui con la nostra firma di certificazione, allo stesso modo possiamo revocarla.

Revoco la mia firma su tutti gli uid di una chiave pubblica

# gpg --quick-revoke-sig <KeyID|fpr del firmato> <KeyID|fpr del firmante> 
gpg --quick-revoke-sig 0x204621DACB1296E0 0xE01BDCB6A3C6778B

Posso anche revocare la mia firma su un uid specifico

# gpg --quick-revoke-sig <KeyID|fpr del firmato> <KeyID|fpr del firmante> <uid_i>
gpg --quick-revoke-sig 0x204621DACB1296E0 0xE01BDCB6A3C6778B frodo_uid2

Revocare l'intero certificato

Va a revocare non solo tutti gli uid e tutte le sottochiavi, ma anche la masterkey.

gpg --import 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB.rev

Il certificato di revoca viene generato all'atto della creazione della chiave. Se non ci fosse, conviene sempre crearlo così che, se la master key venisse compromessa, saremmo almeno in grado di revocare l'intero certificato.

# gpg -o <file> --gen-rev <fpr>
gpg -o 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB.rev --gen-rev 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB

Le operazioni di revoca, nel mondo gpg, corrispondono alle maledizioni senza perdono, nel mondo di Harry Potter. Non si torna indietro a meno di un backup, e se le revoche vengono pubblicate su un keyserver, diventano irreversibili.

Operazioni sul keyserver

Il caricamento delle chiavi su un keyserver costituisce la finalizzazione delle operazioni svolte finora.

Il keyserver pubblica al mondo le nostre chiavi, la configurazione avviene nel file dirmngr.conf aggiungendo una riga (ad es. per keys.openpgp.org):

vi dirmngr.conf

...
keyserver hkps://keys.openpgp.org
...

e ricaricando la configurazione:

gpgconf --reload dirmngr

Cerca

Cerca nel keyserver le chiavi con uid specificato. In caso di successo, chiede se possono essere aggiunte al keyring.

# gpg --search-keys <uid>
gpg --search-keys 0xE01BDCB6A3C6778B 0x204621DACB1296E0

Per gli utilizzatori di keys.openpgp.org:

gpg --auto-key-locate keyserver --locate-keys <uid>

Invia

Invia una lista di chiavi al keyserver

# gpg --send-keys <KeyIDs|fpr>
gpg --send-keys 0xE01BDCB6A3C6778B 0x204621DACB1296E0

Per gli utilizzatori di keys.openpgp.org: Il classico send non è sufficiente perché non sarebbe possibile validare la mail di conferma. Si consiglia, non volendo usare l'interfaccia web, di usare il seguente comando:

# gpg --export <KeyID|fpr|uid> | curl -T - https://keys.openpgp.org
gpg --export 0xE01BDCB6A3C6778B | curl -T - https://keys.openpgp.org

che restituisce un link diretto alla pagina di verifica.

Ricevi

Scarica dal keyserver le chiavi

# gpg --keyserver-options honor-keyserver-url --receive-keys <KeyIDs|fpr>
gpg --keyserver-options honor-keyserver-url --receive-keys 0xE01BDCB6A3C6778B 0x204621DACB1296E0

Scarica dal keyserver la chiave indicata dall'uri

# gpg --fetch-keys <uri>
gpg --fetch-keys https://keyserver.ubuntu.com/pks/lookup?search=0xE01BDCB6A3C6778B&fingerprint=on&op=index

Aggiorna

Per rinnovare tutte le chiavi pubbliche del keyring.

gpg --keyserver-options honor-keyserver-url --refresh-keys

Come proteggere il nostro keyring

Come visto in precedenza, suggerisco di creare la master key per la sola certificazione e le due sottochiavi per firma e cifratura (anche quando la chiave primaria dovesse contenere altre autorizzazioni).

Questo permetterebbe, volendo ma non è necessario, di ruotare più agevolmente le chiavi di firma e cifratura svincolandole dalla certificazione.

Inoltre, così è più semplice rendere le chiavi gpg “partially stripped”, chiavi la cui sola secret key sia mancante della chiave privata, cosicché, se queste venissero smarrite o trafugate, la secret key in nostro possesso ci permetterebbe immediatamente di generare un certificato di revoca per le sottochiavi compromesse, generare delle nuove sottochiavi di firma e cifratura e di distribuire il tutto ad un keyserver.

Chiavi gpg siffatte permetterebbero di svolgere le consuete operazioni di firma e cifratura documentale (quello che potremmo definire “utilizzo giornaliero”) ma impedirebbero qualunque operazione critica sulla propria chiave gpg (impossibilità di aggiungere, revocare sottochiavi o uid, di alterare scadenza o password ecc.) e su quelle altrui (certificare e quindi validare altre chiavi) poichè è la chiave privata della master key a sigillare self-signed le informazioni della chiave gpg.

In generale, posso estrarre la chiave privata da qualunque coppia di chiavi, siano esse sottochiavi o master key, ma non è uno scenario molto comune. Per estensione, eliminandole tutte otterremo un insieme di chiavi pubbliche (quella che otterrei anche con gpg —export ).

Quello che invece ci interessa è eliminare la chiave privata della sola master key. L'eliminazione della chiave privata dalla master key, di per sè, non è un'operazione particolarmente onerosa.

La vera “difficoltà” risiede nel cambio di paradigma per l'utente che l'utilizzo di master key stripped comporta, perché avremo a che fare con un keyring da proteggere accuratamente e dei keyring da “trincea” da usare liberamente sui nostri device.

Realizzare un keyring per l'uso quotidiano

Per farlo dobbiamo eliminare le chiavi private di tutte le master key del nostro keyring e per farlo dobbiamo fare un po' di assunzioni.

  1. Come primo passo, bisogna spostare, se non è stato già fatto, il keryring dal pc/laptop/device ad un luogo sicuro (ad es. pendrive cifrata)
  2. quindi si devono estrarre le chiavi private dalle master key e distribuirle dove possano servire
  3. in caso di emergenza o se vi è necessità di modificare le chiavi, importare le chiavi gpg dal dispositivo sicuro, effettuare le modifiche, rigenerare e ridistribuire le nuove chiavi stripped

Eliminazione della chiave privata dalla master key

La cancellazione della chiave privata impedisce alla master key o alla sottochiave di esercitare pienamente le funzioni indicate dalle proprie autorizzazioni ossia certificazione, firma o decifratura.

Per intervenire sulla singola chiave privata, occorre individuare il suo fingerprint o il suo keyid e usarlo per cancellare postponendo il carattere “!”.

Ad es. sulla master key di gandalf:

gpg --delete-secret-keys 0x055D271BD85313D0!

Il carattere “#” (accanto a sec) vuol dire che la chiave privata è stata eliminata

gpg -K
/home/gandalf/ramfs_gpg/pubring.kbx
-----------------------------------
sec#  ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C]
	  8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid                   [ultimo] gandalf
ssb   ed25519/0xA391F0548FB542DB 2024-11-05 [S] [scadenza: 2029-11-04]
ssb   cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [scadenza: 2025-11-05]

Generalizzando, per realizzare il nostro keyring di lavoro si può agire, una tantum, in questo modo:

1. spostiamo il keyring di lavoro sul dispositivo sicuro

KEYRING_RAMFS=<path_ramfs>
KEYRING_VAULT=<path_pendrive_cifrata>
KEYRING_WORK=<path_gpg_daily>
export GNUPGHOME=${KEYRING_WORK}; cd $GNUPGHOME

rsync -avp ${KEYRING_WORK}/ ${KEYRING_VAULT}/

2. rendiamo il keyring stripped cancellando le chiavi private di tutte le master key.

for FPR in $(gpg --with-colons -K|grep sec -A 1|grep fpr|cut -d ":" -f 10); do 
    gpg --batch --yes --delete-secret-keys "${FPR}!"
done

In seguito, come detto in precedenza, per lavorare sul keyring occorrerà ripristinarlo dal dispositivo sicuro, ad es. una pendrive cifrata.

Per non lasciare tracce su altri device che non sia la pendrive cifrata, si possono seguire due strade.

  1. usare una distribuzione live (più sicura)
  2. montare una partizione in ram su ramfs (non usa lo swap) su cui caricare il keyring.

La prima via è certamente preferibile. Non c'è alcun uso dei dispositivi di storage fisici della macchine, solo quelli volatili, ma presuppone che si possa avviare un SO da pendrive. La seconda è più accessibile per certi versi ma presuppone che si possiedano i privilegi per montare una partizione su ram.

Mostrerò la seconda via che è più articolata.

Lavorare con un keyring effimero

La strategia è quella di avere un keyring effimero montato su ramfs che farà da tramite fra il keyring master (su pendrive cifrata) e il keyring di lavoro.

L'obiettivo finale è quello di rendere strutturale il fatto di riuscire a compiere operazioni sul keyring usando il meno possibile i dispositivi di storage.

0. Init

KEYRING_RAMFS=<path_ramfs>
KEYRING_VAULT=<path_pendrive_cifrata>
KEYRING_WORK=<path_gpg_daily>

1. Monto la partizione effimera

mkdir -p ${KEYRING_RAMFS}
sudo mount -t ramfs -o size=10M ramfs ${KEYRING_RAMFS}
sudo chown $(logname):$(logname) ${KEYRING_RAMFS}

2. Esporto chiavi pubbliche e trust dal keyring di lavoro

gpg -o ${KEYRING_RAMFS}/keyring_pubkeys.gpg --export
gpg --export-ownertrust > ${KEYRING_RAMFS}/keyring_ownertrust.txt

3. Copio il keyring master sulla partizione effimera, modifico GNUPGHOME in modo che gpg lavori direttamente sulla partizione effimera. Su questo keyring effimero, completo l'allineamento importando le chiavi pubbliche e il trust provenienti dal keyring di lavoro.

rsync -avp ${KEYRING_VAULT}/ ${KEYRING_RAMFS}/
export GNUPGHOME=${KEYRING_RAMFS}; cd $GNUPGHOME
gpg --import keyring_pubkeys.gpg
gpg --import-ownertrust keyring_ownertrust.txt

4. Eseguo le mie manipolazioni sul keyring effimero: uid, key, passwd, firme, revoche ecc.

...
[operazioni gpg]
...

5. Copio il keyring master dalla partizione effimera alla pendrive cifrata

rsync -avp ${KEYRING_RAMFS}/ ${KEYRING_VAULT}/

6. Rendo il keyring effimero di nuovo stripped

for FPR in $(gpg --with-colons -K|grep sec -A 1|grep fpr|cut -d ":" -f 10); do 
    gpg --batch --yes --delete-secret-keys "${FPR}!"
done

7. Ripristino il keyring di lavoro escludendo i certificati di revoca e cancellando la partizione effimera

rsync -avp --exclude openpgp-revocs.d ${KEYRING_RAMFS}/ ${KEYRING_WORK}/
export GNUPGHOME=${KEYRING_WORK}/
sudo umount ${KEYRING_RAMFS}; rmdir ${KEYRING_RAMFS}

La complessità di questa gestione può essere ridotta rendendo scriptabili i due blocchi (1,2,3) e (5,6,7), ad es. immaginando di avere a disposizione delle funzioni come gpg-vault [open|close|status], avendo la consapevolezza che, se usate male, possono essere delle operazioni distruttive.

Cos'è un keyerver

Il keyserver è il luogo in cui pubblichiamo le nostre chiavi per renderle disponibili agli altri utenti.

Inizialmente i keyserver avevano una logica p2p, distribuita e decentralizzata ottenuta con un'implementazione chiamata SKS (Synchronizing Key Server) basata sulla rapida diffusione delle chiavi fra keyserver.

I keyserver inizialmente servivano anche a realizzare il WOT (Web Of Trust) per la convalida delle chiavi.

Col tempo, la mancanza di aggiornamenti del protocollo sks e la suscettibilità ad attacchi di tipo “key poisoning”, che possono rendere indisponibili interi certificati (ad es. riempiendo la chiave con innumerevoli firme contenenti tonnellate di dati tali da far crashare i client) o gli stessi keyserver (pubblicando quantitivi enormi di certificati non validi), amplificata dalle caratteristiche di sincronizzazione dei server, ne hanno decretato la fine.

La realizzazione del WOT, tra l'altro, offriva pubblicamente una tale quantità di chiavi che permetteva, da un lato, di tracciare interi social network basati sulle firme che vi venivano apposte, dall'altro, di essere un formidabile serbatoio di email e altri dati sensibili a disposizione di attori malevoli, spammer e altro.

Inoltre leggi recenti sulla privacy come GDPR, cozzavano contro la natura immutabile dei keyserver che, by design, aggiungono chiavi e non permettono la cancellazione.

Modelli recenti

I modelli di keyserver successivi mitigano (ma non risolvono completamente) queste debolezze:

  • rinunciando alla federazione e alla distribuzione
  • sposando un modello basato sul controllo dell'email prima dell'accettazione della chiave
  • ricorrendo a limitazioni, filtri e valutazioni sulla bontà delle chiavi prima che queste vengano accettate.

I principali modelli di keyserver sono:

  • Hagrid
  • Mailvelope
  • HockeyPuck

Sono stati tutti creati per sopperire ai limiti dei server SKS.

Hagrid

Il primo, basato su SequoiaPGP, ha una natura centralizzata (non sarà mai federato), è GDPR compliant ed ha dato luogo a keys.openpgp.org.

I keyserver di questo tipo non aderiscono al modello WOT per ragioni di privacy e di efficienza. Sono quindi rifiutate le chiavi di terze parti, essenziali nel modello WOT, l'accettazione della chiave pubblica è vincolata dalla verifica dell'email, è possibile rimuovere le chiavi. Sono più resistenti agli attacchi di key poisoning.

Mailvelope

Ha dato luogo al keyserver keys.mailvelope.com, molto simile al primo e ne condivide la politica: no federazione, niente firme di terze parti e verifica dell'email vincolante per l'accettazione della chiave.

A differenza di altri keyserver, il focus di Mailvelope è la semplificazione dell'utilizzo della crittografia sull'e-mail, che sia webmail, con i provider e i browser che supportano Mailvelope, o client, quando si integrino con le sue api.

Hockeypuck

È un ritorno alle origini, ha una natura federata ed è considerato l'alternativa robusta ai server SKS. Uno fra i più noti server hockeypuck è certamente:

  • keyserver.ubuntu.com

il keyserver gestito dalla comunità Ubuntu che contiene le chiavi per i suoi pacchetti ma è anche aperto al pubblico.

Un altro keyserver hockeypuck più di nicchia perché legato ad una specifica realtà tecnologica olandese è:

  • pgp.surf.nl

Sebbene possa essere meno aggiornato del primo, può essere usato liberamente per pubblicare le proprie chiavi.

I keyserver di questo tipo, come il pool di server sks, anche se con un filtraggio più stringente, abbracciano il modello WOT con tutto quello che ne consegue.

Altri keyserver

Infine, per dovere di cronaca, bisogna citare due decani dei keyserver apparsi all'alba di pgp e ormai non più utilizzabili per motivi di obsolescenza e di abbandono.

pgp.mit.edu: uno dei primi repository a permettere la pubblicazione e la distribuzione di chiavi pubbliche, facente anche parte della rete SKS.

global.pgp.com: l'alternativa proprietaria, appartenente a PGP Corporation prima e Symantec dopo, era il repository centralizzato per la distribuzione di chiavi usato dall'applicazione pgp.

In conclusione, se la necessità è di utilizzare il WOT, allora la scelta è senza dubbio Hockeypuck quindi keyserver.ubuntu.com. Se invece la privacy è prioritaria, Hagrid quindi keys.openpgp.org diventa la scelta obbligatoria, tanto che è il default sia di GPG che di OpenKeyChain

#gpg #gnupg #crittografia #keyserver #hagrid #hockeypuck #mailvelope

]]> https://noblogo.org/aytin/gestire-la-tua-chiave-gpg Mon, 25 Nov 2024 15:00:37 +0000