Aldolat.it — Post con tag Sicurezza

La gestione del firewall in Arch Linux

aldolat@gmail.com (Aldo Latino) — Sun, 09 Mar 2025 11:23:58 +0100

È da tanto tempo che non attivo il firewall nella mia installazione Linux, e questo non è propriamente un bene. Fidandomi del fatto che nella mia rete locale non abbiamo dispositivi 'pericolosi', non ne ho mai sentito l'esigenza. Ma è sempre bene attivarlo. E la sua gestione oggi è davvero alla portata di tutti.

* * *

Introduzione

Quando un computer è collegato a una rete, questo avrà a che fare con la gestione di pacchetti IP che gli arrivano: il sistema dovrà prendere decisioni su cosa farne. In GNU/Linux la loro gestione è demandata a un componente del kernel che si chiama netfilter: con questo componente è possibile rispondere a questi pacchetti, ignorarli, bloccarli, instradarli da qualche altra parte. In poche parole, netfilter funge da firewall per la nostra macchina in rete. Per poter dire a netfilter cosa fare si possono usare due strumenti: iptables, quello storico per questa operazione, e nftables, più recente e proposto come sostituto del primo.

Ora, poiché iptables e nftables hanno una loro sintassi che non è proprio semplicissima, è disponibile da tempo uno strumento che rende la gestione del firewall alla portata di tutti: Uncomplicated firewall, noto anche come UFW.

UFW può gestire sia iptables che nftables. Nella mia installazione di Arch Linux uso iptables, anche perché è quello che conosco da più tempo ed è quello che è installato già di default.

Installazione di Uncomplicated firewall

Per installare UFW su Arch Linux, eseguire:

sudo pacman -S ufw

Dopo l’installazione, assicurarsi che il servizio sia attivo e che venga avviato assieme al sistema:

sudo systemctl enable ufw

sudo systemctl start ufw

Abilitare UFW con:

sudo ufw enable

Gestione delle regole

In questo momento, cioè subito dopo l’installazione, UFW è impostato così:

blocca tutte le connessioni in ingresso;
permette tutte le connessioni in uscita.

Dobbiamo quindi aggiungere delle regole. Ci sono due modi per farlo:

usare regole (app) preimpostate;
impostare delle regole personalizzate.

Uso delle regole preimpostate

UFW fornisce alcune configurazioni predefinite per applicazioni comuni. Per visualizzare l’elenco delle configurazioni disponibili, dare:

sudo ufw app list

L’output mostrerà un elenco di applicazioni con profili preconfigurati:

Available applications:
  AIM
  Bonjour
  CIFS
  DNS
  Deluge
  IMAP
  IMAPS
  IPP
  KTorrent
  Kerberos Admin
  Kerberos Full
  Kerberos KDC
  Kerberos Password
  LDAP
  LDAPS
  LPD
  MSN
  MSN SSL
  Mail submission
  NFS
  POP3
  POP3S
  PeopleNearby
  SMTP
  SSH
  Socks
  Telnet
  Transmission
  Transparent Proxy
  VNC
  WWW
  WWW Cache
  WWW Full
  WWW Secure
  XMPP
  Yahoo
  qBittorrent
  svnserve

Per ottenere maggiori dettagli su un profilo specifico, dare:

sudo ufw app info NOME_APP

Ad esempio, per visualizzare le informazioni sul profilo SSH:

sudo ufw app info SSH

Una volta individuata la regola preimpostata (ad esempio SSH), applicarla con questo comando:

sudo ufw allow SSH

Uso di regole personalizzate

La sintassi per impostare una regola personalizzata è più o meno la seguente:

sudo ufw [allow|deny] from [indirizzo_IP] to [indirizzo_IP|any] port [numero_porta] comment "[commento]"

Ad esempio:

sudo ufw allow from 192.168.0.0/24 to any port 22 comment "SSH"

Nota

Il to any significa che è permesso il traffico a qualunque nostro indirizzo IP. Potremmo ad esempio avere due schede di rete che hanno quindi due indirizzi IP differenti, per cui permettiamo con questa regola il traffico verso (to) qualunque indirizzo (any).

Oppure si può usare un modo più breve. In questo esempio si utilizza una porta personalizzata per SSH (2222):

sudo ufw allow 2222/tcp

Altri esempi:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw deny from 192.168.1.100

sudo ufw deny 8080/tcp

sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp

Visualizzare le regole attuali

Si possono vedere le regole attuali in modi diversi, ognuno con un suo output:

sudo ufw status

sudo ufw status verbose

sudo ufw status numbered

Ad esempio:

$ sudo ufw status verbose 
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22                         ALLOW IN    192.168.0.0/24             # SSH
137,138/udp                ALLOW IN    192.168.0.0/24             # Samba NetBIOS UDP
139,445/tcp                ALLOW IN    192.168.0.0/24             # Samba SMB TCP
1714:1764/tcp              ALLOW IN    192.168.0.0/24             # KDE Connect TCP
1714:1764/udp              ALLOW IN    192.168.0.0/24             # KDE Connect UDP

Eliminare una regola

Individuare il numero della regola con:

sudo ufw status numbered

e quindi:

sudo ufw delete NUMERO_REGOLA

Monitorare il firewall

Abilitare il logging

La registrazione degli eventi (logging) di UFW va attivata con:

sudo ufw logging on

È possibile poi specificare quali log conservare. I livelli di log disponibili sono:

off → nessun log
low → solo i pacchetti bloccati
medium → connessioni accettate e bloccate
high → dettagli estesi su ogni pacchetto
full → ancora più dettagli

Il livello che solitamente scelgo è low:

sudo ufw logging low

Controllare i log

Su Arch Linux, i log di UFW non vengono salvati in /var/log/ufw.log, come avviene in altre distribuzioni. Arch invece utilizza systemd-journald per la gestione dei log di UFW.

Per vedere i log dare:

sudo journalctl -k | grep 'UFW'

Oppure:

sudo dmesg | grep 'UFW'

Consiglio

Poiché dmesg sarà popolato da messaggi di UFW, è possibile avviare dmesg senza visualizzarli. Dare:

sudo dmesg | sed '/UFW/d'

Disabilitare e reimpostare il firewall

Se si ha bisogno di disattivare temporaneamente UFW:

sudo ufw disable

Per rimuovere completamente tutte le regole e reimpostare UFW:

sudo ufw reset

Regole che solitamente uso

Io solitamente non uso le regole preimpostate, ma preferisco definirle a mano. Scrivo qui quelle che uso io.

SSH

SSH usa questa porta e protocollo:

Porta	Protocollo	Uso
`22`	TCP	Connessione SSH

Per cui questa la regola da impostare:

sudo ufw allow from 192.168.0.0/24 to any port 22 comment "SSH"

Come si vede non è necessario specificare proto tcp.

Samba

Samba usa queste porte e protocolli:

Porta	Protocollo	Uso
`137`	UDP	NetBIOS Name Service
`138`	UDP	NetBIOS Datagram Service
`139`	TCP	NetBIOS Session Service
`445`	TCP	SMB Direct

Per cui queste le regole da impostare:

sudo ufw allow from 192.168.0.0/24 to any port 137,138 proto udp comment "Samba NetBIOS UDP"

sudo ufw allow from 192.168.0.0/24 to any port 139,445 proto tcp comment "Samba SMB TCP"

KDE Connect

KDE Connect usa queste porte e protocolli:

Porta	Protocollo	Uso
`1714-1764`	TCP	Comunicazione principale tra dispositivi
`1714-1764`	UDP	Scoperta automatica dei dispositivi nella rete

Per cui queste le regole da impostare:

sudo ufw allow from 192.168.0.0/24 to any port 1714:1764 proto tcp comment "KDE Connect TCP"

sudo ufw allow from 192.168.0.0/24 to any port 1714:1764 proto udp comment "KDE Connect UDP"

L'articolo La gestione del firewall in Arch Linux è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Checklist per la sicurezza digitale del giornalista nel 2025

aldolat@gmail.com (Aldo Latino) — Sun, 05 Jan 2025 09:51:58 +0100

Leggo e rilancio questo articolo di Davis Erin Anderson e Dr. Martin Shelton dal titolo The 2025 journalist’s digital security checklist, pubblicato dalla Freedom of the Press Foundation e dedicato alla sicurezza digitale del giornalista oggi. Cito questo brano tratto dall’introduzione:

In tumultuous times, we believe in being prepared, not scared. Sound digital security practice often involves forming and relying on good habits. Building these reflexes now will help keep you better protected. This is why we’ve distilled advice our trainers have shared with thousands of journalists over the years into the actionable, concrete steps below.

Before you dive in, know that there are many ways to shore up your safety and privacy. It’s OK to take them on slowly but surely, one at a time. If you run into any challenges, remember: the Digital Security Training team at Freedom of the Press Foundation (FPF) is here to help. Reach out here.¹

L’articolo completo è reperibile qui:

https://freedom.press/digisec/blog/journalists-digital-security-checklist/

Risorse online

Electronic Frontier Foundation, Surveillance Self-Defense.
Sophia Cope, Amul Kalia, Seth Schoen, Adam Schwartz, Digital Privacy at the U.S. Border: Protecting the Data On Your Devices, Electronic Frontier Foundation.
Free Software Foundation, Autodifesa email.
Freedom of the Press Foundation, Digital Security Education.
Daniel Gray et alii, Privacy Guides.
Front Line Defenders, Security in-a-box. Digital security tools and tactics.
Open Rights Group, Know your digital rights: a guide to subject access requests.
Manualetto di sicurezza digitale per giornalisti e attivisti, a cura di Carola Frediani, Sonia Montegiove, Patrizio Tufarolo, con i contributi di Raﬀaele Angius, Carola Frediani, Sonia Montegiove, Rosita Rijtano, Matteo Spinelli, Taylor, CRP, Guerre di Rete, 2026.

Davis Erin Anderson, Dr. Martin Shelton, The 2025 journalist’s digital security checklist, Freedom of the Press Foundation, 10 dicembre 2024. ↩︎

L'articolo Checklist per la sicurezza digitale del giornalista nel 2025 è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

nwipe e ShredOS

aldolat@gmail.com (Aldo Latino) — Sat, 04 Jan 2025 22:09:08 +0100

Leggendo il feed RSS di Schneier, apprendo dell’esistenza di nwipe e di ShredOS, tool dedicati alla ‘distruzione software’ di uno o più dischi. Per ‘distruzione software’ intendo la cancellazione abbastanza sicura dei contenuti presenti in un disco, cosa che ci permette il riutilizzo del disco per esigenze diverse da quelle personali: un esempio per tutti, la cessione di un disco ad altre persone per i loro usi. Dal sito dello sviluppatore di nwipe si legge:

nwipe is a program that will securely erase the entire contents of disks.¹

È uno strumento che ce ne richiama alla mente un altro, vale a dire shred, di cui ho parlato qui, ma dedicato quest’ultimo a singoli file.

Questo strumento, invece, scaricabile da GitHub ma probabilmente presente nella vostra distro, è dedicato appunto a interi dischi e ha un’interfaccia del tipo:

L’interfaccia di nwipe.

Alla fine della cancellazione del disco, nwipe vi genera anche un “certificato”, un rapporto in PDF con le operazioni eseguite.

Agganciata a questo strumento, è stata creata un’intera distribuzione Linux, chiamata ShredOS e scaricabile anch’essa da GitHub. Una volta avviata la distribuzione da chiavetta, magari usando il comodissimo Ventoy, si ha a disposizione un potente strumento per la cancellazione di tutti i dischi attaccati a quella macchina: nwipe può infatti eseguire una cancellazione in parallelo di tutti i dischi presenti.

Questa è l’interfaccia di ShredOS una volta avviato da chiavetta:

Come si presenta ShredOS.

Che dire: strumenti potenti per operazioni complesse a portata di mano.

Martijn van Brummelen, nwipe su GitHub. ↩︎

L'articolo nwipe e ShredOS è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

No alle email in HTML /2

aldolat@gmail.com (Aldo Latino) — Wed, 21 Aug 2024 11:09:38 +0200

Ho scritto qualche anno fa in merito e vorrei ribadire ed estendere quanto già comunicato. Ho trovato per caso la pagina Use plain text email, citata sia dal Wiki di Arch Linux sia da The Linux Kernel Archive, dove nella sezione “Why is plain text better than HTML?” elenca i motivi per cui è bene evitare come la peste le email in HTML. Elenco solo i titoli dei paragrafi:

HTML as a vector for phishing
Privacy invasion and tracking
Higher incidence of spam
Mail client vulnerabilities
HTML emails are less accessible
Some clients can’t display HTML emails at all
Rich text isn’t that great, anyway

L'articolo No alle email in HTML /2 è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

La direttiva Order in Apache

aldolat@gmail.com (Aldo Latino) — Sun, 06 Aug 2023 10:25:24 +0200

Uno dei punti fondamentali¹ da comprendere per il controllo del proprio server Apache è la direttiva Order, quella in cui vediamo Allow,Deny o Deny,Allow. Non è di immediata comprensione ma, una volta capito il meccanismo che sta alla base, non dovrebbe risultare difficile applicarla con relativa semplicità.

Poniamo il caso che abbiamo queste direttive nel nostro file .htaccess:

<Directory "/www">
    Order Deny,Allow
    Deny from all
    Allow from 192.168.0.100 123.456.
    Allow from example.org example.com
    Allow from foo.example.
</Directory>

Quello su cui questo post si concentra è la riga che inizia con Order. Questa direttiva dice ad Apache in quale ordine deve applicare le successive direttive Deny e Allow, vale a dire se prima l’una o l’altra. Nel caso in esempio, l’ordine è prima quelle Deny e poi quelle Allow. L’ordine è importante perché in Apache l’ultima direttiva ha priorità sulle precedenti.

Detta in modo semplice quelle righe significano:

nega (Deny) a tutti l’accesso alla directory /www;
permettilo (Allow) a chi proviene dall’indirizzo IP 192.168.0.100 e a chi abbia indirizzo IP che comincia con 123.456.;
permettilo (Allow) a chi proviene dal dominio example.org o da example.com;
permettilo (Allow) a chi proviene dal dominio foo.example. di qualsiasi TLD.

Se, invece, invertissimo l’ordine della direttiva Order da Order Deny,Allow a Order Allow,Deny, l’effetto sarebbe di bloccare tutti. Avremmo infatti che Apache leggerebbe così:

permetti l’accesso all’indirizzo IP 192.168.0.100 e a chi abbia…;
permetti l’accesso al dominio example.org…;
ecc…
nega a tutti l’accesso.

La regola finale avrebbe la prevalenza sulle precedenti, finendo così per bloccare tutti.

L’ordine con cui le direttive sono scritte nel blocco di codice non ha invece alcuna influenza.² Potremmo anche scriverle così:

<Directory "/www">
    Order Deny,Allow
    Allow from 192.168.0.100 123.456.
    Allow from example.org example.com
    Deny from all
    Allow from foo.example.
</Directory>

In ogni caso Apache leggerà e applicherà in blocco prima tutte le direttive Deny e poi tutte quelle Allow. In linea generale, Jeff Starr³ consiglia di tenere queste due regole di base:

Quando si vogliono bloccare specifici indirizzi, usare Order Allow,Deny, quindi la direttiva Allow from all e a seguire le direttive Deny from .... Ad esempio:
```
<Directory "/www">
    Order Allow,Deny
    Allow from all
    Deny from 192.168.0.100
</Directory>
```
Quando si vogliono permettere specifici indirizzi, usare Order Deny,Allow, quindi la direttiva Deny from all e a seguire le direttive Allow from .... Ad esempio:
```
<Directory "/www">
    Order Deny,Allow
    Deny from all
    Allow from 192.168.0.100
</Directory>
```

Bibliografia

The Apache Software Foundation, Apache Module mod_access_compat.
Ben Laurie – Peter Laurie, Apache: The Definitive Guide, O’Reilly & Associates, 2001.
Jeff Starr, .htaccess made easy, Perishable Press Books, aprile 2023.

«Getting the order and syntax of these directives is critical to their operation». Jeff Starr, .htaccess made easy, Perishable Press Books, aprile 2023, p. 123. ↩︎
«The order in which lines appear in the configuration files is not significant — all Allow lines are processed as one group, all Deny lines are considered as another, and the default state is considered by itself». Cfr. The Apache Software Foundation, Apache Module mod_access_compat, par. “Order Directive”. ↩︎
Jeff Starr, op. cit., p. 123. ↩︎

L'articolo La direttiva Order in Apache è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Video Guida sulle chiavi YubiKey

aldolat@gmail.com (Aldo Latino) — Sat, 16 Apr 2022 21:06:12 +0200

Una guida molto interessante di LearnLinuxTV sulle chiavi YubiKey:

https://www.youtube.com/watch?v=INi-xKpYjbE

L'articolo Video Guida sulle chiavi YubiKey è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Generazione sicura di chiavi OpenPGP

aldolat@gmail.com (Aldo Latino) — Thu, 07 Apr 2022 21:32:25 +0200

Generare una coppia di chiavi con GnuPG è un'operazione semplice, ma se abbiamo l'esigenza di crearle e proteggerle in un modo abbastanza sicuro, al riparo da sguardi indiscreti per le più svariate ragioni, allora bisogna prendere qualche precauzione. Sviluppatori di software, giornalisti, whistleblower e utenti che vivono in stati ficcanaso potrebbero aver bisogno di un ambiente _sanificato_. In questa guida vedremo una strada possibile per arrivare a generarle in modo abbastanza sicuro, soprattutto tentando di proteggere in modo diretto la chiave "master", vale a dire quella che è il fondamento di tutto il mazzo di chiavi. Non si tratta di una guida per tutti, soprattutto perché nel tempo la gestione del portachiavi è onerosa in termini di cura e attenzione.

* * *

Introduzione

Come sappiamo,¹ tutto il sistema della crittografia a chiave pubblica si basa sull’uso di una chiave che ha una parte pubblica, da divulgare il più possibile, e una parte privata, che va tenuta rigorosamente in un luogo sicuro. Qualora avessimo il dubbio che le chiavi private possano essere in mani altrui, saremmo obbligati a generare un nuovo mazzo di chiavi, con tutto quello che ne comporta (revoca delle chiavi, perdita del lavoro fatto per il Web of Trust, perdita delle firme apposte sulla nostra chiave).

Con questa guida vedremo come:

generare in un luogo abbastanza sicuro il nostro mazzo di chiavi personale;
proteggere le chiavi private in modo da usarle ogni giorno in un modo abbastanza sicuro.

Generalmente un mazzo di chiavi personale è composto in modo predefinito da:

una chiave master (o principale) per la firma e la certificazione;
una sottochiave per la cifratura.

Noi, invece, per elevare la sicurezza del nostro portachiavi spingeremo al massimo il concetto delle sottochiavi. La struttura del nostro portachiavi personale, infatti, sarà la seguente:

Chiave master (o principale) per sola certificazione di chiavi altrui con dimensione 4096 bit e scadenza dopo 3 anni;
- Sottochiave per firma con dimensione 2048 bit e scadenza dopo 1 anno;
- Sottochiave per cifratura con dimensione 2048 bit e scadenza dopo 1 anno;
- Sottochiave per autenticazione con dimensione 2048 bit e scadenza dopo 1 anno.

Avremo quindi una chiave distinta per ogni operazione.

La chiave più importante è la chiave master. Questa chiave è talmente importante che, qualora fosse stata compromessa, ci costringerebbe a revocare l’intero mazzo di chiavi e a generarne di nuove. Per questo motivo la terremo in cassaforte, separata dal resto del mazzo di chiavi. Visto che la terremo separata dal resto, la abiliteremo solo per scopi che non sono quotidiani, ma solo periodiche (come ad esempio il rinnovo della validità delle chiavi) o per occasioni speciali (come ad esempio un Key signing party). Lo scopo della chiave master sarà quello di certificare chiavi altrui ed, essendo la chiave principale, di effettuare operazioni di manutenzione del nostro mazzo di chiavi (estensione validità, aggiunta di nomi utente, ecc.).

Le sottochiavi, invece, saranno utilizzate quotidianamente. Le sottochiavi hanno la caratteristica che possono esistere nel portachiavi di GnuPG anche senza la presenza della chiave principale. Per questo motivo, dopo aver fatto un sicuro backup, elimineremo dal portachiavi la chiave principale, lasciando solo le sottochiavi. Le sottochiavi, per loro natura, potrebbero anche essere compromesse (cosa che non dobbiamo permettere mai e, a tal scopo, vedremo come proteggerle), ma questo non invaliderebbe l’intero mazzo di chiavi: qualora una sottochiave fosse compromessa, potremmo revocarla e crearne un’altra per lo stesso scopo. Le sottochiavi potrebbero anche scadere e, qualora non volessimo rinnovarle, potremmo generarne di nuove. Oppure potremmo generare una sottochiave per un evento particolare (un convegno o altro), che ha quindi una durata limitata (un mese, un anno) e lasciarla scadere dopo la fine dell’evento.

Per proteggere le nostre sottochiavi, le sposteremo su un token USB come la YubiKey. Si tratta di token praticamente indistruttibili, che rendono l’uso della firma digitale, la cifratura e l’autenticazione su sistemi (come SSH) molto comodi (basterà usare un PIN numerico al posto della passphrase). Io uso la YubiKey 4. I token come YubiKey hanno il pregio che non permettono l’esportazione delle chiavi lì conservate; questo significa che posso usare le mie chiavi anche in un ambiente poco sicuro come un Internet Point, un PC condiviso, ecc., senza il timore che le chiavi private possano essere copiate da qualche parte a mia insaputa. Quand’anche fosse stato intercettato il PIN da un keylogger o da un malware, la passphrase è ancora al sicuro, ed eventualmente posso cambiare il PIN. Il fatto che le sottochiavi, una volta trasferite, non possano essere esportate dalla YubiKey, ci forzerà a effettuare il backup del nostro mazzo di chiavi prima del trasferimento, ma questo aspetto lo vedremo al momento opportuno.

Alla fine della guida avremo quindi la seguente situazione:

la chiave principale sarà rimossa dal portachiavi sul disco e trasferita in un luogo sicuro;
le sottochiavi risiederanno sulla YubiKey.

Nel nostro disco fisso non avremo quindi nessuna chiave privata. Potremmo anche perdere il nostro PC o potrebbero anche rubarcelo, ma il nostro mazzo di chiavi sarà sempre al sicuro. Potremmo anche perdere la nostra YubiKey, ma essa contiene solo le sottochiavi che, come abbiamo visto, possiamo revocare con la chiave principale (che sta in cassaforte) e ricrearne di nuove. Quando sarà necessario effettuare un’operazione speciale, come ad esempio apporre la nostra firma su chiavi altrui o aggiungere/eliminare una sottochiave o una UserID, importeremo la chiave principale nel nostro portachiavi, effettueremo l’operazione necessaria e infine la rimuoveremo di nuovo.

Un ultimo punto prima di passare alla pratica. Il motivo di avere una scadenza sulle chiavi è un ulteriore sicurezza per noi. Immaginiamo il caso in cui dovessimo perdere il controllo del nostro mazzo di chiavi, compresa la chiave principale, e non avessimo più a disposizione nemmeno il certificato di revoca. In questo caso la scadenza sarà una garanzia per noi che a un certo punto le chiavi scadranno in modo naturale. Per i tempi di scadenza ognuno può scegliere quello che più ritenga opportuno, ma 3 anni per la principale e 1 anno per le sottochiavi dovrebbe essere un buon compromesso tra la seccatura di dover manutenzionare il portachiavi e il tempo di scadenza naturale dopo eventuale compromissione.

Questa guida può essere seguita in modo modulare:

si può scegliere di mantenere tutte le chiavi sul proprio disco fisso, seguendo solo la parte sulla generazione sicura delle chiavi;
si può scegliere di spostare in un luogo sicuro la chiave principale dal resto del proprio mazzo di chiavi, mantenendo nel disco fisso solo le sottochiavi;
si può scegliere di spostare le sottochiavi in un token USB come la YubiKey, mantenendo la chiave principale nel disco fisso;
si può scegliere di spostare le sottochiavi in un token USB come la YubiKey e di spostare la chiave principale in un luogo sicuro, non lasciando nessuna chiave privata nel disco fisso.

Una nota prima di cominciare. Lungo la guida i vari comandi da terminale useranno ID di chiave, keygrip, percorsi nel disco fisso e quant’altro che fanno riferimento a quanto eseguito per scrivere la guida. Ciò significa che dovrete sostituire gli ID di chiave, i keygrip, i percorsi e quant’altro con quelli vostri. Ad esempio, in un comando come questo:

gpg --with-keygrip --list-key 0x9F676B5A4B6E6777

dovrete sostituire 0x9F676B5A4B6E6777 con l’ID corretto della vostra chiave.

Generazione delle chiavi

Con questa guida genereremo la nostra chiave privata che avrà questo schema:

Chiave master (o principale) [C – Certification/Certificazione]
- Sottochiave per firma [S – Signing/Firma]
- Sottochiave per cifratura [E – Encryption/Cifratura]
- Sottochiave per autenticazione [A – Authentication/Autenticazione]

Per la lunghezza delle chiavi avremo la chiave primaria a 4096 bit mentre le sottochiavi a 2048 bit. Per ulteriori informazioni su questo dibattito della lunghezza delle chiavi si può vedere:

Why does GnuPG default to 2048 bit RSA-2048? sul sito di GnuPG;
The Big Debate, 2048 vs. 4096, Yubico’s Position sul blog di Yubico.

Prerequisiti

È necessario lavorare su un sistema avviato con una distribuzione Linux in modalità live. È preferibile una Tails, ma va bene una qualunque. La distribuzione va avviata isolandola da qualsiasi rete.
È necessario usare GnuPG versione 2.1 o successiva.
È necessario un token USB come, ad esempio, una YubiKey, nel caso si decida di spostare le sottochiavi su questo supporto.

Qualora il comando gpg lanci GnuPG versione 1, accertarsi che la versione 2 sia installata e aggiungere questa riga a ~/.bashrc (o a ~/.bash_aliases se usate questo file):

alias gpg='gpg2'

Questa scorciatoia permetterà l’avvio di GnuPG versione 2 ogni volta che digitiamo gpg.

Generare le chiavi

Sul sistema di generazione delle chiavi accertarsi di avere GnuPG versione 2.1 o successiva:

gpg --version

Iniziare quindi la procedura con:

gpg --expert --full-gen-key

che darà:

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
Your selection?

Scegliamo 8:

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Sign Certify Encrypt

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection?

Come si vede le attuali capacità della chiave che stiamo creando sono: Sign Certify Encrypt. Rimuoviamo le capacità di firma premendo S:

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify Encrypt

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection?

Rimuoviamo le capacità di cifratura premendo E:

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection?

Ora la chiave primaria avrà solo la capacità di certificazione (Certify) su altre chiavi.

Premiamo Q:

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

Inserire 4096:

Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)

Inseriamo 3y (3 anni):

Key expires at mer 31 mar 2021 19:46:05 CEST
Is this correct? (y/N)

Premiamo Y:

GnuPG needs to construct a user ID to identify your key.

Real name:
Email address:
Comment:

Inseriamo il nostro nome e cognome e quindi l’indirizzo email. Come commento lasciamo il campo vuoto.

You selected this USER-ID:
    "Mario Rossi <mario.rossi@example.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

Accettare con O:

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

A seguire GnuPG chiederà di impostare la passphrase.

Impostiamo la passphrase.

gpg: key 4B6E6777 marked as ultimately trusted
gpg: directory '/home/mariorossi/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/mariorossi/.gnupg/openpgp-revocs.d/491532759708014725CFE3A79F676B5A4B6E6777.rev'
public and secret key created and signed.

gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: PGP
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2021-03-31
pub   rsa4096/4B6E6777 2018-04-01 [C] [expires: 2021-03-31]
      Key fingerprint = 4915 3275 9708 0147 25CF  E3A7 9F67 6B5A 4B6E 6777
uid         [ultimate] Mario Rossi <mario.rossi@example.com>

GnuPG mostra la chiave appena generata ed esce.

Come si vede, esiste solo la chiave principale con la sola capacità di certificazione [C]. Bisogna ora generare le sottochiavi con:

gpg --expert --edit-key 0x4B6E6777

gpg (GnuPG) 2.1.11; Copyright (C) 2016 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa4096/4B6E6777
     created: 2018-04-01  expires: 2021-03-31  usage: C
     trust: ultimate      validity: ultimate
[ultimate] (1). Mario Rossi <mario.rossi@example.com>

gpg>

Dare il comando addkey:

Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (12) ECC (encrypt only)
  (13) Existing key
Your selection?

Scegliere 8:

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Sign Encrypt

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection?

Togliere la capacità di cifratura premendo E:

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Sign

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection?

Scegliere Q:

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

Premere Invio per accettare 2048:

Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)

Inserire 1y per farla scadere dopo 1 anno:

Key expires at lun 01 apr 2019 19:57:16 CEST
Is this correct? (y/N)

Accettare inserendo Y:

Really create? (y/N)

Accettare inserendo Y.

Inserire quindi la passphrase e la sottochiave sarà aggiunta al portachiavi:

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

Attendiamo che finisca, quindi apparirà:

sec  rsa4096/4B6E6777
     created: 2018-04-01  expires: 2021-03-31  usage: C
     trust: ultimate      validity: ultimate
ssb  rsa2048/9114F367
     created: 2018-04-01  expires: 2019-04-01  usage: S
[ultimate] (1). Mario Rossi <mario.rossi@example.com>

gpg>

Aggiungiamo ora con la stessa procedura (partendo da addkey) la chiave di cifratura e poi quella di autenticazione. Alla fine, dopo aver aggiunto la sottochiave di autenticazione, dare il comando:

save

per salvare e uscire.

Alla fine avremo questo portachiavi:

gpg --list-secret-keys

/home/mariorossi/.gnupg/pubring.kbx
-----------------------------
sec   rsa4096/4B6E6777 2018-04-01 [C] [expires: 2021-03-31]
uid         [ultimate] Mario Rossi <mario.rossi@example.com>
ssb   rsa2048/9114F367 2018-04-01 [S] [expires: 2019-04-01]
ssb   rsa2048/2F3AC08A 2018-04-01 [E] [expires: 2019-04-01]
ssb   rsa2048/AFBE0F10 2018-04-01 [A] [expires: 2019-04-01]

La situazione è, quindi, la seguente:

chiave principale, adibita alla sola certificazione e gestione del portachiavi: sec rsa4096/4B6E6777 2018-04-01 [C];
sottochiave di firma: ssb rsa2048/9114F367 2018-04-01 [S];
sottochiave di cifratura: ssb rsa2048/2F3AC08A 2018-04-01 [E] [expires: 2019-04-01];
sottochiave di autenticazione: ssb rsa2048/AFBE0F10 2018-04-01 [A] [expires: 2019-04-01].

Possiamo aggiungere anche altri UserID o una foto con:

gpg --expert --edit-key 0x4B6E6777

e poi con adduid.

Il certificato di revoca

Con GnuPG versione 2 la generazione del certificato di revoca è stata fatta automaticamente quando le chiavi sono state generate e si trova nella directory ~/.gnupg/openpgp-revocs.d/. Il file ha lo stesso nome dell’impronta della chiave, nel nostro caso:

491532759708014725CFE3A79F676B5A4B6E6777.rev

Questo file andrà tolto da questa directory e conservato in un luogo sicuro. Lo vedremo nel paragrafo dedicato al backup.

Impostare le preferenze della chiave

Modificare la chiave con:

gpg --expert --edit-key 0x4B6E6777

Dal prompt di Gnupg dare:

setpref S10 S9 S8 H10 H9 H8 Z2 Z3 Z1 Z0

che significa:

S10 Cifrario Twofish
S9 Cifrario AES256
S8 Cifrario AES192
H10 Hash SHA512
H9 Hash SHA384
H8 Hash SHA256
Z2 Compressione ZLIB
Z3 Compressione BZIP2
Z1 Compressione ZIP
Z0 Non compresso

Alla domanda di GnuPG seguente:

Set preference list to:
     Cipher: TWOFISH, AES256, AES192, 3DES
     Digest: SHA512, SHA384, SHA256, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences? (y/N)

premere Y e quindi:

save

Impostare il file gpg.conf

Aprire il file gpg.conf dentro la directory ~/.gnupg, eliminare tutto il contenuto e incollarvi questo testo, ricordandosi di aggiornare le due ID di chiave nelle righe default-key e encrypt-to con l’ID della vostra chiave:

# Per lo skeleton di questo file vedi:
# /usr/share/gnupg2/gpg-conf.skel

#-----------------------------
# default key
#-----------------------------

# The default key to sign with. If this option is not used, the default key is
# the first key found in the secret keyring

default-key 0x9F676B5A4B6E6777
encrypt-to  0x9F676B5A4B6E6777

#-----------------------------
# behavior
#-----------------------------

# Disable inclusion of the version string in ASCII armored output
no-emit-version

# Disable comment string in clear text signatures and ASCII armored messages
no-comments

# Display long key IDs
keyid-format 0xlong

# List all keys (or the specified ones) along with their fingerprints
with-fingerprint

# List all keys (or the specified ones) along with their keygrips
with-keygrip

# Display the calculated validity of user IDs during key listings
list-options show-uid-validity
verify-options show-uid-validity

# Try to use the GnuPG-Agent. With this option, GnuPG first tries to connect to
# the agent before it asks for a passphrase.
use-agent

#-----------------------------
# keyserver
#-----------------------------

# When using --refresh-keys, if the key in question has a preferred keyserver
# URL, then disable use of that preferred keyserver to refresh the key from
keyserver-options no-honor-keyserver-url

# When searching for a key with --search-keys, include keys that are marked on
# the keyserver as revoked
keyserver-options include-revoked

#-----------------------------
# algorithm and ciphers
#-----------------------------

# List of personal digest preferences. When multiple digests are supported by
# all recipients, choose the strongest one
personal-cipher-preferences TWOFISH AES256 AES192 3DES

# List of personal digest preferences. When multiple ciphers are supported by
# all recipients, choose the strongest one
personal-digest-preferences SHA512 SHA384 SHA256 SHA224

# Message digest algorithm used when signing a key
cert-digest-algo SHA512

# List of personal compression preferences.
personal-compress-preferences ZLIB BZIP2 ZIP Uncompressed

# This preference list is used for new keys and becomes the default for
# "setpref" in the edit menu
default-preference-list SHA512 SHA384 SHA256 SHA224 TWOFISH AES256 AES192 3DES ZLIB BZIP2 ZIP Uncompressed

Impostare il keyserver

Modificare (o creare) il file ~/.gnupg/dirmngr.conf:

# Per lo skeleton di questo file vedi:
# /usr/share/gnupg2/dirmngr-conf.skel

# This is the server that --recv-keys, --send-keys, and --search-keys will
# communicate with to receive keys from, send keys to, and search for keys on
keyserver hkps://hkps.pool.sks-keyservers.net

Copiare la directory .gnupg nel proprio computer di lavoro

A questo punto, se avete usato una distribuzione live per la generazione delle chiavi, copiate tutta la directory .gnupg su una chiavetta USB e quindi trasferitela sul disco fisso del computer di lavoro.

Dopo il trasferimento non dimenticate di distruggere la directory .gnupg sulla chiavetta. Si possono usare diversi strumenti come ad esempio shred.

Esportare la chiave pubblica sul keyserver

gpg --send-keys 0x9F676B5A4B6E6777

Segnarsi la data di scadenza delle proprie chiavi nel calendario

Segnatevi nel vostro calendario quando scadranno le chiavi e fatevi mandare un avviso almeno un mese prima. Una volta rinnovate le chiavi, inviatele al keyserver. Ricordate che le chiavi scadute possono essere ancora rinnovate, ma non è buona norma farle scadere.

Fare il backup

Dopo aver generato il nostro mazzo di chiavi è fondamentale farne il backup. Davvero, non si prenda alla leggera questo passaggio e non proseguite oltre se non fate il backup.

Faremo il backup di questi tre elementi:

directory di GnuPG;
chiavi;
certificato di revoca.

Creiamo una directory backup e relative sottodirectory sulla scrivania del PC dove metteremo tutti i file del backup:

mkdir -p ~/Scrivania/backup/directory_gnupg

mkdir ~/Scrivania/backup/chiavi

mkdir ~/Scrivania/backup/certificato_di_revoca

Cambiate Scrivania con Desktop se è il vostro caso.

Backup della directory di GnuPG

Anzitutto facciamo il backup di tutta la directory di GnuPG così come si trova in questo momento. Qualora qualcosa dovesse andare storto, potremmo sempre ripristinarla e cominciare daccapo.

cp -r ~/.gnupg/ ~/Scrivania/backup/directory_gnupg/

Verificate che nella directory di backup ci sia la sotto-directory private-keys-v1.d con all’interno i file privati delle chiavi. Ce ne devono essere uno per ogni chiave privata, vale a dire uno per la chiave master e uno per ogni sottochiave.

Backup delle chiavi

Vediamo anzitutto la situazione delle nostre chiavi private:

gpg --list-secret-keys

che restituirà qualcosa del tipo:

sec   rsa4096/0x9F676B5A4B6E6777 2018-04-01 [C] [expires: 2021-03-31]
      Key fingerprint = 4915 3275 9708 0147 25CF  E3A7 9F67 6B5A 4B6E 6777
      Keygrip = C6D1CD1D12CBBC8FA14D30004EAF381803A72597
uid                   [ultimate] Mario Rossi <mario.rossi@example.com>
ssb   rsa2048/0xE7E0CAF69114F367 2018-04-01 [S] [expires: 2019-04-01]
      Keygrip = 135159EDEFB9FCB6062F9DE0E21FD90CB07DA041
ssb   rsa2048/0x3C91B3682F3AC08A 2018-04-01 [E] [expires: 2019-04-01]
      Keygrip = C74D47329D5D224B0716879DCF3A4EC2D8951C53
ssb   rsa2048/0x465ED456AFBE0F10 2018-04-01 [A] [expires: 2019-04-01]
      Keygrip = 30DEE8A060F3562CD6F1384E0F883D65477E596A

Procediamo ad effettuare un backup di tutta la chiave (principale e sottochiavi) e anche delle singole chiavi. Questo è quello che otterremo:

backup chiave completa;
backup chiave principale;
backup di tutte le sottochiavi;
backup sottochiave di firma;
backup sottochiave di cifratura;
backup sottochiave di autenticazione;
backup chiave pubblica;
backup chiave SSH.

Qui di sotto gli otto comandi di cui sopra, eseguiti uno dopo l’altro. Notate come in alcuni casi l’opzione è --export-secret-keys oppure --export-secret-subkeys e con un punto esclamativo ! dopo l’ID della chiave. Si veda la tabella più sotto per una visione d’insieme.

gpg --armor --export-secret-keys 0x9F676B5A4B6E6777 > ~/Scrivania/backup/chiavi/1_principale_con_sottochiavi_0x9F676B5A4B6E6777.asc

gpg --armor --export-secret-keys 0x9F676B5A4B6E6777! > ~/Scrivania/backup/chiavi/2_principale_soltanto_0x9F676B5A4B6E6777.asc

gpg --armor --export-secret-subkeys 0x9F676B5A4B6E6777 > ~/Scrivania/backup/chiavi/3_sottochiavi_0x9F676B5A4B6E6777.asc

gpg --armor --export-secret-subkeys 0xE7E0CAF69114F367! > ~/Scrivania/backup/chiavi/4_sottochiave_firma_0xE7E0CAF69114F367.asc

gpg --armor --export-secret-subkeys 0x3C91B3682F3AC08A! > ~/Scrivania/backup/chiavi/5_sottochiave_cifratura_0x3C91B3682F3AC08A.asc

gpg --armor --export-secret-subkeys 0x465ED456AFBE0F10! > ~/Scrivania/backup/chiavi/6_sottochiave_autenticazione_0x465ED456AFBE0F10.asc

gpg --armor --export 0x9F676B5A4B6E6777 > ~/Scrivania/backup/chiavi/7_chiave_pubblica_0x9F676B5A4B6E6777.asc

gpg --armor --export-ssh-key 0x9F676B5A4B6E6777 > ~/Scrivania/backup/chiavi/8_chiave_pubblica_ssh_0x9F676B5A4B6E6777.asc

Opzione	Descrizione
`export {chiave}`	Esporta la chiave pubblica identificata da `{chiave}`
`export-ssh-key {chiave}`	Esporta la chiave pubblica `ssh` identificata da `{chiave}`
`export-secret-keys {chiave}`	Esporta tutto il mazzo di chiavi private
`export-secret-keys {chiave}!`	Esporta solo la chiave privata master identificata da `{chiave}`
`export-secret-subkeys {chiave}`	Esporta tutte le sottochiavi private
`export-secret-subkeys {chiave}!`	Esporta la sottochiave privata identificata da `{chiave}`

Tabella 1. Le opzioni di GnuPG per esportare le chiavi.

Backup del certificato di revoca

Come abbiamo detto al paragrafo “Il certificato di revoca”, questo è stato già creato da GnuPG versione 2 nella directory ~/.gnupg/openpgp-revocs.d/ ed il file ha lo stesso nome dell’impronta della chiave, nel nostro caso

491532759708014725CFE3A79F676B5A4B6E6777.rev

Spostiamolo dalla directory ~/.gnupg alla directory di backup:

mv ~/.gnupg/openpgp-revocs.d/491532759708014725CFE3A79F676B5A4B6E6777.rev ~/Scrivania/backup/certificato_di_revoca/

Eventualmente è anche possibile stampare su carta il certificato e conservarlo in cassaforte.

Spostare la directory di backup in un luogo sicuro

Finito il backup, spostare la directory ~/Scrivania/backup in almeno due supporti da conservare in due luoghi distinti e sicuri.

A seconda di quanta importanza hanno queste chiavi per voi, posso consigliare una situazione del genere:

copia della cartella su una chiavetta USB da usare solo per questo scopo, conservata in un luogo sicuro e nascosto, ad esempio la vostra cassaforte in casa;
copia di sicurezza su una seconda chiavetta USB da usare solo per questo scopo, conservata in un altro luogo sicuro e nascosto, ad esempio la vostra cassetta di sicurezza in banca.

Chiaramente non complicatevi la vita, ma prendete le dovute precauzioni per proteggere le chiavi. Sappiate però che, se perdete la YubiKey (se la usate per le vostre sottochiavi) e se perdete i vostri backup, non potrete più accedere ai vostri file cifrati.

Trasferire le chiavi OpenPGP su YubiKey

Se avete un token USB come la YubiKey, potete trasferire le sottochiavi in essa. L’operazione è molto semplice.

Prima di andare avanti, quando dico “trasferire” intendo proprio spostare una cosa da un posto a un altro. Nel nostro caso, intendo spostare le sottochiavi dal disco fisso alla YubiKey.

Ricordo che trasferire le sottochiavi nel token USB è una operazione a senso unico e non è possibile tornare indietro, cioè non si possono trasferire le sottochiavi dal token al nostro disco fisso. Solo se abbiamo un backup delle chiavi possiamo ripristinare la situazione allo stato prima del trasferimento. Per cui non procedete se non avete fatto il backup.

Diamo uno sguardo alla situazione attuale:

gpg --list-secret-keys

sec   rsa4096/0x9F676B5A4B6E6777 2018-04-01 [C] [expires: 2021-03-31]
      Key fingerprint = 4915 3275 9708 0147 25CF  E3A7 9F67 6B5A 4B6E 6777
      Keygrip = C6D1CD1D12CBBC8FA14D30004EAF381803A72597
uid                   [ultimate] Mario Rossi <mario.rossi@example.com>
ssb   rsa2048/0xE7E0CAF69114F367 2018-04-01 [S] [expires: 2019-04-01]
      Keygrip = 135159EDEFB9FCB6062F9DE0E21FD90CB07DA041
ssb   rsa2048/0x3C91B3682F3AC08A 2018-04-01 [E] [expires: 2019-04-01]
      Keygrip = C74D47329D5D224B0716879DCF3A4EC2D8951C53
ssb   rsa2048/0x465ED456AFBE0F10 2018-04-01 [A] [expires: 2019-04-01]
      Keygrip = 30DEE8A060F3562CD6F1384E0F883D65477E596A

Inseriamo il token nella porta USB e controlliamo che venga vista da GnuPG:

gpg --card-status

Se restituisce:

gpg: error getting version from 'scdaemon': No SmartCard daemon
gpg: OpenPGP card not available: No SmartCard daemon

installiamo scdaemon:

sudo apt-get install pcscd pcsc-tools scdaemon

e quindi di nuovo:

gpg --card-status

che restituirà qualcosa del tipo:

Reader ...........: Yubico Yubikey 4 OTP U2F CCID 00 00
Application ID ...: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Version ..........: 2.1
Manufacturer .....: Yubico
Serial number ....: XXXXXXXX
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

Notate come ci siano i tre campi dedicati alla conservazione delle tre sottochiavi che abbiamo creato:

Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]

Qui sposteremo le nostre tre sottochiavi. Iniziamo la procedura.

Entriamo in modalità modifica:

gpg --card-edit

Cambiamo anzitutto i PIN. I PIN predefiniti di fabbrica sono:

Admin PIN (8 cifre): 12345678
PIN (6 cifre): 123456

Entriamo in modalità amministratore dando:

admin

e quindi:

passwd

Dal menu scegliere l’opzione da seguire, vale a dire Change PIN e, una volta finito, Change Admin PIN. Quindi alla fine salvare con save e uscire con quit.

Una volta aggiornati i due PIN, passare al trasferimento delle chiavi. Dal prompt del terminale dare:

gpg --edit-key 0x9F676B5A4B6E6777

che restituirà:

gpg (GnuPG) 2.1.11; Copyright (C) 2016 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa4096/0x9F676B5A4B6E6777
     created: 2018-04-01  expires: 2021-03-31  usage: C
     trust: ultimate      validity: ultimate
ssb  rsa2048/0xE7E0CAF69114F367
     created: 2018-04-01  expires: 2019-04-01  usage: S
ssb  rsa2048/0x3C91B3682F3AC08A
     created: 2018-04-01  expires: 2019-04-01  usage: E
ssb  rsa2048/0x465ED456AFBE0F10
     created: 2018-04-01  expires: 2019-04-01  usage: A
[ultimate] (1). Mario Rossi <mario.rossi@example.com>

Selezioniamo la prima sottochiave con:

key 1

che mostrerà la chiave selezionata con un asterisco *:

sec  rsa4096/0x9F676B5A4B6E6777
     created: 2018-04-01  expires: 2021-03-31  usage: C
     trust: ultimate      validity: ultimate
ssb* rsa2048/0xE7E0CAF69114F367
     created: 2018-04-01  expires: 2019-04-01  usage: S
ssb  rsa2048/0x3C91B3682F3AC08A
     created: 2018-04-01  expires: 2019-04-01  usage: E
ssb  rsa2048/0x465ED456AFBE0F10
     created: 2018-04-01  expires: 2019-04-01  usage: A
[ultimate] (1). Mario Rossi <mario.rossi@example.com>

Trasferiamo la chiave con:

keytocard

Deselezioniamo quindi la chiave 1:

key 1

L’asterisco verrà tolto. Quindi procedere con lo stesso metodo per le restanti due chiavi. Qui indico di seguito i comandi in sequenza:

key 2
keytocard
key 2
key 3
keytocard
key 3

Alla fine salviamo e usciamo:

save

Una volta usciti al prompt dei comandi, diamo uno sguardo alla situazione:

gpg --edit-key 0x9F676B5A4B6E6777

che restituirà:

gpg (GnuPG) 2.1.11; Copyright (C) 2016 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa4096/0x9F676B5A4B6E6777
     created: 2018-04-01  expires: 2021-03-31  usage: C
     trust: ultimate      validity: ultimate
ssb> rsa2048/0xE7E0CAF69114F367
     created: 2018-04-01  expires: 2019-04-01  usage: S
ssb> rsa2048/0x3C91B3682F3AC08A
     created: 2018-04-01  expires: 2019-04-01  usage: E
ssb> rsa2048/0x465ED456AFBE0F10
     created: 2018-04-01  expires: 2019-04-01  usage: A
[ultimate] (1). Mario Rossi <mario.rossi@example.com>

Come si vede abbiamo il segno > dopo ogni ssb, segno che le sottochiavi sono nel token. La chiave principale invece è ancora nel nostro disco. Date anche uno sguardo a com’è cambiata la YubiKey dando:

gpg --card-status

Potremmo finire qua se abbiamo scelto di non cancellare la chiave principale dal disco.

Eliminare la chiave principale

Se abbiamo scelto di eliminare la chiave principale dal disco, dobbiamo anzitutto verificare che versione di GnuPG stiamo usando, perché a seconda della versione bisognerà procedere in due modi diversi:

se abbiamo GnuPG versione 2.1 o successiva: è sufficiente cancellare il file corrispondente alla chiave master dalla directory ~/.gnupg/private-keys-v1.d;
se abbiamo GnuPG precedente alla versione 2.1: dopo aver fatto il backup delle sottochiavi, bisogna dapprima cancellare tutta la chiave (master e sottochiavi) e poi reimportare solo le sottochiavi.

Nonostante all’inizio della guida ho specificato di usare solo la versione di GnuPG 2.1 o successiva, vediamo comunque i due procedimenti nel dettaglio.

GnuPG versione 2.1 o successiva

GnuPG, dalla versione 2.1 in su, deposita le chiavi private nella directory ~/.gnupg/private-keys-v1.d/ e non più nel file ~/.gnupg/secring.gpg. Perciò, se avete una chiave master e 3 sottochiavi, dovreste avere 4 file con estensione .key in quella directory:

C6D1CD1D12CBBC8FA14D30004EAF381803A72597.key
135159EDEFB9FCB6062F9DE0E21FD90CB07DA041.key
C74D47329D5D224B0716879DCF3A4EC2D8951C53.key
30DEE8A060F3562CD6F1384E0F883D65477E596A.key

Per identificare quale di questi file è la chiave master, dare nel terminale questo comando:

gpg --with-keygrip --list-key 0x9F676B5A4B6E6777

Siccome è stato fatto il backup della directory di GnuPG, potete eliminare il file .key corrispondente alla chiave master. Per ogni evenienza, prima di cancellare il file, verificate che nel backup ci sia il file che state per cancellare. Il comando per eliminare il file è:

cp rm ~/.gnupg/private-keys-v1.d/C6D1CD1D12CBBC8FA14D30004EAF381803A72597.key

oppure usate un programma come shred per eliminarlo in modo sicuro:

shred -vuzn25 ~/.gnupg/private-keys-v1.d/C6D1CD1D12CBBC8FA14D30004EAF381803A72597.key

Le opzioni -vuzn25 di shred significano:

v = show progress
u = truncate and remove file after overwriting
z = add a final overwrite with zeros to hide shredding
n = overwrite N times instead of the default (3)

Se avete fatto da poco la migrazione a GnuPG versione 2.1 o superiore, il vecchio file secring.gpg che conteneva le chiavi private potrebbe ancora averla al suo interno. Per cui, se la dimensione del file è zero, il file non contiene più nulla; altrimenti, se la dimensione del file è maggiore di zero, cancellatelo del tutto.

Quando in futuro vi servirà usare la chiave master (ad esempio, per firmare una chiave altrui), potrete semplicemente prendere dal backup il file .key della chiave master e copiarlo nella directory private-keys-v1.d di lavoro. Una volta terminata l’esigenza, potrete eliminare nuovamente il file.

GnuPG precedente alla versione 2.1

Se avete questa versione di GnuPG, bisognerà procedere con questi passi:

Essere sicuri di avere il backup funzionante delle chiavi;
Rimuovere la chiave privata completa (cioè master e sottochiavi);
Reimportare dal backup solo le sottochiavi.

La chiave completa si elimina con:

gpg --delete-secret-keys 0x9F676B5A4B6E6777

Le sottochiavi si importano con:

gpg --import 0xE7E0CAF69114F367

gpg --import 0x3C91B3682F3AC08A

gpg --import 0x465ED456AFBE0F10

Vediamo quindi la situazione:

gpg --list-secret-keys

Ora, se avete spostato le sottochiavi nella YubiKey, la risposta sarà:

sec#  rsa4096/0x9F676B5A4B6E6777 2018-04-01 [C] [expires: 2021-03-31]
      Key fingerprint = 4915 3275 9708 0147 25CF  E3A7 9F67 6B5A 4B6E 6777
      Keygrip = C6D1CD1D12CBBC8FA14D30004EAF381803A72597
uid                   [ultimate] Mario Rossi <mario.rossi@example.com>
ssb>  rsa2048/0xE7E0CAF69114F367 2018-04-01 [S] [expires: 2019-04-01]
      Keygrip = 135159EDEFB9FCB6062F9DE0E21FD90CB07DA041
ssb>  rsa2048/0x3C91B3682F3AC08A 2018-04-01 [E] [expires: 2019-04-01]
      Keygrip = C74D47329D5D224B0716879DCF3A4EC2D8951C53
ssb>  rsa2048/0x465ED456AFBE0F10 2018-04-01 [A] [expires: 2019-04-01]
      Keygrip = 30DEE8A060F3562CD6F1384E0F883D65477E596A

mentre, se avete deciso di tenere le sottochiavi nel disco, la risposta sarà:

sec#  rsa4096/0x9F676B5A4B6E6777 2018-04-01 [C] [expires: 2021-03-31]
      Key fingerprint = 4915 3275 9708 0147 25CF  E3A7 9F67 6B5A 4B6E 6777
      Keygrip = C6D1CD1D12CBBC8FA14D30004EAF381803A72597
uid                   [ultimate] Mario Rossi <mario.rossi@example.com>
ssb   rsa2048/0xE7E0CAF69114F367 2018-04-01 [S] [expires: 2019-04-01]
      Keygrip = 135159EDEFB9FCB6062F9DE0E21FD90CB07DA041
ssb   rsa2048/0x3C91B3682F3AC08A 2018-04-01 [E] [expires: 2019-04-01]
      Keygrip = C74D47329D5D224B0716879DCF3A4EC2D8951C53
ssb   rsa2048/0x465ED456AFBE0F10 2018-04-01 [A] [expires: 2019-04-01]
      Keygrip = 30DEE8A060F3562CD6F1384E0F883D65477E596A

Gli agenti

Fermiamo ssh-agent:

killall ssh-agent

Disabilitiamo ssh-agent permanentemente:

sudo nano /etc/X11/Xsession.options

e commentiamo la riga aggiungendo un cancelletto # all’inizio:

# use-ssh-agent

Abilitiamo il supporto SSH in GnuPG aggiungendo la seguente riga in ~/.gnupg/gpg-agent.conf:

enable-ssh-support

Già che ci siamo aggiungiamo pure la scelta di quale pinentry usare:

pinentry-program /usr/bin/pinentry-gtk-2

Alternative sono, ad esempio:

pinentry-program /usr/bin/pinentry-curses
pinentry-program /usr/bin/pinentry-tty
pinentry-program /usr/bin/pinentry-qt
pinentry-program /usr/bin/pinentry-gnome3

Riavviamo l’agente di GnuPG:

gpg-connect-agent killagent /bye

gpg-connect-agent /bye

Inseriamo la riga seguente in ~/.bashrc:

# You should always add the following lines to your .bashrc or whatever initialization file is used for all shell invocations.
# @link https://gnupg.org/documentation/manuals/gnupg/Invoking-GPG_002dAGENT.html#Invoking-GPG_002dAGENT
GPG_TTY=$(tty)
export GPG_TTY

# Launch gpg-agent
gpg-connect-agent /bye

# When using SSH support, use the current TTY for passphrase prompts
gpg-connect-agent updatestartuptty /bye > /dev/null

# Point the SSH_AUTH_SOCK to the one handled by gpg-agent
if [ -S $(gpgconf --list-dirs agent-ssh-socket) ]; then
  export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
else
  echo "$(gpgconf --list-dirs agent-ssh-socket) doesn't exist. Is gpg-agent running ?"
fi

Facciamo rileggere questo file:

source .bashrc

Infine, se non l’abbiamo già fatto, assicuriamoci di usare gpg2 invece della versione 1:

echo "alias gpg=gpg2" >> ~/.bashrc

oppure al file ~/.bash_aliases se usate questo:

echo "alias gpg=gpg2" >> ~/.bash_aliases

Importare la chiave principale per operazioni speciali

Quando periodicamente dovrete fare operazioni occasionali sul vostro portachiavi o se dovete firmare (certificare) una chiave altrui, vi servirà la chiave principale. Per fare queste operazioni dovrete importare la chiave principale nel vostro portachiavi, fare l’operazione e quindi cancellarla nuovamente.

C’è un altro metodo per fare uso della chiave principale, come ad esempio dire momentaneamente a GnuPG che la sua home non è ~/.gnupg ma un’altra directory. Io non ho mai usato questo sistema, per cui scrivo solo quello che uso io.

Accertatevi di avere accesso dal terminale alla directory dove c’è il vostro backup. Lo scopo è quello di copiare il file .key della chiave master dal backup alla directory attuale di lavoro di GnuPG.

cp directory-backup-gnupg/private-keys-v1.d/C6D1CD1D12CBBC8FA14D30004EAF381803A72597.key ~/.gnupg/private-keys-v1.d/C6D1CD1D12CBBC8FA14D30004EAF381803A72597.key

Effettuare quindi le operazioni che dovevamo compiere e, alla fine, eliminarla nuovamente:

rm ~/.gnupg/private-keys-v1.d/C6D1CD1D12CBBC8FA14D30004EAF381803A72597.key

Accertatevi ora che la chiave master non ci sia più con:

gpg --list-secret-keys

che dovrebbe restituire qualcosa di simile a questo:

sec#  rsa4096/0x9F676B5A4B6E6777 2018-04-01 [C] [expires: 2021-03-31]
      Key fingerprint = 4915 3275 9708 0147 25CF  E3A7 9F67 6B5A 4B6E 6777
      Keygrip = C6D1CD1D12CBBC8FA14D30004EAF381803A72597
uid                   [ultimate] Mario Rossi <mario.rossi@example.com>
ssb>  rsa2048/0xE7E0CAF69114F367 2018-04-01 [S] [expires: 2019-04-01]
      Keygrip = 135159EDEFB9FCB6062F9DE0E21FD90CB07DA041
ssb>  rsa2048/0x3C91B3682F3AC08A 2018-04-01 [E] [expires: 2019-04-01]
      Keygrip = C74D47329D5D224B0716879DCF3A4EC2D8951C53
ssb>  rsa2048/0x465ED456AFBE0F10 2018-04-01 [A] [expires: 2019-04-01]
      Keygrip = 30DEE8A060F3562CD6F1384E0F883D65477E596A

o a questo, se avete deciso di tenere le sottochiavi nel disco:

sec#  rsa4096/0x9F676B5A4B6E6777 2018-04-01 [C] [expires: 2021-03-31]
      Key fingerprint = 4915 3275 9708 0147 25CF  E3A7 9F67 6B5A 4B6E 6777
      Keygrip = C6D1CD1D12CBBC8FA14D30004EAF381803A72597
uid                   [ultimate] Mario Rossi <mario.rossi@example.com>
ssb   rsa2048/0xE7E0CAF69114F367 2018-04-01 [S] [expires: 2019-04-01]
      Keygrip = 135159EDEFB9FCB6062F9DE0E21FD90CB07DA041
ssb   rsa2048/0x3C91B3682F3AC08A 2018-04-01 [E] [expires: 2019-04-01]
      Keygrip = C74D47329D5D224B0716879DCF3A4EC2D8951C53
ssb   rsa2048/0x465ED456AFBE0F10 2018-04-01 [A] [expires: 2019-04-01]
      Keygrip = 30DEE8A060F3562CD6F1384E0F883D65477E596A

C’è il simbolo # dopo la parola sec, per cui la chiave master non c’è più.

Estendere la validità delle nostre chiavi

Se abbiamo scelto una validità a tempo per le nostre chiavi, periodicamente potremo estenderne la validità se ancora sono valide per noi. Teniamo presente che possiamo rinnovare la validità di una chiave già scaduta.

Se abbiamo scelto di togliere la chiave principale dal nostro disco, dovremo importarla nuovamente, come descritto al paragrafo “Importare la chiave principale per operazioni speciali”.

Se abbiamo scelto, poi, di tenere le sottochiavi nel token USB, dovremo inserirlo in una porta USB.

Iniziamo quindi la procedura di rinnovo:

gpg --edit-key 0x9F676B5A4B6E6777

sec  rsa4096/0x9F676B5A4B6E6777
     created: 2018-04-01  expires: 2021-03-31  usage: C
     trust: ultimate      validity: ultimate
ssb  rsa2048/0xE7E0CAF69114F367
     created: 2018-04-01  expires: 2019-04-01  usage: S
ssb  rsa2048/0x3C91B3682F3AC08A
     created: 2018-04-01  expires: 2019-04-01  usage: E
ssb  rsa2048/0x465ED456AFBE0F10
     created: 2018-04-01  expires: 2019-04-01  usage: A
[ultimate] (1). Mario Rossi <mario.rossi@example.com>

I passi di rinnovo per ogni chiave sono i seguenti:

selezione della sottochiave da rinnovare;
invio del comando expire;
scelta della durata della validità;
deselezione della sottochiave.

Nel nostro caso, essendo tre le chiavi, questi i passaggi tutti di seguito:

key 1 (per la prima sottochiave; key 2 per seconda; key 3 per terza)
   expire (e seguire le istruzioni)
      1y (per un anno di validità)
key 1 (deseleziona)
key 2 (seleziona la seconda sottochiave)
   expire
      1y
key 2 (deseleziona)
key 3 (seleziona la terza sottochiave)
   expire
      1y
check (verifichiamo che tutto sia stato eseguito)
save

Bibliografia

Debian Wiki, Subkeys.
Riseup, OpenPGP Best Practices.
Tjl73, Creazione di chiavi sicure (ossìa, come generare con GnuPG una coppia di chiavi per poterla conservare in modo “abbastanza” sicuro).
Eric Severance, PGP and SSH keys on a Yubikey NEO.
Alex Cabal, Creating the perfect GPG keypair.
Suva.sh, Using GPG and SSH keys (GnuPG 2.1) with a Smartcard (Yubikey 4).
Drduh, Guide to using YubiKey as a SmartCard for GPG and SSH.

Questa guida, rivista e corretta in piccole parti, è la copia di quanto pubblicato a suo tempo su GitHub. ↩︎

L'articolo Generazione sicura di chiavi OpenPGP è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

La truffa via Google Calendar

aldolat@gmail.com (Aldo Latino) — Sat, 24 Aug 2019 06:12:54 +0000

Questa mattina ho ricevuto un invito tramite Google Calendar a partecipare a un “evento” in cui avrei vinto un iPhone. L’invito era ripetuto per 5 giorni, dal 23 al 27 agosto. Ovviamente l’invito conteneva un link.

Non ero al corrente di questo tipo di attacco o non me ne ricordavo più. Da una rapida ricerca, ho trovato un post di Lily Hay Newman su Wired, Tricky Scam Plants Phishing Links in Your Google Calendar, pubblicato lo scorso 17 giugno:

The idea, of course, is to get victims to click and then enter personal information into the malicious form. “For the calendar attack, the scammers use a prepared email list to send their fraudulent invitations,” says Maria Vergelis, a security researcher at Kaspersky who has been following the method. “They can also set the number of reminders to deliver the same message many times until the desired link is clicked or the invitation is deleted. And such an invitation automatically adds the notifications to one’s calendar. The delivery method is quite new and growing.”

Lily Hay Newman

Che è esattamente quello che è successo a me. Questo è uno screenshot del mio calendario con i 5 eventi aggiunti dall’esterno al mio calendario:

e questo è uno screenshot dell’invito via email:

È possibile evitare del tutto questa truffa, cambiando due impostazioni generali di Google Calendar, che sono attive di default. Basta disattivare in “Impostazioni generali” > “Impostazioni evento” > “Aggiungi automaticamente gli inviti”, mettendolo su “No, mostra solo gli inviti a cui ho risposto”, mentre, poco più sotto, in “Opzioni di visualizzazione” disattivare “Mostra eventi rifiutati”.

Occhi sempre aperti. 😈

L'articolo La truffa via Google Calendar è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Perché le smart card sono smart

aldolat@gmail.com (Aldo Latino) — Sun, 16 Jun 2019 16:57:24 +0000

Qualche giorno fa Linux Journal ha pubblicato un articolo dal titolo Why Smart Cards Are Smart. La brevissima introduzione dice così:

If you use GPG keys, learn about the benefits to storing them on a smart card.¹

Questo articolo può fungere da introduzione alla mia guida Generazione sicura di chiavi OpenPGP, che scrissi più di un anno fa e che pubblicai su GitHub.

Unico appunto al titolo della mia guida: forse oggi la intitolerei Generazione (quasi) sicura di chiavi OpenPGP, per mantenere un po’ di prudenza.

Kyle Rankin, Why Smart Cards Are Smart, «Linux Journal», 12 giugno 2019. ↩︎

L'articolo Perché le smart card sono smart è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Cambiare le password in pass

aldolat@gmail.com (Aldo Latino) — Sat, 19 Jan 2019 15:28:36 +0000

Il programma pass, di cui ho scritto qualche articolo fa, non ha un metodo comodo per aggiornare le password. L’unico modo è:

pass edit directory/account

ma ci troviamo direttamente nell’editor di testo dove possiamo modificare soltanto a mano la password. In questi casi, io ho sempre aperto un altro terminale dove generavo la password con pwgen che poi copiavo e incollavo a mano nell’altro terminale.

Esiste però l’estensione pass-update che dà questa funzionalità in più a pass. Installarla è semplicissimo perché basta scaricare il file, decomprimerlo e, dalla directory, dare:

sudo make install

Una volta installato, avremo il comando aggiuntivo update. L’unica cosa da sapere è che l’estensione cambia solo la prima riga del file perché per pass ogni file di password va organizzato così:

riga 1: password
riga 2 e seguenti: tutto quello che si vuole

Per opzione predefinita, dopo aver dato ad esempio:

pass update Social/twitter.com

l’estensione vi stampa il contenuto attuale del file e attende l’ok dall’utente per il cambio. Se diamo ok, genererà lui una password e cambierà solo la prima riga del file. È ovviamente possibile dirgli la lunghezza della password e la complessità, così come anche dargli noi una password. Davvero comodo!

Un’ultima nota. La versione di pass nei repository è la 1.7.1, la quale non gestisce l’autocompletamento da terminale per le estensioni. La versione corrente 1.7.3, non ancora presente nei repo, lo fa.

L'articolo Cambiare le password in pass è uno scritto di aldolat.it. Rispettane le condizioni di licenza.