Cyberdyne Systems https://noblogo.org/aytin/ "Fare o non fare. Non c'è provare!" Wed, 08 Apr 2026 00:03:13 +0000 Installazione di Cloudflare WARP su OSMC https://noblogo.org/aytin/installazione-di-cloudflare-warp-su-osmc <![CDATA[cloudflare-warp È noto come l'uso dei resolver Cloudflare sia uno dei modi per anonimizzare il proprio IP all'ISP. Cloudflare offre anche altre modalità di risoluzione ancora più efficaci: DNS over HTTPS (DoH) DNS over TCP (DoT) DNS over WARP (DoW) !--more-- I primi due sono relativi a richieste dns crittografate e incapsulate, in una richiesta https (porta 443) la prima, e in una connessione TLS (porta 853) la seconda. La terza modalità è una richiesta dns in chiaro ma all'interno di un tunnel Wireguard o MASQUE (QUIC + HTTP/3 - rif. https://datatracker.ietf.org/meeting/interim-2021-masque-03/materials/slides-interim-2021-masque-03-sessa-masque-interim-2021-04-h3-dgram-00). Molto interessante ed è quella che approfondirò in seguito. Senza entrare nel merito, tutte le soluzioni anonimizzano le query dns. L'ultima, quella che mi ha stutzzicato, è in realtà un tunnel vpn che crittografa TUTTO il traffico, non solo le richieste DNS. DoT è una cifratura TLS che lascia intatto il pacchetto UDP iniziale, è quindi più efficiente di DoH che converte una richieste DNS in una HTTP cifrata dal layer TLS. DoT di solito viene fatta a livello di dispositivo, DoH per singole applicazioni. DoT, basandosi su una porta specifica, 853, è facilmente identificabile (e bloccabile) come traffico DNS (benché cifrato), DoH è una richiesta HTTPS e si mescola col traffico che viaggia sulla porta 443 (difficilmente si invaliderà tutto quel tipo di traffico). DoT, DoH, DoW, mitigano notevolmente il cache poisoning dei resolver perché rendono quasi impossibilie per un attaccante alterare una richiesta che viene protetta per l'intero percorso. Va detto che la soluzione ideale in questo contesto è la combinazione con DNSSEC, che fornisce autenticità e integrità alla riservatezza fornita da DoH/DoT. Anche se l'obiettivo rimane l'approfondimento di CLoudflare WARP, vale la pena di spendere due parole anche sulle altre modalità di risoluzione, DoT/DoH Configurare risoluzioni DNS DoH Configurare DoH è molto semplice perché è qualcosa legato all'applicazione, il browser tipicamente. Se l'applicazione lo supporta, di solito è poco di più di un flag da abilitare. Ad es. Firefox o Chrome permettono di attivare una sorte di "protezione avanzata del DNS" indicando semplicemente un resolver che la supporti (es. Cloudflare, NextDNS o Quad9). Configurare risoluzioni DNS DoT DoT, come detto, è una configurazione che avviene a livello di dispositivo, l'anonimizzazione delle query DNS si ottiene quindi per ogni applicazione. Sul come farlo, dipende dal dispositivo. Ad es. su una linux box basta aggiungere due righe su systemd-resolved e riavviare il relativo servizio. sudo vi /etc/systemd/resolved.conf ... DNS=1.1.1.1 DNSOverTLS=yes dopo aver salvato il file systemctl restart systemd-resolved Un veloce test su https://1.1.1.1/help (da qualunque browser) ci mostrerà qualcosa del tipo: Connected to 1.1.1.1 Yes Using DNS over HTTPS (DoH) No Using DNS over TLS (DoT) Yes Using DNS over WARP No AS Name Cloudflare, Inc. AS Number 13335 Cloudflare Data Center MXP indice che DoT è attivo e funzionante. Lo stesso test poteva essere fatto anche per DoH. Cloudflare WARP E poi c'è DoW, che è qualcosa di ancora più estremo perché, all'occorrenza, anonimizza non solo le richieste DNS ma tutto il nostro traffico (e infatti diversi servizi di streaming non lo consentono). Cloudflare Warp attiva diverse modalità di risoluzione dns fra cui DoH e DoT. Dal momento che Cloudflare Warp agisce su tutta la connessione, è il modo più semplice per avere risoluzione dns di tipo DoH o DoT, su qualunque dispositivo su cui è presente Cloudflare Warp senza gli sbattimenti di systemd o altro. Cloudflare Warp in modalità tunnel è un client che instaura un collegamento cifrato punto-punto (un tunnel) fra il nostro host e un endpoint Cloudflare. In questo modo ogni bit che esce dal nostro dispositivo viene cifrato prima della comunicazione, che diventa così totalmente schermata. La vpn di Coudflare si basa su wireguard o su MASQUE. Nel primo caso è una normale vpn con un setup roadwarrior, il secondo caso offre in più la possibilità di associare al tunnel anche le modalità DoH/DoT per le richieste dns. Anonimato sì/no? Cloudflare WARP è uno strumento incentrato sulla sicurezza, progettato per crittografare il traffico internet e proteggere la privacy dagli ISP, piuttosto che per garantire l'anonimato completo o nascondere la posizione dell'utente. Sostituisce l'IP dell'utente con un IP di Cloudflare che generalmente corrisponde alla sua reale area geografica, rendendolo inadatto a eludere le restrizioni basate sulla posizione. Non è una VPN tradizionale. WARP non maschera la nostra posizione ai siti web, che spesso possono visualizzare la tua posizione approssimativa. Per migliorare la privacy, si dovrebbe utilizzare il protocollo MASQUE, che offre anche una maggiore efficienza. In sintesi, WARP fornisce un "tunnel sicuro" per proteggere la privacy dei dati da amministratori di rete indiscreti, protegge il traffico perché eccelle nella crittografia del traffico su reti non sicure (ad esempio, Wi-Fi pubbliche), ma non offre le funzionalità di anonimato dei tradizionali servizi VPN incentrati sulla privacy. Fatta questa doverosa premessa, vediamo come può essere usato. Configurare Cloudflare WARP L'installazione del client è molto semplice. Per Gnu/Linux c'è la versione cli, per android un app, per altri sistemi, Win /MacOS, un installer. La parte applicativa prima di tutto registra il dispositivo sulla rete Cloudflare generando degli ID e una chiave di licenza. In un secondo momento si generano le chiavi di cifratura. Per fissare le idee, una volta fatte le operazioni di inizializzazione, sulla linux box per tunnellizzare ogni nostra comunicazione con una risoluzione DoT, basta: facoltativo warp-cli mode warp+dot connessione warp-cli connect Per terminare: warp-cli disconnect Questo approccio torna molto comodo quando per es. vogliamo usare wifi pubbliche, in città o in aeroporto. A meno di non avere un'installazione personale di una nostra vpn, questa è una soluzione immediata. Certo, bisogna fidarsi di Clooudflare ma è certamente meglio che fidarsi delle wifi free. E arriviamo al caso d'uso che volevo approfondire riguardante l'"anonimizzazione" di un mediacenter casalingo per il quale non vogliamo rendere noto il suo utilizzo. L'esperienza che ho avuto al proposito è stata interessante, visto che uso da anni OSMC su una RasbPi 3 e ho deciso di metterla dietro Cloudflare. OSMC insieme a LibreELEC sono ottime soluzioni di mediacenter per SBC. La prima più "general", essendo una debian customizzata per ospitare un mediacenter, la seconda invece meno elastica ma più essenziale ed efficiente. Nonostante la Raspberry Pi 3 sia dotata di un processore ARM64, la versione di OSMC che ho installato a suo tempo è a 32 bit e per quella non c'è disponibilità per il client cloudflare (solo ARM64). Ho dovuto ricorrere ad un client "unofficial", wgcf, che permette di registrare il dispositivo e di generare le chiavi ma solo per la modalità Wireguard, non MASQUE, quindi niente Warp+DoT/DoH (per inciso, wgcf rappresenta un'ottima alternativa anche per chi non vuole usare il client Cloudflare su Gnu/Linux). A questo aggiungo che, sebbebe OSMC sia una Debian su cui posso installare e configurare tanta roba, l'installazione di Wireguard, e penso di qualunque cosa che vada a toccare lo stack di rete, diventa qualcosa di estremamente complicato da fare, dal momento che OSMC si rifiuta categoricamente di eseguire operazione che metterebbero a rischio il suo essere un mediacenter, fondamentalmente. Tradotto in soldoni, il client wireguard si installa, sale su correttamente ma non c'è verso di far funzionare la risoluzione. L'unica via d'usicta è stata configurare Wireguard attraverso il gestore di rete di OSMC che è connman. Una volta fatto questo, sono stati necessari solo un paio di piccoli accorgimenti per far si che, in seguito all'avvio del mediacenter, la configurazione vpn venisse caricata automaticamente da connman, contestualmente alla connessione vpn. Configurazione wgcf Account cloudflare curl -L https://github.com/ViRb3/wgcf/releases/latest/download/wgcf2.2.30linuxarmv7 -o /usr/local/bin/wgcf chmod u+x /usr/local/bin/wgcf wgcf register wgcf generate status & trace wgcf status curl https://www.cloudflare.com/cdn-cgi/trace Configurazione connman Su OSMC connman ha i suoi file di configurazione in /var/lib/connman e /var/lib/connman-vpn Nel file di configurazione, l'host va indicato con l'ip non con l'fqdn (engage.cloudflareclients.com) Configurazione wireguard cloudflare La configurazione della vpn deve essere un file .config sotto /var/lib/connman-vpn vi /var/lib/connman-vpn/cloudflarewarp.config [provider*] Type = WireGuard Name = CloudflareWARP Host = 162.159.192.1 AutoConnect = true WireGuard.Address = 172.16.0.2/24 WireGuard.ListenPort = 51280 WireGuard.PrivateKey = myprivatekey WireGuard.PublicKey = cloudlarewgpublickey WireGuard.DNS = 1.1.1.1, 1.0.0.1 WireGuard.AllowedIPs = 0.0.0.0/0 WireGuard.EndpointPort = 2408 WireGuard.PersistentKeepalive = 25 Dopo aver creato il file di configurazione, possiamo vedere il nuovo servizio pronto per essere richiamato da comman-vpnd elenco servizi attivi connmanctl services AO SSID wifiidmanagedpsk R CloudflareWARP vpn1621591921 Affinché la connessione alla vpn parta all'avvio di OSMC, è necessario disporre di un servizio che: esegua common-vpnd per caricare il file di configurazione effettui la connessione vpn Creazione nuovo servizio in /lib/systemd/system/connman-vpn.service [Unit] Description=ConnMan VPN service After=network-online.target Wants=network-online.target [Service] Type=dbus BusName=net.connman.vpn ExecStart=/usr/sbin/connman-vpnd -n ExecStop=/usr/local/bin/vpn-autoconnect.sh StandardOutput=null Restart=on-failure [Install] WantedBy=multi-user.target Script richiamato dal servizio per la connessione alla vpn: connessione vpn vi /usr/local/bin/vpn-autoconnect.sh !/bin/bash Attende che il demone VPN sia pronto sleep 5 Tenta la connessione (usa il nome esatto che vedi in connmanctl services) connmanctl connect vpn1621591921 Inifine si rende il file eseguibile e si avvia il servizio chmod +x /usr/local/bin/vpn-autoconnect.sh avvio servizio systemctl daemon-reload systemctl enable connman-vpn.service systemctl start connman-vpn.service E il gioco è fatto. Da questo momento in poi, OSMC tunnellizza tutto il suo traffico verso Cloudflare. Come detto, in questo modo ho "solo" la configurazione di un tunnel wireguard verso l'endpoint Cloudflare, non dispongo di altre funzionalità che warp-cli offre. Tuttavia è un procedimento abbastanza trasparente che non prevede la convivenza con ulteriori servizi come nel caso di warp-cli e che può essere un'alternativa anonimizzante valida anche su una linux box normale. #dns #doh #dot #warp #vpn #tunnel #cloudflare #wireguard #masque #osmc]]> cloudflare-warp È noto come l'uso dei resolver Cloudflare sia uno dei modi per anonimizzare il proprio IP all'ISP.

Cloudflare offre anche altre modalità di risoluzione ancora più efficaci:

  1. DNS over HTTPS (DoH)
  2. DNS over TCP (DoT)
  3. DNS over WARP (DoW)

I primi due sono relativi a richieste dns crittografate e incapsulate, in una richiesta https (porta 443) la prima, e in una connessione TLS (porta 853) la seconda.

La terza modalità è una richiesta dns in chiaro ma all'interno di un tunnel Wireguard o MASQUE (QUIC + HTTP/3 – rif. https://datatracker.ietf.org/meeting/interim-2021-masque-03/materials/slides-interim-2021-masque-03-sessa-masque-interim-2021-04-h3-dgram-00). Molto interessante ed è quella che approfondirò in seguito.

Senza entrare nel merito, tutte le soluzioni anonimizzano le query dns. L'ultima, quella che mi ha stutzzicato, è in realtà un tunnel vpn che crittografa TUTTO il traffico, non solo le richieste DNS.

DoT è una cifratura TLS che lascia intatto il pacchetto UDP iniziale, è quindi più efficiente di DoH che converte una richieste DNS in una HTTP cifrata dal layer TLS.

DoT di solito viene fatta a livello di dispositivo, DoH per singole applicazioni.

DoT, basandosi su una porta specifica, 853, è facilmente identificabile (e bloccabile) come traffico DNS (benché cifrato), DoH è una richiesta HTTPS e si mescola col traffico che viaggia sulla porta 443 (difficilmente si invaliderà tutto quel tipo di traffico).

DoT, DoH, DoW, mitigano notevolmente il cache poisoning dei resolver perché rendono quasi impossibilie per un attaccante alterare una richiesta che viene protetta per l'intero percorso. Va detto che la soluzione ideale in questo contesto è la combinazione con DNSSEC, che fornisce autenticità e integrità alla riservatezza fornita da DoH/DoT.

Anche se l'obiettivo rimane l'approfondimento di CLoudflare WARP, vale la pena di spendere due parole anche sulle altre modalità di risoluzione, DoT/DoH

Configurare risoluzioni DNS DoH

Configurare DoH è molto semplice perché è qualcosa legato all'applicazione, il browser tipicamente. Se l'applicazione lo supporta, di solito è poco di più di un flag da abilitare.

Ad es. Firefox o Chrome permettono di attivare una sorte di “protezione avanzata del DNS” indicando semplicemente un resolver che la supporti (es. Cloudflare, NextDNS o Quad9).

Configurare risoluzioni DNS DoT

DoT, come detto, è una configurazione che avviene a livello di dispositivo, l'anonimizzazione delle query DNS si ottiene quindi per ogni applicazione. Sul come farlo, dipende dal dispositivo.

Ad es. su una linux box basta aggiungere due righe su systemd-resolved e riavviare il relativo servizio.

sudo vi /etc/systemd/resolved.conf
...
DNS=1.1.1.1
DNSOverTLS=yes

# dopo aver salvato il file
systemctl restart systemd-resolved

Un veloce test su https://1.1.1.1/help (da qualunque browser) ci mostrerà qualcosa del tipo:

Connected to 1.1.1.1        Yes
Using DNS over HTTPS (DoH)  No
Using DNS over TLS (DoT)    Yes
Using DNS over WARP         No
AS Name                     Cloudflare, Inc.
AS Number                   13335
Cloudflare Data Center      MXP

indice che DoT è attivo e funzionante. Lo stesso test poteva essere fatto anche per DoH.

Cloudflare WARP

E poi c'è DoW, che è qualcosa di ancora più estremo perché, all'occorrenza, anonimizza non solo le richieste DNS ma tutto il nostro traffico (e infatti diversi servizi di streaming non lo consentono).

Cloudflare Warp attiva diverse modalità di risoluzione dns fra cui DoH e DoT.

Dal momento che Cloudflare Warp agisce su tutta la connessione, è il modo più semplice per avere risoluzione dns di tipo DoH o DoT, su qualunque dispositivo su cui è presente Cloudflare Warp senza gli sbattimenti di systemd o altro.

Cloudflare Warp in modalità tunnel è un client che instaura un collegamento cifrato punto-punto (un tunnel) fra il nostro host e un endpoint Cloudflare. In questo modo ogni bit che esce dal nostro dispositivo viene cifrato prima della comunicazione, che diventa così totalmente schermata.

La vpn di Coudflare si basa su wireguard o su MASQUE. Nel primo caso è una normale vpn con un setup roadwarrior, il secondo caso offre in più la possibilità di associare al tunnel anche le modalità DoH/DoT per le richieste dns.

Anonimato sì/no?

Cloudflare WARP è uno strumento incentrato sulla sicurezza, progettato per crittografare il traffico internet e proteggere la privacy dagli ISP, piuttosto che per garantire l'anonimato completo o nascondere la posizione dell'utente.

Sostituisce l'IP dell'utente con un IP di Cloudflare che generalmente corrisponde alla sua reale area geografica, rendendolo inadatto a eludere le restrizioni basate sulla posizione.

Non è una VPN tradizionale. WARP non maschera la nostra posizione ai siti web, che spesso possono visualizzare la tua posizione approssimativa.

Per migliorare la privacy, si dovrebbe utilizzare il protocollo MASQUE, che offre anche una maggiore efficienza.

In sintesi, WARP fornisce un “tunnel sicuro” per proteggere la privacy dei dati da amministratori di rete indiscreti, protegge il traffico perché eccelle nella crittografia del traffico su reti non sicure (ad esempio, Wi-Fi pubbliche), ma non offre le funzionalità di anonimato dei tradizionali servizi VPN incentrati sulla privacy.

Fatta questa doverosa premessa, vediamo come può essere usato.

Configurare Cloudflare WARP

L'installazione del client è molto semplice. Per Gnu/Linux c'è la versione cli, per android un app, per altri sistemi, Win /MacOS, un installer. La parte applicativa prima di tutto registra il dispositivo sulla rete Cloudflare generando degli ID e una chiave di licenza. In un secondo momento si generano le chiavi di cifratura.

Per fissare le idee, una volta fatte le operazioni di inizializzazione, sulla linux box per tunnellizzare ogni nostra comunicazione con una risoluzione DoT, basta:

# facoltativo
warp-cli mode warp+dot

#connessione
warp-cli connect

Per terminare:

warp-cli disconnect

Questo approccio torna molto comodo quando per es. vogliamo usare wifi pubbliche, in città o in aeroporto. A meno di non avere un'installazione personale di una nostra vpn, questa è una soluzione immediata. Certo, bisogna fidarsi di Clooudflare ma è certamente meglio che fidarsi delle wifi free.

E arriviamo al caso d'uso che volevo approfondire riguardante l'“anonimizzazione” di un mediacenter casalingo per il quale non vogliamo rendere noto il suo utilizzo.

L'esperienza che ho avuto al proposito è stata interessante, visto che uso da anni OSMC su una RasbPi 3 e ho deciso di metterla dietro Cloudflare.

OSMC insieme a LibreELEC sono ottime soluzioni di mediacenter per SBC. La prima più “general”, essendo una debian customizzata per ospitare un mediacenter, la seconda invece meno elastica ma più essenziale ed efficiente.

Nonostante la Raspberry Pi 3 sia dotata di un processore ARM64, la versione di OSMC che ho installato a suo tempo è a 32 bit e per quella non c'è disponibilità per il client cloudflare (solo ARM64).

Ho dovuto ricorrere ad un client “unofficial”, wgcf, che permette di registrare il dispositivo e di generare le chiavi ma solo per la modalità Wireguard, non MASQUE, quindi niente Warp+DoT/DoH (per inciso, wgcf rappresenta un'ottima alternativa anche per chi non vuole usare il client Cloudflare su Gnu/Linux).

A questo aggiungo che, sebbebe OSMC sia una Debian su cui posso installare e configurare tanta roba, l'installazione di Wireguard, e penso di qualunque cosa che vada a toccare lo stack di rete, diventa qualcosa di estremamente complicato da fare, dal momento che OSMC si rifiuta categoricamente di eseguire operazione che metterebbero a rischio il suo essere un mediacenter, fondamentalmente.

Tradotto in soldoni, il client wireguard si installa, sale su correttamente ma non c'è verso di far funzionare la risoluzione. L'unica via d'usicta è stata configurare Wireguard attraverso il gestore di rete di OSMC che è connman.

Una volta fatto questo, sono stati necessari solo un paio di piccoli accorgimenti per far si che, in seguito all'avvio del mediacenter, la configurazione vpn venisse caricata automaticamente da connman, contestualmente alla connessione vpn.

Configurazione wgcf

# Account cloudflare
curl -L https://github.com/ViRb3/wgcf/releases/latest/download/wgcf_2.2.30_linux_armv7 -o /usr/local/bin/wgcf
chmod u+x /usr/local/bin/wgcf
wgcf register
wgcf generate

# status & trace
wgcf status
curl https://www.cloudflare.com/cdn-cgi/trace

Configurazione connman

Su OSMC connman ha i suoi file di configurazione in /var/lib/connman e /var/lib/connman-vpn

Nel file di configurazione, l'host va indicato con l'ip non con l'fqdn (engage.cloudflareclients.com)

# Configurazione wireguard cloudflare
# La configurazione della vpn deve essere un file .config sotto /var/lib/connman-vpn

vi /var/lib/connman-vpn/cloudflare_warp.config
[provider_*]
Type = WireGuard
Name = Cloudflare_WARP
Host = 162.159.192.1
AutoConnect = true
WireGuard.Address = 172.16.0.2/24
WireGuard.ListenPort = 51280
WireGuard.PrivateKey = <my_private_key>
WireGuard.PublicKey = <cloudlare_wg_public_key>
WireGuard.DNS = 1.1.1.1, 1.0.0.1
WireGuard.AllowedIPs = 0.0.0.0/0
WireGuard.EndpointPort = 2408
WireGuard.PersistentKeepalive = 25

Dopo aver creato il file di configurazione, possiamo vedere il nuovo servizio pronto per essere richiamato da comman-vpnd

# elenco servizi attivi
connmanctl services
* AO <SSID>           wifi_<id>_managed_psk
* R Cloudflare_WARP      vpn_162_159_192_1

Affinché la connessione alla vpn parta all'avvio di OSMC, è necessario disporre di un servizio che:

  1. esegua common-vpnd per caricare il file di configurazione
  2. effettui la connessione vpn
# Creazione nuovo servizio in /lib/systemd/system/connman-vpn.service
[Unit]
Description=ConnMan VPN service
After=network-online.target
Wants=network-online.target

[Service]
Type=dbus
BusName=net.connman.vpn
ExecStart=/usr/sbin/connman-vpnd -n
ExecStop=/usr/local/bin/vpn-autoconnect.sh
StandardOutput=null
Restart=on-failure

[Install]
WantedBy=multi-user.target

Script richiamato dal servizio per la connessione alla vpn:

# connessione vpn
vi /usr/local/bin/vpn-autoconnect.sh
#!/bin/bash
# Attende che il demone VPN sia pronto
sleep 5
# Tenta la connessione (usa il nome esatto che vedi in connmanctl services)
connmanctl connect vpn_162_159_192_1

Inifine si rende il file eseguibile e si avvia il servizio

chmod +x /usr/local/bin/vpn-autoconnect.sh

# avvio servizio
systemctl daemon-reload
systemctl enable connman-vpn.service
systemctl start connman-vpn.service

E il gioco è fatto.

Da questo momento in poi, OSMC tunnellizza tutto il suo traffico verso Cloudflare.

Come detto, in questo modo ho “solo” la configurazione di un tunnel wireguard verso l'endpoint Cloudflare, non dispongo di altre funzionalità che warp-cli offre.

Tuttavia è un procedimento abbastanza trasparente che non prevede la convivenza con ulteriori servizi come nel caso di warp-cli e che può essere un'alternativa anonimizzante valida anche su una linux box normale.

#dns #doh #dot #warp #vpn #tunnel #cloudflare #wireguard #masque #osmc

]]> https://noblogo.org/aytin/installazione-di-cloudflare-warp-su-osmc Fri, 03 Apr 2026 22:33:32 +0000 Device Mapper: LUKS + LVM https://noblogo.org/aytin/device-mapper-luks-lvm <![CDATA[luks-lvm (segue da "Cenni sulla creazione di pool di storage con LVM") ...anche se è la base per una serie di sviluppi interessanti. Come ormai sappiamo, device mapper è il framework del kernel Linux col quale mappare dispositivi a blocchi fisici su dispositivi a blocchi logici, che costituisce la base per fornire funzionalità ulteriori quali: !--more-- volumi logici raid cifratura (Full Disk Encryption) snapshot di volumi Scenario 1 È molto comune per es. cifrare l'intero disco e "affettarlo" con volumi logici in base alle proprie esigenze di partizionamento . Il doppio vantaggio è dato da: offuscamento totale dello schema di partizionamento estrema versatilità / flessibilità del partizionamento grazie ai volumi logici Come si agisce? si cifra il dispositivo fisico si crea un gruppo di volumi avente come volume fisico il volume cifrato si creano i volumi logici in base allo schema di partizionamento desiderato. luks-lvm Passo 1 - Inizializzazione Simulo il mio dispositivo fisico ricorrendo ai loop device. Il "disco" avrà una grandezza simbolica di 2 GiB, non avrà header detachable. L'algoritmo di hash sarà sha512 e la chiave sarà da 512 bit. Il resto è il default di luks2 (argon2id come pbkdf, per maggiori dettagli vedi cryptsetup --help) 1. Preparazione disco "fisico" fallocate -l 2g cipherdisk.img 2. loop device che simula l'attach del dispositivo DEV=$(losetup -Pf --show cipherdisk.img) 3. Inizializzazione cifratura cryptsetup luksFormat \ --type luks2 \ --hash sha512 \ --key-size 512 \ $DEV Passo 2 Il passo successivo consiste nell'apertura del dispositivo cifrato e nella definizione dello schema di partizionamento in volumi logici 1. apertura del disco cifrato cryptsetup open \ --type luks2 \ $DEV cipherdisk Nell'apertura, device mapper fa la sua prima magia. Infatti, se osserviamo lo stato dei dispositivi, vedremo una situazione simile: lsblk ... loop9 7:9 Kib0 2G 0 loop └─cipherdisk 252:3 0 2G 0 crypt ... Cio vuol dire che sopra il dispositivo fisico, /dev/loop9 in questo caso, device mapper ha "poggiato" cipherdisk (/dev/mapper/cipherdisk). Questo sarà il nostro volume fisico per definire gruppi di volume e, conseguentemente, i volumi logici. 2. creazione gruppo di volumi vgcreate vglab /dev/mapper/cipherdisk 3. creazione volumi logici lvcreate -n lvlab1 vglab -L 700M lvcreate -n lvlab2 vglab -L 600M lvcreate -n lvlab3 vglab -l 100%FREE La situazione dei dispositivi è ora questa: lsblk ... loop9 7:9 0 2G 0 loop └─cipherdisk 252:3 0 2G 0 crypt ├─vglab-lvlab1 252:4 0 700M 0 lvm ├─vglab-lvlab2 252:5 0 600M 0 lvm └─vglab-lvlab3 252:6 0 728M 0 lvm ... Sopra /dev/loop9 c'è cipherdisk (/dev/mapper/cipherdisk) e sopra di esso, i 3 volumi logici lvlab1 (/dev/mapper/vglab-lvlab1) lvlab2 (/dev/mapper/vglab-lvlab2) lvlab3 (/dev/mapper/vglab-lvlab3) Formatto e monto i volumi logici 4. formattazione dei 3 volumi logici mkfs.ext4 /dev/mapper/vglab-lvlab1 mkfs.ext4 /dev/mapper/vglab-lvlab2 mkfs.ext4 /dev/mapper/vglab-lvlab3 5. creo e preparo i punti di mmontaggio mkdir disk1 disk2 disk3 mount -t ext4 -o user,noauto,rw /dev/mapper/vglab-lvlab1 disk1 mount -t ext4 -o user,noauto,rw /dev/mapper/vglab-lvlab2 disk2 mount -t ext4 -o user,noauto,rw /dev/mapper/vglab-lvlab3 disk3 chown $USER disk1 disk2 disk3 6. unmount di tutti i dispositivi umount disk1 disk2 disk3 vgchange -an vglab cryptsetup close cipherdisk losetup -d $DEV Passo 3 Infine, per completezza, gli script di mount e unmount del dispositivo. mount 1. attach del dispositivo DEV=$(losetup -Pf --show cipherdisk.img) 2. Apre il disco cifrato cryptsetup open \ --type luks2 \ $DEV cipherdisk 3. monta il gruppo di volume (opzionale. L'apertura del disco cifrato dovrebbe montare automaticamente il gruppo di volumi) vgchange -ay vglab 4. monta i volumi logici mount -t ext4 -o user,noauto,rw /dev/mapper/vglab-lvlab1 disk1 mount -t ext4 -o user,noauto,rw /dev/mapper/vglab-lvlab2 disk2 mount -t ext4 -o user,noauto,rw /dev/mapper/vglab-lvlab3 disk3 unmount 1. smonta i 3 dischi umount disk1 disk2 disk3 2. smonta il gruppo di volumi vgchange -an vglab 3. chiude il disco cifrato cryptsetup close cipherdisk 4. "stacca" il dispositivo fisico losetup -d $DEV Questo è ciò che si farebbe normalmente quando si vuole il full disk encryption sul proprio pc. Ma con una piccola eccezione. In realtà ciò che viene cifrata è una partizione quasi completa del disco, perché almeno una piccola partizione, quella contenente il boot, /BOOT, deve essere in chiaro per consentire: a UEFI di avviare GRUB che conosce le partizioni, GRUB provvederà all'avvio del kernel, l'avvio del kernel con initramfs chiederà la password per sbloccare la partizione cifrata. La cifratura totale (che proprio totale non sarà perché /boot/efi deve rimanere in chiaro) eleva di molto la complessità del setup iniziale. Affidare a GRUB la gestione della cifratura potrebbe voler dire, oltre alla complessità della configurazione iniziale che dovrà far ricorso a moduli come cryptodisk, che bisognerà rinunciare ad Argon2 perché GRUB ancora non lo supporta pienamente e, a differenza del kernel, non ha sufficiente potenza per farlo lavorare come si deve. Un buon compromesso potrebbe essere il ricorso ad un dispositivo esterno, es. una pendrive, che contenga tutta la partizione /boot in chiaro, anche l'header del disco cifrato. GRUB dovrà solo sapere dove si trovi il boot, il resto dell'avvio viene affidato come di consueto al kernel. Scenario 2 Rimanendo nell'ambito dell'esplorazione di device mapper e della cifratura di dispositivi esterni non avviabili, immaginiamo qualcosa di più estremo. Supponiamo di dover custodire un segreto in qualcosa che non sia un semplice vault cifrato. Per diminuire il rischio di compromettere un unico vault, decido di dividerlo in varie parti, come gli horcrux ma con 0 malignità. Ogni parte sarà cifrata con una sua chiave che affiderò ad una persona diversa, di mia fiducia. Solo io, titolare ultimo del segreto, avrò accesso ai dati e solo la mia chiave (come l'Anello che li domina tutti) aprirà il vault. Supponiamo di avere 3 dispositivi fisici (che nel laboratoro saranno simulati da loop device come al solito) per altrettanti "custodi", ognuno dei quali verrà cifrato con la chiave e con dei parametri da consegnare al "custode" specifico. I 3 dispositivi cifrati costituiranno un gruppo di volumi con un volume logico (dai requisiti posti non c'è necessità di sfruttare la flessibilità di partizionamento dei volumi logici) che verrà cifrato con la mia chiave master. luks-lvm-luks Ogni dispositivo, volume logico finale compreso, prima della cifratura, verrà inizializzato con del rumore casuale. Questo per impedire ad un'analisi forense di risalire ad un qualunque pattern sul dispositivo raw. Caratteristiche di ogni cifratura: dispositivi inizializzati con rumore casuale header detachable offset custom key-file default di argon2id (controlla il tuo default con cryptsetup benchmark) Quando vorrò aprire il vault, sarà necessario che i 3 "custodi" aprano il loro "pezzo" e solo io potrò ricostruire e decifrare il volume con la mia chiave. L'inzializzazione con rumore casuale dei dispositivo, tralasciando l'uso di dd su /dev/urandom che sappiamo essere CPU-intensive, può essere fatta ricorrendo: ad openssl rand, come sappiamo da "Come generare una password o un keyfile sicuri (Trilogia Della Password – 1 di 3" oppure usando furbescamente cryptsetup, con cui apriamo il dispositivo in modalità plain, senza header, e riempiendolo di zeri (da /dev/zero con dd) che, attraversando il motore di cifratura, verranno scritti sul dispositivo come dati casuali ad alta velocità. ################################ Emulazione dei device fisici ################################ fallocate -l 512M cipherdisk1.img fallocate -l 512M cipherdisk2.img fallocate -l 512M cipherdisk3.img ########################### creazione dei 3 keyfile ########################### keyfile del custode n° 1 dd if=/dev/urandom bs=1024 count=4 | \ gpg --yes -o cipherdisk1.key.gpg -c \ --s2k-mode 3 \ --s2k-count 32505856 \ --s2k-cipher-algo aes256 \ --s2k-digest-algo sha512 \ --force-mdc - keyfile del custode n° 2 dd if=/dev/urandom bs=1024 count=4 | \ gpg --yes -o cipherdisk2.key.gpg -c \ --s2k-mode 3 \ --s2k-count 32505856 \ --s2k-cipher-algo aes256 \ --s2k-digest-algo sha512 \ --force-mdc - keyfile del custode n° 3 dd if=/dev/urandom bs=1024 count=4 | \ gpg --yes -o cipherdisk3.key.gpg -c \ --s2k-mode 3 \ --s2k-count 32505856 \ --s2k-cipher-algo aes256 \ --s2k-digest-algo sha512 \ --force-mdc - keyfile master dd if=/dev/urandom bs=1024 count=4 | \ gpg --yes -o master.key.gpg -c \ --s2k-mode 3 \ --s2k-count 32505856 \ --s2k-cipher-algo aes256 \ --s2k-digest-algo sha512 \ --force-mdc - ########################## cifratura dei 3 device ########################## attach dispositivo DEV1=$(losetup -Pf --show cipherdisk1.img) inizializzazione dev1 con rumore casuale cryptsetup open --type plain ${DEV1} container --key-file /dev/urandom dd if=/dev/zero of=/dev/mapper/container status=progress cryptsetup close container cifratura dispositivo n° 1 gpg -d cipherdisk1.key.gpg | \ cryptsetup luksFormat \ --type luks2 \ --key-file - \ --header header1.img \ --offset 32768 \ --hash sha512 \ --key-size 512 \ --cipher aes-xts-plain64 \ ${DEV1} attach dispositivo DEV2=$(losetup -Pf --show cipherdisk2.img) inizializzazione dev2 con rumore casuale cryptsetup open --type plain ${DEV2} container --key-file /dev/urandom dd if=/dev/zero of=/dev/mapper/container status=progress cryptsetup close container cifratura dispositivo n° 2 gpg -d cipherdisk2.key.gpg | \ cryptsetup luksFormat \ --type luks2 \ --key-file - \ --header header2.img \ --offset 36864 \ --hash sha512 \ --key-size 512 \ --cipher aes-xts-plain64 \ ${DEV2} attach dispositivo DEV3=$(losetup -Pf --show cipherdisk3.img) inizializzazione dev3 con rumore casuale cryptsetup open --type plain ${DEV3} container --key-file /dev/urandom dd if=/dev/zero of=/dev/mapper/container status=progress cryptsetup close container cifratura dispositivo n° 3 gpg -d cipherdisk3.key.gpg | \ cryptsetup luksFormat \ --type luks2 \ --key-file - \ --header header3.img \ --offset 40960 \ --hash sha512 \ --key-size 512 \ --cipher aes-xts-plain64 \ ${DEV3} ############################## Creazione gruppo di volumi ############################## "apro" il volume 1 gpg -d cipherdisk1.key.gpg | \ cryptsetup open \ --type luks2 \ --header header1.img \ --key-file - \ ${DEV1} cipherdisk1 "apro" il volume 2 gpg -d cipherdisk2.key.gpg | \ cryptsetup open \ --type luks2 \ --header header2.img \ --key-file - \ ${DEV2} cipherdisk2 "apro" il volume 3 gpg -d cipherdisk3.key.gpg | \ cryptsetup open \ --type luks2 \ --header header3.img \ --key-file - \ ${DEV3} cipherdisk3 Creo il mio gruppo di volumi con i 3 volumi "fisici": 1. /dev/mapper/cipherdisk1 2. /dev/mapper/cipherdisk2 3. /dev/mapper/cipherdisk3 vgcreate vgmaster /dev/mapper/cipherdisk1 /dev/mapper/cipherdisk2 /dev/mapper/cipherdisk3 creazione dell'unico volume logico lvcreate -n lvmaster vgmaster -l 100%FREE ################################ cifratura e mount del master ################################ cifratura dispositivo master dd if=/dev/urandom of=/dev/mapper/vgmaster-lvmaster bs=1M count=32 status=progress gpg -d master.key.gpg | \ cryptsetup luksFormat \ --type luks2 \ --key-file - \ --header headermaster.img \ --offset 65536 \ --hash sha512 \ --key-size 512 \ --cipher aes-xts-plain64 \ /dev/mapper/vgmaster-lvmaster apriamo il dispositivo master gpg -d master.key.gpg | \ cryptsetup open \ --type luks2 \ --header headermaster.img \ --key-file - \ /dev/mapper/vgmaster-lvmaster cipherdiskmaster e finalmente lo formattiamo mkfs.ext4 /dev/mapper/cipherdiskmaster Test: montiamo il disco mkdir -p /run/media/master/diskmaster chown -R ${USER}:${USER} /run/media/master/diskmaster mount -t auto /dev/mapper/cipherdiskmaster /run/media/master/diskmaster Infine chiudiamo tutto umount /run/media/master/diskmaster cryptsetup close cipherdiskmaster vgchange -an vgmaster cryptsetup close cipherdisk1 cryptsetup close cipherdisk2 cryptsetup close cipherdisk3 losetup -d ${DEV1} ${DEV2} ${DEV3} Dopo aver appurato che tutto funzioni, consegno ad ogni "custode" dispositivo, keyfile e header. Se un attaccante dovesse entrare in possesso di uno o più dispositivi, troverebbe solo un mucchio di dati incomprensibili. Posto che riuscisse a decifrare il dispositivo, troverebbe un pezzo di un gruppo di volumi, cifrato e inutilizzabile. Il master a questo punto non dovrà fare altro che aprire e chiudere il vault, dopo aver riunito tutti i pezzi, come segue: Apertura del vault Attach dei dispositivi DEV1=$(losetup -Pf --show cipherdisk1.img) DEV2=$(losetup -Pf --show cipherdisk2.img) DEV3=$(losetup -Pf --show cipherdisk3.img) "apro" il volume 1 gpg -d cipherdisk1.key.gpg | \ cryptsetup open \ --type luks2 \ --header header1.img \ --key-file - \ ${DEV1} cipherdisk1 "apro" il volume 2 gpg -d cipherdisk2.key.gpg | \ cryptsetup open \ --type luks2 \ --header header2.img \ --key-file - \ ${DEV2} cipherdisk2 "apro" il volume 3 gpg -d cipherdisk3.key.gpg | \ cryptsetup open \ --type luks2 \ --header header3.img \ --key-file - \ ${DEV3} cipherdisk3 (facoltativo) apre il gruppo di volumi vgchange -ay vgmaster "apre" il master volume gpg -d master.key.gpg | \ cryptsetup open \ --type luks2 \ --header headermaster.img \ --key-file - \ /dev/mapper/vgmaster-lvmaster cipherdiskmaster Monta il volume mount -t auto /dev/mapper/cipherdiskmaster /run/media/master/diskmaster Chiusura del vault smonta il volume cifrato umount /run/media/master/diskmaster chiusura del vault master cryptsetup close cipherdiskmaster chiusura del gruppo di volumi vgchange -an vgmaster chiusura dei singoli vault cifrati cryptsetup close cipherdisk1 cryptsetup close cipherdisk2 cryptsetup close cipherdisk3 deattach dei dispositivi losetup -d ${DEV1} ${DEV2} ${DEV3} #cryptsetup #devicemapper #dmcrypt #gpg #loseup #luks #lvm #loopdevice #storage]]> luks-lvm (segue da “Cenni sulla creazione di pool di storage con LVM“) ...anche se è la base per una serie di sviluppi interessanti.

Come ormai sappiamo, device mapper è il framework del kernel Linux col quale mappare dispositivi a blocchi fisici su dispositivi a blocchi logici, che costituisce la base per fornire funzionalità ulteriori quali:

  • volumi logici
  • raid
  • cifratura (Full Disk Encryption)
  • snapshot di volumi

Scenario 1

È molto comune per es. cifrare l'intero disco e “affettarlo” con volumi logici in base alle proprie esigenze di partizionamento .

Il doppio vantaggio è dato da:

  1. offuscamento totale dello schema di partizionamento
  2. estrema versatilità / flessibilità del partizionamento grazie ai volumi logici

Come si agisce?

  1. si cifra il dispositivo fisico
  2. si crea un gruppo di volumi avente come volume fisico il volume cifrato
  3. si creano i volumi logici in base allo schema di partizionamento desiderato.

luks-lvm

Passo 1 – Inizializzazione

Simulo il mio dispositivo fisico ricorrendo ai loop device.

Il “disco” avrà una grandezza simbolica di 2 GiB, non avrà header detachable. L'algoritmo di hash sarà sha512 e la chiave sarà da 512 bit. Il resto è il default di luks2 (argon2id come pbkdf, per maggiori dettagli vedi cryptsetup --help)

# 1. Preparazione disco "fisico"
fallocate -l 2g cipher_disk.img

# 2. loop device che simula l'attach del dispositivo
DEV=$(losetup -Pf --show cipher_disk.img)

# 3. Inizializzazione cifratura
cryptsetup luksFormat  \
    --type luks2 \
    --hash sha512 \
    --key-size 512 \
    $DEV

Passo 2

Il passo successivo consiste nell'apertura del dispositivo cifrato e nella definizione dello schema di partizionamento in volumi logici

# 1. apertura del disco cifrato
cryptsetup open \
    --type luks2 \
    $DEV cipher_disk

Nell'apertura, device mapper fa la sua prima magia.

Infatti, se osserviamo lo stato dei dispositivi, vedremo una situazione simile:

lsblk
...
loop9                7:9    Kib0     2G  0 loop  
└─cipher_disk      252:3    0     2G  0 crypt 
...

Cio vuol dire che sopra il dispositivo fisico, /dev/loop9in questo caso, device mapper ha “poggiato” cipher_disk (/dev/mapper/cipher_disk).

Questo sarà il nostro volume fisico per definire gruppi di volume e, conseguentemente, i volumi logici.

# 2. creazione gruppo di volumi
vgcreate vg_lab /dev/mapper/cipher_disk

# 3. creazione volumi logici
lvcreate -n lv_lab_1 vg_lab -L 700M
lvcreate -n lv_lab_2 vg_lab -L 600M
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

La situazione dei dispositivi è ora questa:

lsblk
...
loop9                7:9    0     2G  0 loop  
└─cipher_disk      252:3    0     2G  0 crypt
  ├─vg_lab-lv_lab_1 252:4    0   700M  0 lvm
  ├─vg_lab-lv_lab_2 252:5    0   600M  0 lvm
  └─vg_lab-lv_lab_3 252:6    0   728M  0 lvm
...

Sopra /dev/loop9 c'è cipher_disk (/dev/mapper/cipher_disk) e sopra di esso, i 3 volumi logici

  • lv_lab_1 (/dev/mapper/vg_lab-lv_lab_1)
  • lv_lab_2 (/dev/mapper/vg_lab-lv_lab_2)
  • lv_lab_3 (/dev/mapper/vg_lab-lv_lab_3)

Formatto e monto i volumi logici

# 4. formattazione dei 3 volumi logici
mkfs.ext4 /dev/mapper/vg_lab-lv_lab_1
mkfs.ext4 /dev/mapper/vg_lab-lv_lab_2
mkfs.ext4 /dev/mapper/vg_lab-lv_lab_3

# 5. creo e preparo i punti di mmontaggio
mkdir disk_1 disk_2 disk_3
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_1 disk_1
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_2 disk_2
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_3 disk_3
chown $USER disk_1 disk_2 disk_3

# 6. unmount di tutti i dispositivi
umount disk_1 disk_2 disk_3
vgchange -an vg_lab
cryptsetup close cipher_disk
losetup -d $DEV

Passo 3

Infine, per completezza, gli script di mount e unmount del dispositivo. mount

# 1. attach del dispositivo
DEV=$(losetup -Pf --show cipher_disk.img)

# 2. Apre il disco cifrato 
cryptsetup open \
    --type luks2 \
    $DEV cipher_disk

# 3. monta il gruppo di volume
# (opzionale. L'apertura del disco cifrato dovrebbe montare 
# automaticamente il gruppo di volumi)
vgchange -ay vg_lab

# 4. monta i volumi logici
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_1 disk_1
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_2 disk_2
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_3 disk_3

unmount

# 1. smonta i 3 dischi
umount disk_1 disk_2 disk_3

# 2. smonta il gruppo di volumi
vgchange -an vg_lab

# 3. chiude il disco cifrato
cryptsetup close cipher_disk

# 4. "stacca" il dispositivo fisico
losetup -d $DEV

Questo è ciò che si farebbe normalmente quando si vuole il full disk encryption sul proprio pc. Ma con una piccola eccezione.

In realtà ciò che viene cifrata è una partizione quasi completa del disco, perché almeno una piccola partizione, quella contenente il boot, /BOOT, deve essere in chiaro per consentire:

  • a UEFI di avviare GRUB che conosce le partizioni,
  • GRUB provvederà all'avvio del kernel,
  • l'avvio del kernel con initramfs chiederà la password per sbloccare la partizione cifrata.

La cifratura totale (che proprio totale non sarà perché /boot/efi deve rimanere in chiaro) eleva di molto la complessità del setup iniziale.

Affidare a GRUB la gestione della cifratura potrebbe voler dire, oltre alla complessità della configurazione iniziale che dovrà far ricorso a moduli come cryptodisk, che bisognerà rinunciare ad Argon2 perché GRUB ancora non lo supporta pienamente e, a differenza del kernel, non ha sufficiente potenza per farlo lavorare come si deve.

Un buon compromesso potrebbe essere il ricorso ad un dispositivo esterno, es. una pendrive, che contenga tutta la partizione /boot in chiaro, anche l'header del disco cifrato. GRUB dovrà solo sapere dove si trovi il boot, il resto dell'avvio viene affidato come di consueto al kernel.

Scenario 2

Rimanendo nell'ambito dell'esplorazione di device mapper e della cifratura di dispositivi esterni non avviabili, immaginiamo qualcosa di più estremo.

Supponiamo di dover custodire un segreto in qualcosa che non sia un semplice vault cifrato.

Per diminuire il rischio di compromettere un unico vault, decido di dividerlo in varie parti, come gli horcrux ma con 0 malignità. Ogni parte sarà cifrata con una sua chiave che affiderò ad una persona diversa, di mia fiducia. Solo io, titolare ultimo del segreto, avrò accesso ai dati e solo la mia chiave (come l'Anello che li domina tutti) aprirà il vault.

Supponiamo di avere 3 dispositivi fisici (che nel laboratoro saranno simulati da loop device come al solito) per altrettanti “custodi”, ognuno dei quali verrà cifrato con la chiave e con dei parametri da consegnare al “custode” specifico.

I 3 dispositivi cifrati costituiranno un gruppo di volumi con un volume logico (dai requisiti posti non c'è necessità di sfruttare la flessibilità di partizionamento dei volumi logici) che verrà cifrato con la mia chiave master.

luks-lvm-luks

Ogni dispositivo, volume logico finale compreso, prima della cifratura, verrà inizializzato con del rumore casuale. Questo per impedire ad un'analisi forense di risalire ad un qualunque pattern sul dispositivo raw.

Caratteristiche di ogni cifratura:

  • dispositivi inizializzati con rumore casuale
  • header detachable
  • offset custom
  • key-file
  • default di argon2id (controlla il tuo default con cryptsetup benchmark)

Quando vorrò aprire il vault, sarà necessario che i 3 “custodi” aprano il loro “pezzo” e solo io potrò ricostruire e decifrare il volume con la mia chiave.

L'inzializzazione con rumore casuale dei dispositivo, tralasciando l'uso di dd su /dev/urandom che sappiamo essere CPU-intensive, può essere fatta ricorrendo:

################################
# Emulazione dei device fisici #
################################
fallocate -l 512M cipher_disk_1.img
fallocate -l 512M cipher_disk_2.img
fallocate -l 512M cipher_disk_3.img



###########################
# creazione dei 3 keyfile #
###########################
# keyfile del custode n° 1
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o cipher_disk_1.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -

# keyfile del custode n° 2
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o cipher_disk_2.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -

# keyfile del custode n° 3
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o cipher_disk_3.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -

# keyfile master
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o master.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -



##########################
# cifratura dei 3 device #
##########################
# attach dispositivo
DEV_1=$(losetup -Pf --show cipher_disk_1.img)

# inizializzazione dev_1 con rumore casuale
cryptsetup open --type plain ${DEV_1} container --key-file /dev/urandom
dd if=/dev/zero of=/dev/mapper/container status=progress
cryptsetup close container

# cifratura dispositivo n° 1
gpg -d cipher_disk_1.key.gpg | \
    cryptsetup luksFormat  \
        --type luks2 \
        --key-file - \
        --header header_1.img \
        --offset 32768 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        ${DEV_1}

# attach dispositivo
DEV_2=$(losetup -Pf --show cipher_disk_2.img)

# inizializzazione dev_2 con rumore casuale
cryptsetup open --type plain ${DEV_2} container --key-file /dev/urandom
dd if=/dev/zero of=/dev/mapper/container status=progress
cryptsetup close container

# cifratura dispositivo n° 2
gpg -d cipher_disk_2.key.gpg | \
    cryptsetup luksFormat  \
        --type luks2 \
        --key-file - \
        --header header_2.img \
        --offset 36864 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        ${DEV_2}

# attach dispositivo
DEV_3=$(losetup -Pf --show cipher_disk_3.img)

# inizializzazione dev_3 con rumore casuale
cryptsetup open --type plain ${DEV_3} container --key-file /dev/urandom
dd if=/dev/zero of=/dev/mapper/container status=progress
cryptsetup close container

# cifratura dispositivo n° 3
gpg -d cipher_disk_3.key.gpg | \
    cryptsetup luksFormat  \
        --type luks2 \
        --key-file - \
        --header header_3.img \
        --offset 40960 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        ${DEV_3}



##############################
# Creazione gruppo di volumi #
##############################
# "apro" il volume 1
gpg -d cipher_disk_1.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_1.img \
         --key-file - \
         ${DEV_1} cipher_disk_1

# "apro" il volume 2
gpg -d cipher_disk_2.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_2.img \
         --key-file - \
         ${DEV_2} cipher_disk_2

# "apro" il volume 3
gpg -d cipher_disk_3.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_3.img \
         --key-file - \
         ${DEV_3} cipher_disk_3

# Creo il mio gruppo di volumi con i 3 volumi "fisici":
# 1. /dev/mapper/cipher_disk_1
# 2. /dev/mapper/cipher_disk_2
# 3. /dev/mapper/cipher_disk_3
vgcreate vg_master /dev/mapper/cipher_disk_1  /dev/mapper/cipher_disk_2  /dev/mapper/cipher_disk_3

# creazione dell'unico volume logico
lvcreate -n lv_master vg_master -l 100%FREE



################################
# cifratura e mount del master #
################################
# cifratura dispositivo master
dd if=/dev/urandom of=/dev/mapper/vg_master-lv_master bs=1M count=32 status=progress
gpg -d master.key.gpg | \
    cryptsetup luksFormat  \
        --type luks2 \
        --key-file - \
        --header header_master.img \
		--offset 65536 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        /dev/mapper/vg_master-lv_master

# apriamo il dispositivo master
gpg -d master.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_master.img \
         --key-file - \
         /dev/mapper/vg_master-lv_master cipher_disk_master

# e finalmente lo formattiamo
mkfs.ext4 /dev/mapper/cipher_disk_master

# Test: montiamo il disco
mkdir -p /run/media/master/disk_master
chown -R ${USER}:${USER} /run/media/master/disk_master
mount -t auto /dev/mapper/cipher_disk_master /run/media/master/disk_master

# Infine chiudiamo tutto
umount /run/media/master/disk_master
cryptsetup close cipher_disk_master
vgchange -an vg_master
cryptsetup close cipher_disk_1
cryptsetup close cipher_disk_2
cryptsetup close cipher_disk_3
losetup -d ${DEV_1} ${DEV_2} ${DEV_3}

Dopo aver appurato che tutto funzioni, consegno ad ogni “custode” dispositivo, keyfile e header.

Se un attaccante dovesse entrare in possesso di uno o più dispositivi, troverebbe solo un mucchio di dati incomprensibili.

Posto che riuscisse a decifrare il dispositivo, troverebbe un pezzo di un gruppo di volumi, cifrato e inutilizzabile.

Il master a questo punto non dovrà fare altro che aprire e chiudere il vault, dopo aver riunito tutti i pezzi, come segue:

Apertura del vault

# Attach dei dispositivi
DEV_1=$(losetup -Pf --show cipher_disk_1.img)
DEV_2=$(losetup -Pf --show cipher_disk_2.img)
DEV_3=$(losetup -Pf --show cipher_disk_3.img)

# "apro" il volume 1
gpg -d cipher_disk_1.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_1.img \
         --key-file - \
         ${DEV_1} cipher_disk_1

# "apro" il volume 2
gpg -d cipher_disk_2.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_2.img \
         --key-file - \
         ${DEV_2} cipher_disk_2

# "apro" il volume 3
gpg -d cipher_disk_3.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_3.img \
         --key-file - \
         ${DEV_3} cipher_disk_3

# (facoltativo) apre il gruppo di volumi
vgchange -ay vg_master

# "apre" il master volume
gpg -d master.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_master.img \
         --key-file - \
         /dev/mapper/vg_master-lv_master cipher_disk_master

# Monta il volume
mount -t auto /dev/mapper/cipher_disk_master /run/media/master/disk_master

Chiusura del vault

# smonta il volume cifrato
umount /run/media/master/disk_master

# chiusura del vault master
cryptsetup close cipher_disk_master

# chiusura del gruppo di volumi
vgchange -an vg_master

# chiusura dei singoli vault cifrati
cryptsetup close cipher_disk_1
cryptsetup close cipher_disk_2
cryptsetup close cipher_disk_3

# deattach dei dispositivi
losetup -d ${DEV_1} ${DEV_2} ${DEV_3}

#cryptsetup #devicemapper #dmcrypt #gpg #loseup #luks #lvm #loopdevice #storage

]]> https://noblogo.org/aytin/device-mapper-luks-lvm Mon, 23 Feb 2026 10:58:17 +0000 Archiviare le password in sicurezza con KDF/password-hashing (Trilogia Della Password - 3 di 3) https://noblogo.org/aytin/archiviare-le-password-in-sicurezza-con-kdf-password-hashing-trilogia-della <![CDATA[password hashing Dopo aver capito come creare password inviolabili anche avendo a disposizione tutta l'energia termica dell'universo, pensiamo al modo migliore per archiviarle. Pensare di lasciare la password raw in un database, rappresenta un grosso rischio in virtù di un possibile attacco offline. !--more-- Rainbow Table Come ti blocco la Rainbow Table: Il “Salt” (sale) Il livello successivo: Il Pepper Final step: L’hashing PBKDF2 Bcrypt Scrypt yescrypt Argon2 Un piccolo esempio: hashing di una password con Argon2 Gestione del pepper HSM Key / Algo Rotation Caso A: Algo rotation Caso B: Pepper rotation Una prima linea di difesa consiste nel memorizzare il digest della password, una stringa alfanumerica univoca generata da un apposito algoritmo, così da lasciare nelle mani dell'attaccante degli oggetti che, per la loro non invertibilità, non permettono di risalire alle password. La scelta dell'algoritmo di hashing diventa critica al fine di scongiurare altri tipi di attacchi. Ad es. SHA-256, pur essendo ottimo e molto efficiente per il digest e la firma anche di file di grandi dimensioni, mostra il fianco, proprio in virtù della sua velocità, nel caso di attacchi con: brute-force: si calcola l’hash di password casuali fino a trovare una corrispondenza, dizionario: un'alternativa intelligente alla forza bruta. Si punta alle password più comuni, si calcola l'hash e si controlla se c'è corrispondenza. Rainbow Table: l'attacco al dizionario più insidioso di tutti Oltre al fatto che, la funzione di hashing , essendo deterministica, permette di capire chi sono gli utenti che hanno la stessa password, dal momento che avranno lo stesso digest. Rainbow Table Una Rainbow Table è un enorme dizionario pre-calcolato che contiene: Milioni di password comuni. Il relativo hash corrispondente. Invece di calcolare l’entropia di ogni tentativo, l’attaccante ruba il database degli hash e fa un semplice “Cerca e Trova”. Se l’hash della tua password è nella tabella, la tua password è violata in millisecondi, indipendentemente da quanto fosse alta la sua entropia teorica. smallOss.: Una password totalmente casuale, generata da un CSPRNG affidabile, con un'alta entropia ( 120), rimarrebbe comunque inviolabile anche dalla rainbow table perché la probabilità che quella password si trovi nel dizionario, sarebbe equivalente ad indovinarla./small Come ti blocco la Rainbow Table: Il “Salt” (sale) Per rendere inutili le Rainbow Table, i sistemi sicuri utilizzano il Salt. Il salt è una stringa di dati casuali (generati da una sorgente d’entropia affidabile ovviamente) che viene aggiunta alla password prima di calcolarne il digest. In questo modo le rainbow table vengono vanificate perché gli hash precalcolati sulle password raccolte, mancando il salt, non valgono più. Anche se due utenti avessero la stessa password, avrebbero degli hash completamente diversi. Anche per questo motivo non è un problema che il salt sia pubblico, perché il suo obiettivo non è nascondere quello che è un pezzetto di password a tutti gli effetti, ma di impedire economie di scala degli attacchi perché, pur potendo disporre offline di un database di decine di milioni di utenti, gli hash della mia Rainbow Table (che può arrivare a pesare anche decine di GB) andrebbero tutti ricalcolati per ogni utente, con un costo computazionale e di archiviazione inimmaginabile. Per riassumere, gli ingredienti di base sono: una buona sorgente d’entropia: una fonte di casualità certificata per generare un salt unico; entropia della password: sempre buona norma, ove possibile, come sappiamo ormai fare (https://noblogo.org/aytin/come-generare-una-password-o-un-keyfile-sicuri-trilogia-della-password-1-di). Evita attacchi brute-force o al dizionario in cui l’attaccante prova a indovinare; salt: protegge la password dagli attacchi basati su database pre-calcolati (Rainbow Table). Il livello successivo: Il Pepper È vero che col salt andiamo a complicare lo sfruttamento di un attacco offline ma possiamo fare di meglio. Il punto d'attenzione è che il salt protegge le password di tutti gli utenti. Ma un attaccante potrebbe non essere affatto interessato a violare ogni singolo utente (niente economia di scala) ma solo alcuni. E allora l'attacco attraverso Ranbow Table potrebbe essere di nuovo praticabile. Ma gli informatici sono dei gran giocherelloni, si sa. Visto che abbiamo già il "sale", perché non finire aggiustando con un po’ di “pepe”? Detto, fatto! Il pepper, come il salt, è un'altra password generata con gli stessi criteri del salt ma le analogie finiscono qua perché: a differenza del salt che si trova nel database, il pepper è separato da ques'ultimo. L'ideale sarebbe un HSM; Il salt è visibile a tutti, attaccante compreso. Il pepper è segreto. Un eventuale data breach che permette all'attaccante di disporre offline di tutto il database degli utenti, "vedrà" certamente gli eventuali salt ma sarà ignaro del fatto che gli mancherà sempre un pezzo di chiave; il salt è diverso per ogni utente, il pepper, di solito, è unico; il salt serve a rendere uniche la password degli utenti, il pepper protegge l'intero database da attacchi offline. Il pepper è la chiave di un HMAC, o di un meccanismo di cifratura simmetrica, applicato al digest della password (che ricordo essere salt+password in realtà), che sarà ciò che verrà archiviato. Va detto che l'uso del "pepper" complica ulteriormente lo scenario di archiviazione. Nella stragrande maggioranza dei casi è sufficiente scegliere un buon algoritmo di password hashing (vedi paragrafo successivo) per scoraggiare gli attaccanti. "Pepare" le password prevederebbe, come detto sopra, l'uso di un HSM per es, e tutta una serie di riflessioni di contorno che evidenzierò più avanti. Final step: L'hashing L'ultimo punto da dettagliare è l'hash della password. L'hash crittografico, in uso in questi casi, deve soddisfare le seguenti proprietà: resistenza alla pre-immagine: dato un hash h, deve essere impossibile trovare una password p t.c. H(p) = h (non invertibilità della funzione hash) resistenza alla pre-immagine secondaria: dato una password psub1/sub, deve essere impossibile trovare un'altra password psub2/sub t.c. H(psub1/sub) = H(psub2/sub) (resistenza debole alle collisioni) resistenza alle collisioni: è impossibile trovare due password diverse, psub1/sub e psub2/sub, t.c. H(psub1/sub) = H(psub2/sub) (resistenza forte alle collisioni) effetto valanga: il cambio di un solo bit della password deve cambiare radicalmente l'intero hash In un sistema moderno, l'hash non può essere delegato a funzioni di tipo SHA perché nascono per altri compiti, SHA-2 e SHA-3 nascono per il digest veloce, per verificare l'integrità di file anche molto grossi o firmare documenti. La loro eccellente velocità diventa il loro più grosso difetto quando si parla di password. Negli scenari precedenti di attachi offline, l'hacker che dispone di una grossa potenza di calcolo, può ricostituire velocemente le rainbow table per n utenti. Magari non di tutti ma di quelli attenzionati. Le funzioni di derivazione della chiave (KDF) come pbkdf2 e quelle ancora più estreme come B/Scrypt, Argon2, oltre che soddisfare tutti i punti precedentemente elencati tipici di funzioni di password hashing, sono progettate per essere computazionalmente pesantissime da calcolare perché il loro scopo non è il digest ma la protezione di un segreto contro il brute-force. E mentre le vecchie KDF come pbdfk2 sono CPU bound, ma non GPU bound, le KDF più moderne come Bcrypt, Scrypt ma soprattutto Argon2, agiscono pesantemente su tempo, memoria e parallelismo e l'attacco offline di cui sopra diventa impraticabile. PBKDF2 È il decano delle KDF. Applica iterativamente una funzione pseudorandomica, come HMAC con uno SHA, con salt alla password. Il conteggio delle iterazioni è un parametro configurabile. PBDKF2 è uno standard di lunga data ampiamente adottato. Se non ci sono necessità stringenti di sicurezza o requisiti legacy, è una buona scelta. Il fatto di essere solo CPU bound però non la rende la scelta ideale in scenari dove gli attaccanti possono attingere a risorse di calcolo considerevoli Bcrypt Basato su Blowfish, anche Bcrypt usa un hash crittografico sulla password con parametri il salt e un fattore di costo. Il fattore di costo aumenta esponenzialmente il numero di iterazioni per adattarsi all'aumento di potenza di calcolo dell'hardware. Bcrypt è stato progetto per essere lento e resistente a semplici attacchi di forzat bruta. Tuttavia, il basso utilizzo di ram richiesto dal calcolo lo rendono poco resistente ad attacchi sferrati usando hardware specializzato. Bcrypt ha dalla sua una storia solidissima in ragione della quale da 20 anni a questa parte non sono state trovate vulnerabilità critiche nel suo design. Per questo motivo Bcrypt cifra le password di sistema di OpenBSD dal 1999, come pure ha cifrato quelle di tante distro Linux per anni, prima che passassero ad Argon2 o yescrypt (default di Fedora). Domina nei framework web (\[Python\] Django, \[Ruby\] Ruby on Rails, \[PHP\] Laravel), \[Java\] Spring, Node.js), nelle applicazioni (Ansible / Terraform, Docker), nel web (la cifratura in .htpasswd di Apache e Nginx) visto che la sua semplcitià di implementazione gli ha permesso di trovarsi praticamente in ogni linguaggio. È presente come alternativa anche nei password manager benché molti di essi abbiano spostato il default verso Argon2 o PBKDF2 per conformità agli standard FIPS. È molto semplice implementare e anche da usare perché bisogna agire solo sul fattore di costo (consigliato almeno 10-12, altrimenti diventa troppo vulnerabile ad attacchi sferrati attraverso la GPU) Scrypt Rilasciato nel 2009, Scrypt è stato il primo algoritmo a introdurre il concetto di Memory Hardness ed è stato progettato per rendere economicamente poco conveniente il ricorso ad hardware specializzato come gli ASIC o i FPGA e incidere pesantemente su CPU, ram e parallelismo. Il suo alveo principale sono state le cripto-valute, molte monete lo usano per il mining. Scrypt lo troviamo in quasi tutti i linguaggi di programmazione, in Tarsnap, servizio di baclup online creato dallo stesso autore di Scrypt, è stato usato da LastPass ed è presente come opzione in VeraCrypt per derivare la chiave dalla password. Fino ad Android 9 era l'algoritmo usato per la FDE del dispositvio (passato poi al FBE) . Presente anche su FreeBSD come opzione per la cifratura delle password di sistema e come opzione su LUKS per la cifratura degli slot delle chiavi. Su Scrypt i parametri da configurare sono: Costro CPU/Memoria (N): un parametro che aumenta i costi computazionali di cpu e memoria DImensione del blocco (R): influenza la larghezza di banda della memoria Parallelizzazione (p): indica quanto deve incidere sul calcolo parallelo In questo modo riesce ad essere sia CPU bound che GPU bound che, a differenza di Bcrypt, lo rende resistente anche ad attacchi facenti uso di hardware specializzato.. Di contro, in ambiente in cui siamo vincolati dalle risorse disponibili, la sua potenza diventa un fattore limitante. Quasi paragonabile ad Argon2 in quanto a robustezza, il suo unico tallone d'Achille è la permeabilità ad attacchi di tipo side-channel. yescrypt Piccola menzione per yescrypt, appartenente alla famiglia "Scrypt", pensato per essere ancora più resistente di Scrypt agli attacchi GPU e FPGA ma con una gestione più intelligente delle risorse. Grazie alle sue peculiarità, di fatto, è diventato il successore spirituale di Bcrypt nei sistemi operativi gnu/linux dove, a cominciare da Fedora, passando per Debian, Ubuntu, Arch, Kali, è il default per la cifratura delle password di sistema in /etc/shadow. È talmente incardinato ormai nei sistemi operativi, che è la libreria libxcrypt di yescrypt a gestire la tipica funzione crypt() di C che è la base della crittografia su tutti i sistemi gnu/linux moderni. La sua robustezza unita alla gestione intelligente delle risorse lo rende un coltellino svizzero di riferimento utile per es. per versione custom di LUKS su sistemi embedded, che magari fanno uso di cpu meno recenti, oppure come opzione per strumenti di backup specialistici Di fatto, sui sistemi operativi, yescrypt s'è guadagnato un consenso amplissimo dovuto alla sua scalabilità, alla sua capacità di usare anche la ROM per rendere il cracking ancora più difficile e senza pesare sulla RAM e alla sua compatibilità potendosi inserire perfettamente nella storica funzione crypt() di C come detto prima. Se Argon2 è il vincitore accademico avendo vinto il Password Hashing Competition del 2015, yescrypt per la sua robustezza, efficienza e flessibilità si ritaglia un profilo di indispensabilità nei sistemi operativi, Argon2 E veniamo al dominatore indiscusso di questa che non è una llista esaustiva di KDF. Argon2 è LO standard moderno per il password hashing raccomandato da OWASP e IETF. È il riferimento per praticamente ogni password manager: Bitwarden, KeppasXC, 1Password, a cui assegnanp la protezione della Master Password È la scelta principale per la cifratura degli hard disk anche con impostazioni molto aggressive, in ragione delle quali un ritardo di mezzo secondo (un tempo enorme se venisse scalato esponenzialmente) nell'apertura di un HD è assolutamente accettabile. È il default di LUKS2 (LUKS1 usava PBKDF2) e di VeraCrypt, con cui ha sostituito SHA-512. Come Bcrypt, è implementato estensivamente su praticamente ogni frameword web e backend, da PHP, Django (Python), Laravel fino a Node.js. Nei sistemi operativi, laddove yescrytpt domina nella gestione delle password utente, Argon2 è usato per compiti più critici. Dal kernel Linux per gestire internamente le chiavi crittografiche o da macOS / iOS, dove algoritmi proprietari ispirati fortemente ad Argon2, proteggono i dati nel Secure Enclave. Argon2 setta 3 parametri principali per regolare la sua forza: t: iterazioni, quante volte vengono rimescolati i dati (default Bitwarden = 3) m: memoria, quanta ram deve occupare il calcolo. Questa è la misura anti-GPU (default Bitwarden = 16 (64MB)) p: parallelismo, quanti core della cpu usare. Questa è la misura anti-CPU (default Bitwarden = 4) La variante id è anche resistente agli attacchi side-channel perché impediscono a un attaccante di capire la password osservando i tempi di accesso alla memoria. Un piccolo esempio: hashing di una password con Argon2 Il grosso vantaggio degli algoritmi di kdf è che sono naturalmente resilienti rispetto all'evoluzione tecnologica che produce macchine con sempre maggiore potenza di calcolo. Da pbkdf2 in poi, il salt implicito che invalida le rainbow table precalcolate e la possibilità di calibrare il key stretching in moda da agire intensivamente su ram e cpu, permettono all'algoritmo di adeguarsi per conservare la sua robustezza. Mini-script per l'hashing di una password fornita dall'utente con argon2 settato al default di Bitwarden: echo -n "Password: "; read -s PASSWORD Genero un Salt casuale di 128 bit SALT=$(openssl rand -base64 128) PASSWORDHASH=$(echo "${PASSWORD}" | argon2 "${SALT}" -m 16 -t 3 -p 4 -id -e) PASSWORDHASH e SALT sono i dati che verranno archiviati e, poiché argon2 "frulla" la password con un salt, è praticamente impossibile risalire alla password originale. La verifica è tuttavia banale perché, avendo il salt e la password da verificare, si ricrea l'hash con argon2 e si confronta con l'hash memorizzato. Per maggior sicurezza salt e digest possono essere memorizzati in punti differenti. L'importante è che possano essere recuperate a partire dall'utente. Gestione del pepper Col pepper le cose cambiano un pochino perché: deve essere archiviato con tutte le paranoie possibili in un punto diverso dal database degli utenti il key rotation del pepper non è banale Mini-script che mostra come applicare salt e pepper all'hashing di una password: L'utente inserisce la password echo -n "Password: "; read -s PASSWORD Genero un Salt casuale di 128 bit unico per ogni utente SALT=$(openssl rand -base64 128) Anche PEPPER sarà qualcosa del tipo "openssl rand -base64 128" e si troverà in un punto esterno al database degli utenti. PEPPER=$(getpepperfromext) Digest della password+salt PASSWORDHASH=$(echo "${PASSWORD}" | argon2 "${SALT}" -m 16 -t 3 -p 4 -id -e) HMAC del digest con PEPPER come chiave PASSWORDPEPPER=$(echo "${PASSWORDHASH}" | openssl dgst -sha256 -hmac "${PEPPER}" -binary | base64) HSM Quella vista prima è una versione molto edulcorata di ciò che avviene nella realtà. Il pepper, non può essere gestito con leggerezza visto che è un segreto che protegge non un singolo oggetto ma intere classi, come db di utenti. L'apparato che gestisce chiavi di questo tipo e di questa importanza, deve essere robusto, praticamente inattaccabile, quasi completamente isolato dal resto dei sistemi a meno delle applicazioni, e solo di quelle, che hanno il permesso di richiedere una chiave, Apparati hardware specializzati che assolvono a tutte queste funzioni e anche di più, sono gli HSM (Hardware Security Module) che garantiscono il ciclo di vita delle chiavi, dalla generazione alla distruzione, includendo versionamento, rotazione e backup. Sono concepiti per resistere anche a manipolazioni forzate che possono innescare un meccanismo di autodistruzione e, particolare rilevante, le operazioni crittografiche basate sulle chiavi protette vengono svolte dall'hsm che consegna al client il risultato delle operazioni, non le chiavi. Nel nostro caso, l'HSM dovrebbe restituirci l'hmac del digest della password che gli inviamo. Key / Algo Rotation Cosa succede se cambio pepper o algoritmo (anche la sua configurazione)? Non avendo disponibilità in alcun modo della password dovrò adottare una strategia ad-hoc. Fra tutti gli scenari possibili, il miglior compromesso fra sicurezza e comodità secondo me, è quello basato sul wrapping. È necessario innanzitutto che vengano conservate le versioni delle chiavi per i servizi che le richiedono. E a questo dovrebbe pensarci l'HSM, se ce n'è uno o qualcosa di custom che abbia funzionalità analoghe. Inoltre dovrebbero esserci dei flag che indichino quali sono gli utenti a cui sono state applicate le nuove configurazioni. Caso A: Algo rotation Supponiamo che l'algoritmo di hashing venga cambiato o vengano cambiate le sue configurazioni. Premessa: Nel mio DB degli utenti, in corrispondenza di ogni utente, avrò: il digest della password "pepato": HMAC ( pepper, HASH ( salt, password ) ) il salt Il wrapping: La strategia sarà quello di "avvolgere" la password di ogni utente col nuovo algoritmo, settare un qualche flag che mi indichi l'operazione compiuta e archiviare il tutto. Imponiamo il nuovo algoritmo a tutti gli utenti "imbustando" il digest attuale (in questo caso 'HMAC in realtà, visto che abbiamo a che fare anche col pepper) con il nuovo digest HASH\NEW: HASH\NEW ( salt\new, HMAC ( pepper, HASH ( salt, password ) ) ). Per ogni utente averemo dunque: il nuovo digest al posto di quello vecchio, il nuovo salt il vecchio salt Settiamo il flag del cambio algoritmo a true (o quello che è) Quando l'utente effettuerà il login con successo e il flag sarà a "true", abbiamo la password che ci permetterà di eliminare il vecchio "involucro" e ripristinare l'HMAC del nuovo digest: HMAC ( pepper, HASH\NEW ( salt\new, password ) ) e il flag ritornerà a "false" Considerazioni: La sicurezza non viene compromessa perché il digest di un digest, con KDF configurate a dovere, non comporta alcun rischio. La fase di verifica è quella che si complica di più perché in base al valore del flag, dovrà essere effettuata in maniera differente. Se il flag è "true" (nella nostra convenzione), dopo il login devo avere gli elementi per calcolare il digest in questo modo: HASH\NEW ( salt\new, HMAC ( pepper, HASH ( salt, password ) ) ). Se il flag è a false, calcolerò al solito: HMAC ( pepper, HASH\NEW ( salt\new, password ) ) Caso B: Pepper rotation Supponiamo che a ruotare sia il pepper. Procediamo sempre con il wrapping massivo su tutti gli utenti incapsulando il digest : HMAC ( pepper, HASH ( salt, password ) ) con quello nuovo: HMAC ( pepper\new, HMAC ( pepper, HASH ( salt, password ) ) ) mettendo il flag a "true". Come prima, una volta che gli utenti cominceranno a fare il login, se il flag è "true" innanzitutto verificherò che: HMAC ( pepper\new, HMAC ( pepper, HASH ( salt, password ) ) ) sia uguale a ciò che è stato archiviato. Se così fosse, ora che sono di nuovo in possesso della password, ripristinerò l'HMAC con: HMAC ( pepper\new, HASH ( salt, password ) )_ memorizzandolo al posto di quello vecchio e rimettendo il flag a false. Considerazioni: La modifica massiva delle password degli utenti, stavolta passa dall'HSM e potrebbe essere un problema perché un HSM è progettato per scoraggiare flooding di richieste. È vero che il pepper è sempre lo stesso per tutti gli utenti ma, come ricordavo prima, di solito un HSM non fornisce i suoi segreti ma solo i risultati crittografici delle loro applicazioni. #kdf #pbkdf2 #bcrypt #scrypt #yescrypt #argon2 #luks #cryptography #aes #sha #digest #RainbowTable #BruteForce #salt #pepper #entropy #hsm #hmac #hash]]> password hashing

Dopo aver capito come creare password inviolabili anche avendo a disposizione tutta l'energia termica dell'universo, pensiamo al modo migliore per archiviarle.

Pensare di lasciare la password raw in un database, rappresenta un grosso rischio in virtù di un possibile attacco offline.

Una prima linea di difesa consiste nel memorizzare il digest della password, una stringa alfanumerica univoca generata da un apposito algoritmo, così da lasciare nelle mani dell'attaccante degli oggetti che, per la loro non invertibilità, non permettono di risalire alle password.

La scelta dell'algoritmo di hashing diventa critica al fine di scongiurare altri tipi di attacchi. Ad es. SHA-256, pur essendo ottimo e molto efficiente per il digest e la firma anche di file di grandi dimensioni, mostra il fianco, proprio in virtù della sua velocità, nel caso di attacchi con:

  • brute-force: si calcola l’hash di password casuali fino a trovare una corrispondenza,
  • dizionario: un'alternativa intelligente alla forza bruta. Si punta alle password più comuni, si calcola l'hash e si controlla se c'è corrispondenza.
  • Rainbow Table: l'attacco al dizionario più insidioso di tutti

Oltre al fatto che, la funzione di hashing , essendo deterministica, permette di capire chi sono gli utenti che hanno la stessa password, dal momento che avranno lo stesso digest.

Rainbow Table

Una Rainbow Table è un enorme dizionario pre-calcolato che contiene:

  • Milioni di password comuni.
  • Il relativo hash corrispondente.

Invece di calcolare l’entropia di ogni tentativo, l’attaccante ruba il database degli hash e fa un semplice “Cerca e Trova”. Se l’hash della tua password è nella tabella, la tua password è violata in millisecondi, indipendentemente da quanto fosse alta la sua entropia teorica.

Oss.: Una password totalmente casuale, generata da un CSPRNG affidabile, con un'alta entropia (>120), rimarrebbe comunque inviolabile anche dalla rainbow table perché la probabilità che quella password si trovi nel dizionario, sarebbe equivalente ad indovinarla.

Come ti blocco la Rainbow Table: Il “Salt” (sale)

Per rendere inutili le Rainbow Table, i sistemi sicuri utilizzano il Salt. Il salt è una stringa di dati casuali (generati da una sorgente d’entropia affidabile ovviamente) che viene aggiunta alla password prima di calcolarne il digest.

In questo modo le rainbow table vengono vanificate perché gli hash precalcolati sulle password raccolte, mancando il salt, non valgono più. Anche se due utenti avessero la stessa password, avrebbero degli hash completamente diversi.

Anche per questo motivo non è un problema che il salt sia pubblico, perché il suo obiettivo non è nascondere quello che è un pezzetto di password a tutti gli effetti, ma di impedire economie di scala degli attacchi perché, pur potendo disporre offline di un database di decine di milioni di utenti, gli hash della mia Rainbow Table (che può arrivare a pesare anche decine di GB) andrebbero tutti ricalcolati per ogni utente, con un costo computazionale e di archiviazione inimmaginabile.

Per riassumere, gli ingredienti di base sono:

  1. una buona sorgente d’entropia: una fonte di casualità certificata per generare un salt unico;
  2. entropia della password: sempre buona norma, ove possibile, come sappiamo ormai fare (https://noblogo.org/aytin/come-generare-una-password-o-un-keyfile-sicuri-trilogia-della-password-1-di). Evita attacchi brute-force o al dizionario in cui l’attaccante prova a indovinare;
  3. salt: protegge la password dagli attacchi basati su database pre-calcolati (Rainbow Table).

Il livello successivo: Il Pepper

È vero che col salt andiamo a complicare lo sfruttamento di un attacco offline ma possiamo fare di meglio.

Il punto d'attenzione è che il salt protegge le password di tutti gli utenti. Ma un attaccante potrebbe non essere affatto interessato a violare ogni singolo utente (niente economia di scala) ma solo alcuni. E allora l'attacco attraverso Ranbow Table potrebbe essere di nuovo praticabile.

Ma gli informatici sono dei gran giocherelloni, si sa. Visto che abbiamo già il “sale”, perché non finire aggiustando con un po’ di “pepe”? Detto, fatto!

Il pepper, come il salt, è un'altra password generata con gli stessi criteri del salt ma le analogie finiscono qua perché:

  • a differenza del salt che si trova nel database, il pepper è separato da ques'ultimo. L'ideale sarebbe un HSM;
  • Il salt è visibile a tutti, attaccante compreso. Il pepper è segreto. Un eventuale data breach che permette all'attaccante di disporre offline di tutto il database degli utenti, “vedrà” certamente gli eventuali salt ma sarà ignaro del fatto che gli mancherà sempre un pezzo di chiave;
  • il salt è diverso per ogni utente, il pepper, di solito, è unico;
  • il salt serve a rendere uniche la password degli utenti, il pepper protegge l'intero database da attacchi offline.

Il pepper è la chiave di un HMAC, o di un meccanismo di cifratura simmetrica, applicato al digest della password (che ricordo essere salt+password in realtà), che sarà ciò che verrà archiviato.

Va detto che l'uso del “pepper” complica ulteriormente lo scenario di archiviazione. Nella stragrande maggioranza dei casi è sufficiente scegliere un buon algoritmo di password hashing (vedi paragrafo successivo) per scoraggiare gli attaccanti. “Pepare” le password prevederebbe, come detto sopra, l'uso di un HSM per es, e tutta una serie di riflessioni di contorno che evidenzierò più avanti.

Final step: L'hashing

L'ultimo punto da dettagliare è l'hash della password.

L'hash crittografico, in uso in questi casi, deve soddisfare le seguenti proprietà:

  1. resistenza alla pre-immagine: dato un hash h, deve essere impossibile trovare una password p t.c. H(p) = h (non invertibilità della funzione hash)
  2. resistenza alla pre-immagine secondaria: dato una password p1, deve essere impossibile trovare un'altra password p2 t.c. H(p1) = H(p2) (resistenza debole alle collisioni)
  3. resistenza alle collisioni: è impossibile trovare due password diverse, p1 e p2, t.c. H(p1) = H(p2) (resistenza forte alle collisioni)
  4. effetto valanga: il cambio di un solo bit della password deve cambiare radicalmente l'intero hash

In un sistema moderno, l'hash non può essere delegato a funzioni di tipo SHA perché nascono per altri compiti,

SHA-2 e SHA-3 nascono per il digest veloce, per verificare l'integrità di file anche molto grossi o firmare documenti. La loro eccellente velocità diventa il loro più grosso difetto quando si parla di password. Negli scenari precedenti di attachi offline, l'hacker che dispone di una grossa potenza di calcolo, può ricostituire velocemente le rainbow table per n utenti. Magari non di tutti ma di quelli attenzionati.

Le funzioni di derivazione della chiave (KDF) come pbkdf2 e quelle ancora più estreme come B/Scrypt, Argon2, oltre che soddisfare tutti i punti precedentemente elencati tipici di funzioni di password hashing, sono progettate per essere computazionalmente pesantissime da calcolare perché il loro scopo non è il digest ma la protezione di un segreto contro il brute-force. E mentre le vecchie KDF come pbdfk2 sono CPU bound, ma non GPU bound, le KDF più moderne come Bcrypt, Scrypt ma soprattutto Argon2, agiscono pesantemente su tempo, memoria e parallelismo e l'attacco offline di cui sopra diventa impraticabile.

PBKDF2

È il decano delle KDF. Applica iterativamente una funzione pseudorandomica, come HMAC con uno SHA, con salt alla password. Il conteggio delle iterazioni è un parametro configurabile.

PBDKF2 è uno standard di lunga data ampiamente adottato. Se non ci sono necessità stringenti di sicurezza o requisiti legacy, è una buona scelta.

Il fatto di essere solo CPU bound però non la rende la scelta ideale in scenari dove gli attaccanti possono attingere a risorse di calcolo considerevoli

Bcrypt

Basato su Blowfish, anche Bcrypt usa un hash crittografico sulla password con parametri il salt e un fattore di costo.

Il fattore di costo aumenta esponenzialmente il numero di iterazioni per adattarsi all'aumento di potenza di calcolo dell'hardware.

Bcrypt è stato progetto per essere lento e resistente a semplici attacchi di forzat bruta. Tuttavia, il basso utilizzo di ram richiesto dal calcolo lo rendono poco resistente ad attacchi sferrati usando hardware specializzato.

Bcrypt ha dalla sua una storia solidissima in ragione della quale da 20 anni a questa parte non sono state trovate vulnerabilità critiche nel suo design.

Per questo motivo Bcrypt cifra le password di sistema di OpenBSD dal 1999, come pure ha cifrato quelle di tante distro Linux per anni, prima che passassero ad Argon2 o yescrypt (default di Fedora).

Domina nei framework web ([Python] Django, [Ruby] Ruby on Rails, [PHP] Laravel), [Java] Spring, Node.js), nelle applicazioni (Ansible / Terraform, Docker), nel web (la cifratura in .htpasswd di Apache e Nginx) visto che la sua semplcitià di implementazione gli ha permesso di trovarsi praticamente in ogni linguaggio.

È presente come alternativa anche nei password manager benché molti di essi abbiano spostato il default verso Argon2 o PBKDF2 per conformità agli standard FIPS.

È molto semplice implementare e anche da usare perché bisogna agire solo sul fattore di costo (consigliato almeno 10-12, altrimenti diventa troppo vulnerabile ad attacchi sferrati attraverso la GPU)

Scrypt

Rilasciato nel 2009, Scrypt è stato il primo algoritmo a introdurre il concetto di Memory Hardness ed è stato progettato per rendere economicamente poco conveniente il ricorso ad hardware specializzato come gli ASIC o i FPGA e incidere pesantemente su CPU, ram e parallelismo.

Il suo alveo principale sono state le cripto-valute, molte monete lo usano per il mining.

Scrypt lo troviamo in quasi tutti i linguaggi di programmazione, in Tarsnap, servizio di baclup online creato dallo stesso autore di Scrypt, è stato usato da LastPass ed è presente come opzione in VeraCrypt per derivare la chiave dalla password. Fino ad Android 9 era l'algoritmo usato per la FDE del dispositvio (passato poi al FBE) . Presente anche su FreeBSD come opzione per la cifratura delle password di sistema e come opzione su LUKS per la cifratura degli slot delle chiavi.

Su Scrypt i parametri da configurare sono:

  • Costro CPU/Memoria (N): un parametro che aumenta i costi computazionali di cpu e memoria
  • DImensione del blocco ®: influenza la larghezza di banda della memoria
  • Parallelizzazione (p): indica quanto deve incidere sul calcolo parallelo

In questo modo riesce ad essere sia CPU bound che GPU bound che, a differenza di Bcrypt, lo rende resistente anche ad attacchi facenti uso di hardware specializzato..

Di contro, in ambiente in cui siamo vincolati dalle risorse disponibili, la sua potenza diventa un fattore limitante. Quasi paragonabile ad Argon2 in quanto a robustezza, il suo unico tallone d'Achille è la permeabilità ad attacchi di tipo side-channel.

yescrypt

Piccola menzione per yescrypt, appartenente alla famiglia “Scrypt”, pensato per essere ancora più resistente di Scrypt agli attacchi GPU e FPGA ma con una gestione più intelligente delle risorse.

Grazie alle sue peculiarità, di fatto, è diventato il successore spirituale di Bcrypt nei sistemi operativi gnu/linux dove, a cominciare da Fedora, passando per Debian, Ubuntu, Arch, Kali, è il default per la cifratura delle password di sistema in /etc/shadow.

È talmente incardinato ormai nei sistemi operativi, che è la libreria libxcrypt di yescrypt a gestire la tipica funzione crypt() di C che è la base della crittografia su tutti i sistemi gnu/linux moderni.

La sua robustezza unita alla gestione intelligente delle risorse lo rende un coltellino svizzero di riferimento utile per es. per versione custom di LUKS su sistemi embedded, che magari fanno uso di cpu meno recenti, oppure come opzione per strumenti di backup specialistici

Di fatto, sui sistemi operativi, yescrypt s'è guadagnato un consenso amplissimo dovuto alla sua scalabilità, alla sua capacità di usare anche la ROM per rendere il cracking ancora più difficile e senza pesare sulla RAM e alla sua compatibilità potendosi inserire perfettamente nella storica funzione crypt() di C come detto prima.

Se Argon2 è il vincitore accademico avendo vinto il Password Hashing Competition del 2015, yescrypt per la sua robustezza, efficienza e flessibilità si ritaglia un profilo di indispensabilità nei sistemi operativi,

Argon2

E veniamo al dominatore indiscusso di questa che non è una llista esaustiva di KDF.

Argon2 è LO standard moderno per il password hashing raccomandato da OWASP e IETF.

È il riferimento per praticamente ogni password manager: Bitwarden, KeppasXC, 1Password, a cui assegnanp la protezione della Master Password

È la scelta principale per la cifratura degli hard disk anche con impostazioni molto aggressive, in ragione delle quali un ritardo di mezzo secondo (un tempo enorme se venisse scalato esponenzialmente) nell'apertura di un HD è assolutamente accettabile. È il default di LUKS2 (LUKS1 usava PBKDF2) e di VeraCrypt, con cui ha sostituito SHA-512.

Come Bcrypt, è implementato estensivamente su praticamente ogni frameword web e backend, da PHP, Django (Python), Laravel fino a Node.js.

Nei sistemi operativi, laddove yescrytpt domina nella gestione delle password utente, Argon2 è usato per compiti più critici. Dal kernel Linux per gestire internamente le chiavi crittografiche o da macOS / iOS, dove algoritmi proprietari ispirati fortemente ad Argon2, proteggono i dati nel Secure Enclave.

Argon2 setta 3 parametri principali per regolare la sua forza:

  • t: iterazioni, quante volte vengono rimescolati i dati (default Bitwarden = 3)
  • m: memoria, quanta ram deve occupare il calcolo. Questa è la misura anti-GPU (default Bitwarden = 16 (64MB))
  • p: parallelismo, quanti core della cpu usare. Questa è la misura anti-CPU (default Bitwarden = 4)

La variante id è anche resistente agli attacchi side-channel perché impediscono a un attaccante di capire la password osservando i tempi di accesso alla memoria.

Un piccolo esempio: hashing di una password con Argon2

Il grosso vantaggio degli algoritmi di kdf è che sono naturalmente resilienti rispetto all'evoluzione tecnologica che produce macchine con sempre maggiore potenza di calcolo. Da pbkdf2 in poi, il salt implicito che invalida le rainbow table precalcolate e la possibilità di calibrare il key stretching in moda da agire intensivamente su ram e cpu, permettono all'algoritmo di adeguarsi per conservare la sua robustezza.

Mini-script per l'hashing di una password fornita dall'utente con argon2 settato al default di Bitwarden:

echo -n "Password: "; read -s PASSWORD
# Genero un Salt casuale di 128 bit
SALT=$(openssl rand -base64 128)
PASSWORD_HASH=$(echo "${PASSWORD}" | argon2 "${SALT}" -m 16 -t 3 -p 4 -id -e)

PASSWORD_HASH e SALT sono i dati che verranno archiviati e, poiché argon2 “frulla” la password con un salt, è praticamente impossibile risalire alla password originale.

La verifica è tuttavia banale perché, avendo il salt e la password da verificare, si ricrea l'hash con argon2 e si confronta con l'hash memorizzato.

Per maggior sicurezza salt e digest possono essere memorizzati in punti differenti. L'importante è che possano essere recuperate a partire dall'utente.

Gestione del pepper

Col pepper le cose cambiano un pochino perché:

  • deve essere archiviato con tutte le paranoie possibili in un punto diverso dal database degli utenti
  • il key rotation del pepper non è banale

Mini-script che mostra come applicare salt e pepper all'hashing di una password:

# L'utente inserisce la password
echo -n "Password: "; read -s PASSWORD

# Genero un Salt casuale di 128 bit unico per ogni utente
SALT=$(openssl rand -base64 128)

# Anche PEPPER sarà qualcosa del tipo "openssl rand -base64 128"
# e si troverà in un punto esterno al database degli utenti.
PEPPER=$(get_pepper_from_ext)

# Digest della password+salt
PASSWORD_HASH=$(echo "${PASSWORD}" | argon2 "${SALT}" -m 16 -t 3 -p 4 -id -e)

# HMAC del digest con PEPPER come chiave
PASSWORD_PEPPER=$(echo "${PASSWORD_HASH}" | openssl dgst -sha256 -hmac "${PEPPER}" -binary | base64)

HSM

Quella vista prima è una versione molto edulcorata di ciò che avviene nella realtà. Il pepper, non può essere gestito con leggerezza visto che è un segreto che protegge non un singolo oggetto ma intere classi, come db di utenti.

L'apparato che gestisce chiavi di questo tipo e di questa importanza, deve essere robusto, praticamente inattaccabile, quasi completamente isolato dal resto dei sistemi a meno delle applicazioni, e solo di quelle, che hanno il permesso di richiedere una chiave,

Apparati hardware specializzati che assolvono a tutte queste funzioni e anche di più, sono gli HSM (Hardware Security Module) che garantiscono il ciclo di vita delle chiavi, dalla generazione alla distruzione, includendo versionamento, rotazione e backup. Sono concepiti per resistere anche a manipolazioni forzate che possono innescare un meccanismo di autodistruzione e, particolare rilevante, le operazioni crittografiche basate sulle chiavi protette vengono svolte dall'hsm che consegna al client il risultato delle operazioni, non le chiavi. Nel nostro caso, l'HSM dovrebbe restituirci l'hmac del digest della password che gli inviamo.

Key / Algo Rotation

Cosa succede se cambio pepper o algoritmo (anche la sua configurazione)? Non avendo disponibilità in alcun modo della password dovrò adottare una strategia ad-hoc. Fra tutti gli scenari possibili, il miglior compromesso fra sicurezza e comodità secondo me, è quello basato sul wrapping.

È necessario innanzitutto che vengano conservate le versioni delle chiavi per i servizi che le richiedono. E a questo dovrebbe pensarci l'HSM, se ce n'è uno o qualcosa di custom che abbia funzionalità analoghe. Inoltre dovrebbero esserci dei flag che indichino quali sono gli utenti a cui sono state applicate le nuove configurazioni.

Caso A: Algo rotation

Supponiamo che l'algoritmo di hashing venga cambiato o vengano cambiate le sue configurazioni.

Premessa: Nel mio DB degli utenti, in corrispondenza di ogni utente, avrò:

  1. il digest della password “pepato”: HMAC ( pepper, HASH ( salt, password ) )
  2. il salt

Il wrapping: La strategia sarà quello di “avvolgere” la password di ogni utente col nuovo algoritmo, settare un qualche flag che mi indichi l'operazione compiuta e archiviare il tutto.

  1. Imponiamo il nuovo algoritmo a tutti gli utenti “imbustando” il digest attuale (in questo caso 'HMAC in realtà, visto che abbiamo a che fare anche col pepper) con il nuovo digest HASH_NEW: HASH_NEW ( salt_new, HMAC ( pepper, HASH ( salt, password ) ) ).
  2. Per ogni utente averemo dunque:
    1. il nuovo digest al posto di quello vecchio,
    2. il nuovo salt
    3. il vecchio salt
  3. Settiamo il flag del cambio algoritmo a true (o quello che è)
  4. Quando l'utente effettuerà il login con successo e il flag sarà a “true”, abbiamo la password che ci permetterà di eliminare il vecchio “involucro” e ripristinare l'HMAC del nuovo digest: HMAC ( pepper, HASH_NEW ( salt_new, password ) ) e il flag ritornerà a “false“

Considerazioni:

  • La sicurezza non viene compromessa perché il digest di un digest, con KDF configurate a dovere, non comporta alcun rischio.
  • La fase di verifica è quella che si complica di più perché in base al valore del flag, dovrà essere effettuata in maniera differente.
    • Se il flag è “true” (nella nostra convenzione), dopo il login devo avere gli elementi per calcolare il digest in questo modo: HASH_NEW ( salt_new, HMAC ( pepper, HASH ( salt, password ) ) ).
    • Se il flag è a false, calcolerò al solito: HMAC ( pepper, HASH_NEW ( salt_new, password ) )

Caso B: Pepper rotation

Supponiamo che a ruotare sia il pepper. Procediamo sempre con il wrapping massivo su tutti gli utenti incapsulando il digest :

HMAC ( pepper, HASH ( salt, password ) )

con quello nuovo:

HMAC ( pepper_new, HMAC ( pepper, HASH ( salt, password ) ) )

mettendo il flag a “true”.

Come prima, una volta che gli utenti cominceranno a fare il login, se il flag è “true” innanzitutto verificherò che:

HMAC ( pepper_new, HMAC ( pepper, HASH ( salt, password ) ) )

sia uguale a ciò che è stato archiviato. Se così fosse, ora che sono di nuovo in possesso della password, ripristinerò l'HMAC con:

HMAC ( pepper_new, HASH ( salt, password ) )

memorizzandolo al posto di quello vecchio e rimettendo il flag a false.

Considerazioni: La modifica massiva delle password degli utenti, stavolta passa dall'HSM e potrebbe essere un problema perché un HSM è progettato per scoraggiare flooding di richieste.

È vero che il pepper è sempre lo stesso per tutti gli utenti ma, come ricordavo prima, di solito un HSM non fornisce i suoi segreti ma solo i risultati crittografici delle loro applicazioni.

#kdf #pbkdf2 #bcrypt #scrypt #yescrypt #argon2 #luks #cryptography #aes #sha #digest #RainbowTable #BruteForce #salt #pepper #entropy #hsm #hmac #hash

]]> https://noblogo.org/aytin/archiviare-le-password-in-sicurezza-con-kdf-password-hashing-trilogia-della Thu, 29 Jan 2026 17:49:50 +0000 Come valutare la resistenza di una password (Trilogia Della Password - 2 di 3) https://noblogo.org/aytin/come-valutare-la-resistenza-di-una-password-trilogia-della-password-2-di-3 <![CDATA[ent,zxcvb,diceware In "Come generare una password o un keyfile sicuri" abbiamo visto come generare password e keyfile che si basassero su dati il più possibile casuali. La verifica matematica di una password si basa sulla determinazione del numero di tentativi necessari a un attaccante per indovinarla. !--more-- Esistono due approcci: quello teorico (brute force) e quello realistico (pattern matching). Calcolo teorico (Entropia di Shannon) Spiegazione dell’entropia di Shannon Esempi d’uso Calcolo realistico (pattern matching) Ent zxcvbn Riassumendo Metodo Diceware Calcolo teorico (Entropia di Shannon) Un primo strumento per la valutazione di una password è dato dall'entropia di Shannon, che chiunque abbia usato un password manager certamente conoscerà. Questo calcolo assume che l'attaccante non sappia nulla della nostra password e debba provare ogni possibile combinazione (forza bruta). Dato un alfabeto di R simboli e una password di lunghezza L, l'entropia E sarà pari a: E = logsub2/sub ( RsupL/sup ) = L \ logsub2/sub ( R ) L'entropia è un valore numerico espresso in bit (gli "Shannon") che rappresenta una misura, non tanto della robustezza, quanto della "densità" della password, ossia di quanto lavoro richieda ad un calcolatore per essere indovinata. Più è alta, meglio è. Spiegazione dell'entropia di Shannon Innanzitutto notiamo che RsupL/sup è la dimensione dello spazio di possibilità in cui esiste la mia password e, per R e L sufficientemente grandi, è un numero talmente enorme da essere difficilmente comprensibile. L'equivalente E, che non è altro che l'esponente della potenza di 2 tale per cui 2supE/sup = RsupL/sup, risulta invece molto più gestibile e confrontabile. Semplificando, se alla mia password lunga L corrisponde quindi un'analoga chiave in bit lunga E, un attaccante che voglia scoprire la mia password, invece che indovinare gli L simboli da un alfabeto R, compirà lo stesso sforzo rispondendo correttamente ad un numero di domande binarie (SI / NO) pari a E, per ricostruire la giusta sequenza binaria. Quanto costa ricostruire la sequenza? O, in altre parole, qual è lo sforzo computazionale richiesto? Si parla di caso medio ottimale corrispondente ad una ricerca binaria in cui ogni domanda dimezza lo spazio di possibilità fino ad azzerarlo completamente. E = L \ logsub2/sub ( R ), è quel numero di bit che mi dice quant'è profondo l'albero delle decisioni che il calcolatore deve percorrere, albero in cui il numero dei possibili cammini radice-foglia (equivalenti a tutte le possibili password) è 2supE/sup = RsupL/sup. Nel caso migliore, rispondo correttamente a tutte le E domande al primo tentativo (trovo subito il mio cammino sull'albero). Nel caso peggiore, mi occorreranno 2supE/sup risposte (percorro tutti i cammini dell'albero) equivalente proprio a RsupL/sup. Possiamo allora definire formalmente l'entropia come quella quantità minima di informazione necessaria ad azzerare l'incertezza legata all'identificazione della password. Per questo motivo è espressa in bit. Una misurazione di questo tipo ha senso solo se ipotizziamo che i simboli siano tutti equiprobabili. La formula di Shannon misura, sì, l'entropia, ma al suo massimo potenziale, quando la distribuzione dei simboli nella sequenza è omogenea e assolutamente casuale. Esempi d'uso Facciamo l'esempio di una password lunga 20, costruita su un alfabeto di 66 simboli (alfanumerico con maiuscole e minuscole più 4 simboli speciali). La dimensione di questo spazio di possibilità è pari a: Ssubp/sub = RsupL/sup = 66sup20/sup = 2,46 \ 10sup36/sup Tentare un attacco di forza bruta su un oggetto del genere è semplicemente impensabile. Faccio un esempio. Per forzare la nostra password, supponiamo di avere a disposizione il più potente supercomputer del mondo, El Capitan ad oggi, dotato di una potenza di calcolo spaventosa, in media 2.000 exaFLOPS con picchi di 2.746 exaFLOPS, dove 1 exaFLOPS è un quintilione (10sup18/sup) di operazioni al secondo. Il calcolo di una password si misura in Hash al secondo, H/s per usare una notazione compatta, che è più dispendiosa della singola operazione. Approssimando per eccesso con molto ottimismo e nell'ipotesi di usare algoritmi estrememente deboli e poco costosi dal punto di vista computazionale come NTLM o MD5, possiamo pensare che il nostro sistema possa arrivare a calcolare, in queste condizioni, circa 1,5 quintilioni ( 1,5 \ 10sup18/sup ) H/s. Per algoritmi come bcrypt o argon2, progettati per essere molto dispendiosi, tale potenza si riduce drasticamente di molti ordini di grandezza. Da 10sup18/sup a 10sup9/sup - 10sup6/sup. Ma consideriamo il caso più favorevole perché sembra appunto una potenza enorme. Ma anche questa tremenda esibizione di potenza annichilisce di fronte al numero di calcoli da compiere nel nosro spazio di possibilità. Dato Ssubp/sub lo spazio di possibilità (il numero di possibili combinazioni), il tempo T espresso in secondi necessario ad eseguire tutte le operazioni sarà: Ssubp/sub = 66sup20/sup = 2,46 \ 10sup36/sup T = 2,46 \ sup36/sup / 1,5 \ 10sup18/sup = 1,64 \ 10sup18/sup Che equivale a circa 52 miliardi di anni. Per avere un'idea di questa grandezza cosmica, si pensi che l'età del nostro universo è di circa 13,8 miliardi di anni. Quindi il calcolo della nostra password potrebbe richiedere un tempo che è grossomodo 3,8 volte l'età dell'universo. I 120 bit di entropia, sono dunque la misura di questo sforzo potenziale, interpretabile equivalentemente in due modi differenti: la probabilità di riuscire a trovare la password tirando a indovinare, probabilità che è 1 su 2sup120/sup oppure la capacità di rispondere correttamente e consecutivamente a 120 domande di tipo (SI / NO) (ricerca del giusto cammino in un albero decisionale binario profondo 120 livelli) Allungando la nostra password di altri due caratteri, l'entropia arriva a circa 133 e il calcolo delle possibili combinazioni, posto che fosse possibile ignorando le leggi della termodinamica, richiederebbe circa 16.500 di volte l'età dell'universo. Considerazione a margine: è la lunghezza della password ad incidere più che la complessità dell'alfabeto. E lo vediamo dalla formula dell'entropia, perché, in una funzione di elevamento a potenza RsupL/sup, aumentare l'esponente L fa crescere molto più rapidamente la funzione che non aumentando la base R. Calcolo realistico (pattern matching) L'entropia di Shannon fornisce un riscontro utilizzabile solo ipotizzando che: le scelte siano indipendenti la distribuzione sia uniforme e in uno scenario di questo tipo, l'attacco di forza bruta non è una via percorribile. Allo stesso tempo, se non vengono rispettati questi vincoli, l'entropia dà una falsa sicurezza perché la formula di Shannon "standard" non tiene conto della ridondanza: Consideriamo questa password: Password12345678 teoria: la formula E = L log2R direbbe che la sua entropia sia 95, ottima. realtà: poiché è una sequenza ovvia, l'attaccante la proverà per prima. La sua entropia reale sarà vicina a 0 bit. L'entropia quindi misura la "densità" della password, la sua imprevedibilità potenziale ma non dà nessuna informazione sulla presenza di schemi ripetuti e sul pattern matching. Ent L'essere umano come generatore di entropia fa schifo. Ecco perché, per un attaccante, prima ancora di provare tutte le possibili combinazioni di caratteri, un attacco a dizionario può far risparmiare un sacco di tempo. Infatti sempre Shannon ci dice che nelle parole dei linguaggi naturali alcune lettere ricorrono più di altre, non serve lo stesso numero di domanda ma molto meno e così l'entropia media diminuisce. Per prevenire questi effetti collaterali, il nostro metodo di generazione e quindi ciò che viene generato, deve essere testato con qualcos'altro che non sia la semplice entropia. ent è un tool a linea di comando che fa 4 valutazioni differenti: entropia Chi-quadrato Media aritmetica Monte Carlo Pi N.B. ent non è adatto alla valutazione della singola password perché ha bisogno di migliaia di dati (almeno 1K). Una singola password di 24 caratteri per es. (24 byte) non ha materiale casuale sufficiente affinché ent converga verso un giudizio oggettivo. Entropia L'entropia misura la densità di informazione. In ent, viene calcolata in bit per carattere (byte). Il valore: Si analizza il file byte per byte, il valore massimo è 8.0 (ogni byte è totalmente imprevedibile). Interpretazione: Più il valore è vicino a 8, più la casualità è "densa" e difficile da indovinare tramite attacchi basati su dizionario. Se il valore è basso (es. 2.0 o 3.0), significa che ci sono molte ripetizioni o uno schema prevedibile. Compressione: ent ti dice anche quanto il file potrebbe essere compresso. Un'entropia di 8.0 significa che il file è già "puro caos" e non può essere compresso ulteriormente. Chi-quadrato Il test del chi-quadrato prova a capire se il disordine presente nel file sia veramente equo o se si preferiscono certi caratteri ad altri. Esamina la distribuzione dei caratteri e la confronta con una distribuzione uniforme teorica. Il risultato viene presentato come percentuale con questi scaglioni: 10% \ chi<sup2/sup \< 90%: La sequenza è considerata casuale. Il 50% è il valore "perfetto". chisup2/sup \ 1% o chi<sup2/sup \ 99%: È quasi certamente non casuale. chisup2/sup = 99.99%: i dati sono sospettosamente regolari; chisup2/sup = 0.01%: i dati sono "troppo" casuali per essere naturali (sospetta manipolazione) Media aritmetica Per capire se la distribuzione è sufficientemente omogenea, si fa la somma dei valori dei byte del file e si fa una media. Poiché i byte vanno da 0 a 255, il valore ideale della media sarebbe 127,5. Se è troppo lontano dalla media avvcinandosi ad uno dei due estremi (ad es. 50 o 190), vuol dire che si sta usando solo un piccola parte dei caratteri a disposizione e questo, a suo modo di vedere, rende le password più prevedibili. Monte Carlo Pi È il metodo più fantasioso di tutti. I dati casuali vengono trasformati in una serie di "dardi" virtuali che vanno a colpire un bersaglio. L'obiettivo non è quello di colpire un ipotico centro ma di verificare che i "dardi" si distribuiscano uniformemente nel bersaglio. Tutto ciò si realizza immaginando di avere un quadrato 1x1 e 1/4 di cerchio al suo interno di raggio 1 e area π/4 I dati della sequenza casuale vengono prelevati a gruppi di n byte e supponiamo n = 3 per ora. Ogni gruppo di 3 byte sarà un numero compreso tra 0 e 2sup24/sup-1. Se normalizziamo questo numero dividendolo per 2sup24/sup, otteniamo un numero compreso fra 0 e 1. Calcolando le coordinate in questo modo, col teorema di Pitagora possiamo verificare se la coordinata (X,Y) "cada" nel quarto di cerchio oppure no e ciò succede se: Xsup2/sup + Ysup2/sup ≤ 1 Lanciando un migliaio di queste "frecce", accumuliamo dati sufficiente per fare una stima. Se indichiamo con In il numero di "lanci" con successo e con Total il numero totale di lanci effettuati: 4 \ (ln/Total) si avvicinerà a π solo se la distribuzione dei caratteri sarà uniforme (indice di una casualità omogenea), altrimenti divergerà in maniera significativa (indice della presenza di pattern o di ripetizioni). zxcvbn ent fa un'analisi statistica della distribuzione dei bit in un generatore di casualità. zxcvbn invece fa un'analisi di tipo euristico, è verticale sulla verifica delle password in particolare nel rilevare se vi sono schemi o ripetizioni di caratteri che renderebbero le password violabili. Il suo algoritmo scompone le password in pezzi dei quali cerca corrispondenze in dizionari o schemi come: dizionari: controlla la presenza di parole di uso comune sequenze: controlla la presenza di serie di caratteri prevedibili come "123456", "abcde" pattern spaziali: controlla la presenza di percorsi sulla tastiera come "qwerty", "asdfg", "zcvbn" o sequenze diagonali ripetizioni: ripetizione di caratteri come "kkkkkkkkkk" o "12121212" l33t: una parola come "p4$$w0rd" viene subito riconosciuta come "password" date: riconosce giorni, mesi, anni, anche composti come "15062026" Il suo uso è molto semplice. Le si dà in pasto la password e zxcvbn restituisce diverse informazioni utili: uno score da "0" (terribile) a "4 (ottima); la stima di quanto tempo impiegherebbe un hacker a violarla in base a vari scenari di attacco; suggerimenti su come migliorare eventualmente la password. zxcvbn era una libreria javascript orginariamente sviluppata da Dropbox e ora disponibile in tante forme: go, python, c++. L'originale Dropbox in javascript, non più manutenuto, può essere trovata qui: https://github.com/dropbox/zxcvbn. Benché esistano diversi porting in python, se c'è l'esigenza di usare la versione legacy, gli stessi sviluppatori dell'originale zxcvbn consigliano questa versione: https://github.com/dwolfhub/zxcvbn-python, che può essere installata con pip. In realtà la versione migliore è un fork in typescript, zxcvbn-ts che offre modularità (a differenza della versione python che è monolitica), maggior sicurezza, risoluzione di bug, aggiornamento continuo dizionari compresi. Per capirci, mentre ent usa l'entropia di Shannon per valutare la probabilità statistica dei byte, zxcvbn cerca di calcolare una stima dei tempi necessari per indovinare la password. Una passphrase su ent avrebbe un punteggio risibile perché le entropie di parole comuni sono molto basse. Su zxcvbn invece avrebbe un punteggio molto alto perché l'entropia di una parola viene calcolata sulla posizione del dizionario che la contiene per cui un hacker dovrebbe provare milioni di combinazioni prima di trovarla. Allo stesso modo, password che per ent sarebbero ottime, per zxcvbn sarebbero da evitare perché legate a pattern o a ripetizioni. Riassumendo Se si deve testare una password / passphrase, sicuramente zxcvbn. Se si deve testare un generatore di casualità o un keyfile di almeno 2k, sicuramente ent. Metodo Diceware Visto che nell'ultima parte abbiamo evidenziato l'anomalia che sorge nel momento in cui si valuta un oggetto casuale o dal punto di vista puramente statistico o dal punto di vista euristico, vale la pena di spendere due parole sulla modalità di creazione delle passphrase usando il metodo Diceware. Usando come password parole estratte dal linguaggio naturale bisogna fare i conti col problema della prevedibilità. Shannon ha dimostrato che la lingua italiana (o inglese) ha un'entropia molto bassa (circa 1-1.5 bit per lettera) perché dopo una "q" ci si aspetta quasi sempre una "u", e dopo un soggetto ci si aspetta un verbo. E così via. Ecco perché, piuttosto che valutare l'entropia nel suo complesso e provare ogni possibile combinazione, un moderno calcolatore inzia col far ricorso a "pattern" umani per violare password in pochi minuti invece che millenni. Per unire la sicurezza del calcolo casuale alla comodità di una password menmonica, si ricorre al metodo Diceware che consiste nel far uso di un dizionario di migliaia di parole. Quello classico, di 7776 parole inglesi, curato dall EFF si può trovare qui: curl -L https://www.eff.org/files/2016/07/18/efflargewordlist.txt dicdiceware.txt Altrimenti Tarin Gamberini espone il suo dizionario diceware , aggiornato al 2019, qui: https://www.taringamberini.com/downloads/dicewareitIT/lista-di-parole-diceware-in-italiano/4/wordlistdicewareit-IT-4.txt. Questo dizionario contiene 6sup5/sup parole numerate da 11111 a 66666. La passphrase è composta da n di queste parole il cui indice è ricavato lanciando un dado (o un analogo virtuale) per 5 volte. In questo modo le parole non sono correlate fra di loro come si potrebbero trovare in una frase, vanificando ogni possibile speculazione sulla sua composizione. Volendo fare un calcolo dell'entropia, supponendo di costruire una passphrase di 6 parole: E = L \ logsub2/sub R = 6 \ logsub2/sub 7776 ~ 77,6 Nella password classiche basate su un alfabeto di R simboli, il mattoncino è rappresentato dal singolo carattere che ha una probabilità 1/R di essere estratto. Con Diceware, il mattoncino è la parola che ha una probabilità su 7776 di essere estratta. Ogni parola in più, aggiunge una quantità enorme di incertezza. Ecco perché con sole 6 parole abbiamo già una passphrase molto robusta e con 10 parole siamo di fronte ad una passphrase inattacabile, almeno dal punto di vista dell'analisi statistica (E 129_) e imperforabile anche ricorrendo ad analisi euristiche. Regola aurea: la scelta delle parole deve essere realmente casuale e non seguire regole grammaticali o preferenze personali. Altrimenti sarà un gioco da ragazzi violarla con un approccio a-là zxcvbn. #entropy #shannon #bruteforce #ent #zxcvbn #diceware #passphrase #PatternMatching]]> ent,zxcvb,diceware

In “Come generare una password o un keyfile sicuri” abbiamo visto come generare password e keyfile che si basassero su dati il più possibile casuali. La verifica matematica di una password si basa sulla determinazione del numero di tentativi necessari a un attaccante per indovinarla. Esistono due approcci: quello teorico (brute force) e quello realistico (pattern matching).

Calcolo teorico (Entropia di Shannon)

Un primo strumento per la valutazione di una password è dato dall'entropia di Shannon, che chiunque abbia usato un password manager certamente conoscerà.

Questo calcolo assume che l'attaccante non sappia nulla della nostra password e debba provare ogni possibile combinazione (forza bruta).

Dato un alfabeto di R simboli e una password di lunghezza L, l'entropia E sarà pari a:

E = log2 ( RL ) = L * log2 ( R )

L'entropia è un valore numerico espresso in bit (gli “Shannon”) che rappresenta una misura, non tanto della robustezza, quanto della “densità” della password, ossia di quanto lavoro richieda ad un calcolatore per essere indovinata. Più è alta, meglio è.

Spiegazione dell'entropia di Shannon

Innanzitutto notiamo che RL è la dimensione dello spazio di possibilità in cui esiste la mia password e, per R e L sufficientemente grandi, è un numero talmente enorme da essere difficilmente comprensibile.

L'equivalente E, che non è altro che l'esponente della potenza di 2 tale per cui 2E = RL, risulta invece molto più gestibile e confrontabile.

Semplificando, se alla mia password lunga L corrisponde quindi un'analoga chiave in bit lunga E, un attaccante che voglia scoprire la mia password, invece che indovinare gli L simboli da un alfabeto R, compirà lo stesso sforzo rispondendo correttamente ad un numero di domande binarie (SI / NO) pari a E, per ricostruire la giusta sequenza binaria.

Quanto costa ricostruire la sequenza? O, in altre parole, qual è lo sforzo computazionale richiesto?

Si parla di caso medio ottimale corrispondente ad una ricerca binaria in cui ogni domanda dimezza lo spazio di possibilità fino ad azzerarlo completamente.

E = L * log2 ( R ), è quel numero di bit che mi dice quant'è profondo l'albero delle decisioni che il calcolatore deve percorrere, albero in cui il numero dei possibili cammini radice-foglia (equivalenti a tutte le possibili password) è 2E = RL.

  • Nel caso migliore, rispondo correttamente a tutte le E domande al primo tentativo (trovo subito il mio cammino sull'albero).
  • Nel caso peggiore, mi occorreranno 2E risposte (percorro tutti i cammini dell'albero) equivalente proprio a RL.

Possiamo allora definire formalmente l'entropia come quella quantità minima di informazione necessaria ad azzerare l'incertezza legata all'identificazione della password. Per questo motivo è espressa in bit.

Una misurazione di questo tipo ha senso solo se ipotizziamo che i simboli siano tutti equiprobabili.

La formula di Shannon misura, sì, l'entropia, ma al suo massimo potenziale, quando la distribuzione dei simboli nella sequenza è omogenea e assolutamente casuale.

Esempi d'uso

Facciamo l'esempio di una password lunga 20, costruita su un alfabeto di 66 simboli (alfanumerico con maiuscole e minuscole più 4 simboli speciali). La dimensione di questo spazio di possibilità è pari a:

Sp = RL = 6620 = 2,46 * 1036

Tentare un attacco di forza bruta su un oggetto del genere è semplicemente impensabile. Faccio un esempio.

Per forzare la nostra password, supponiamo di avere a disposizione il più potente supercomputer del mondo, El Capitan ad oggi, dotato di una potenza di calcolo spaventosa, in media 2.000 exaFLOPS con picchi di 2.746 exaFLOPS, dove 1 exaFLOPS è un quintilione (1018) di operazioni al secondo.

Il calcolo di una password si misura in Hash al secondo, H/s per usare una notazione compatta, che è più dispendiosa della singola operazione.

Approssimando per eccesso con molto ottimismo e nell'ipotesi di usare algoritmi estrememente deboli e poco costosi dal punto di vista computazionale come NTLM o MD5, possiamo pensare che il nostro sistema possa arrivare a calcolare, in queste condizioni, circa 1,5 quintilioni ( 1,5 * 1018 ) H/s. Per algoritmi come bcrypt o argon2, progettati per essere molto dispendiosi, tale potenza si riduce drasticamente di molti ordini di grandezza. Da 1018 a 109 – 106. Ma consideriamo il caso più favorevole perché sembra appunto una potenza enorme.

Ma anche questa tremenda esibizione di potenza annichilisce di fronte al numero di calcoli da compiere nel nosro spazio di possibilità. Dato Sp lo spazio di possibilità (il numero di possibili combinazioni), il tempo T espresso in secondi necessario ad eseguire tutte le operazioni sarà:

Sp = 6620 = 2,46 * 1036

T = 2,46 * 36 / 1,5 * 1018 = 1,64 * 1018

Che equivale a circa 52 miliardi di anni.

Per avere un'idea di questa grandezza cosmica, si pensi che l'età del nostro universo è di circa 13,8 miliardi di anni. Quindi il calcolo della nostra password potrebbe richiedere un tempo che è grossomodo 3,8 volte l'età dell'universo.

I 120 bit di entropia, sono dunque la misura di questo sforzo potenziale, interpretabile equivalentemente in due modi differenti:

  • la probabilità di riuscire a trovare la password tirando a indovinare, probabilità che è 1 su 2120

oppure

  • la capacità di rispondere correttamente e consecutivamente a 120 domande di tipo (SI / NO) (ricerca del giusto cammino in un albero decisionale binario profondo 120 livelli)

Allungando la nostra password di altri due caratteri, l'entropia arriva a circa 133 e il calcolo delle possibili combinazioni, posto che fosse possibile ignorando le leggi della termodinamica, richiederebbe circa 16.500 di volte l'età dell'universo.

Considerazione a margine: è la lunghezza della password ad incidere più che la complessità dell'alfabeto. E lo vediamo dalla formula dell'entropia, perché, in una funzione di elevamento a potenza RL, aumentare l'esponente L fa crescere molto più rapidamente la funzione che non aumentando la base R.

Calcolo realistico (pattern matching)

L'entropia di Shannon fornisce un riscontro utilizzabile solo ipotizzando che:

  • le scelte siano indipendenti
  • la distribuzione sia uniforme

e in uno scenario di questo tipo, l'attacco di forza bruta non è una via percorribile.

Allo stesso tempo, se non vengono rispettati questi vincoli, l'entropia dà una falsa sicurezza perché la formula di Shannon “standard” non tiene conto della ridondanza:

Consideriamo questa password: Password12345678

  • teoria: la formula E = L * log2R direbbe che la sua entropia sia 95, ottima.
  • realtà: poiché è una sequenza ovvia, l'attaccante la proverà per prima. La sua entropia reale sarà vicina a 0 bit.

L'entropia quindi misura la “densità” della password, la sua imprevedibilità potenziale ma non dà nessuna informazione sulla presenza di schemi ripetuti e sul pattern matching.

Ent

L'essere umano come generatore di entropia fa schifo. Ecco perché, per un attaccante, prima ancora di provare tutte le possibili combinazioni di caratteri, un attacco a dizionario può far risparmiare un sacco di tempo. Infatti sempre Shannon ci dice che nelle parole dei linguaggi naturali alcune lettere ricorrono più di altre, non serve lo stesso numero di domanda ma molto meno e così l'entropia media diminuisce. Per prevenire questi effetti collaterali, il nostro metodo di generazione e quindi ciò che viene generato, deve essere testato con qualcos'altro che non sia la semplice entropia.

ent è un tool a linea di comando che fa 4 valutazioni differenti:

  • entropia
  • Chi-quadrato
  • Media aritmetica
  • Monte Carlo Pi

N.B. ent non è adatto alla valutazione della singola password perché ha bisogno di migliaia di dati (almeno 1K). Una singola password di 24 caratteri per es. (24 byte) non ha materiale casuale sufficiente affinché ent converga verso un giudizio oggettivo.

Entropia L'entropia misura la densità di informazione. In ent, viene calcolata in bit per carattere (byte).

  • Il valore: Si analizza il file byte per byte, il valore massimo è 8.0 (ogni byte è totalmente imprevedibile).
  • Interpretazione: Più il valore è vicino a 8, più la casualità è “densa” e difficile da indovinare tramite attacchi basati su dizionario. Se il valore è basso (es. 2.0 o 3.0), significa che ci sono molte ripetizioni o uno schema prevedibile.
  • Compressione: ent ti dice anche quanto il file potrebbe essere compresso. Un'entropia di 8.0 significa che il file è già “puro caos” e non può essere compresso ulteriormente.

Chi-quadrato Il test del chi-quadrato prova a capire se il disordine presente nel file sia veramente equo o se si preferiscono certi caratteri ad altri. Esamina la distribuzione dei caratteri e la confronta con una distribuzione uniforme teorica. Il risultato viene presentato come percentuale con questi scaglioni:

  • 10% < chi2 < 90%: La sequenza è considerata casuale. Il 50% è il valore “perfetto”.
  • chi2 < 1% o chi2 > 99%: È quasi certamente non casuale.
    • chi2 = 99.99%: i dati sono sospettosamente regolari;
    • chi2 = 0.01%: i dati sono “troppo” casuali per essere naturali (sospetta manipolazione)

Media aritmetica Per capire se la distribuzione è sufficientemente omogenea, si fa la somma dei valori dei byte del file e si fa una media.

Poiché i byte vanno da 0 a 255, il valore ideale della media sarebbe 127,5. Se è troppo lontano dalla media avvcinandosi ad uno dei due estremi (ad es. 50 o 190), vuol dire che si sta usando solo un piccola parte dei caratteri a disposizione e questo, a suo modo di vedere, rende le password più prevedibili.

Monte Carlo Pi È il metodo più fantasioso di tutti. I dati casuali vengono trasformati in una serie di “dardi” virtuali che vanno a colpire un bersaglio. L'obiettivo non è quello di colpire un ipotico centro ma di verificare che i “dardi” si distribuiscano uniformemente nel bersaglio.

Tutto ciò si realizza immaginando di avere un quadrato 1x1 e ¼ di cerchio al suo interno di raggio 1 e area π/4 I dati della sequenza casuale vengono prelevati a gruppi di n byte e supponiamo n = 3 per ora. Ogni gruppo di 3 byte sarà un numero compreso tra 0 e 224-1. Se normalizziamo questo numero dividendolo per 224, otteniamo un numero compreso fra 0 e 1. Calcolando le coordinate in questo modo, col teorema di Pitagora possiamo verificare se la coordinata (X,Y) “cada” nel quarto di cerchio oppure no e ciò succede se:

X2 + Y2 ≤ 1

Lanciando un migliaio di queste “frecce”, accumuliamo dati sufficiente per fare una stima.

Se indichiamo con In il numero di “lanci” con successo e con Total il numero totale di lanci effettuati:

4 * (ln/Total) si avvicinerà a π solo se la distribuzione dei caratteri sarà uniforme (indice di una casualità omogenea), altrimenti divergerà in maniera significativa (indice della presenza di pattern o di ripetizioni).

zxcvbn

ent fa un'analisi statistica della distribuzione dei bit in un generatore di casualità.

zxcvbn invece fa un'analisi di tipo euristico, è verticale sulla verifica delle password in particolare nel rilevare se vi sono schemi o ripetizioni di caratteri che renderebbero le password violabili.

Il suo algoritmo scompone le password in pezzi dei quali cerca corrispondenze in dizionari o schemi come:

  • dizionari: controlla la presenza di parole di uso comune
  • sequenze: controlla la presenza di serie di caratteri prevedibili come “123456”, “abcde”
  • pattern spaziali: controlla la presenza di percorsi sulla tastiera come “qwerty”, “asdfg”, “zcvbn” o sequenze diagonali
  • ripetizioni: ripetizione di caratteri come “kkkkkkkkkk” o “12121212”
  • l33t: una parola come “p4$$w0rd” viene subito riconosciuta come “password”
  • date: riconosce giorni, mesi, anni, anche composti come “15062026”

Il suo uso è molto semplice. Le si dà in pasto la password e zxcvbn restituisce diverse informazioni utili:

  • uno score da “0” (terribile) a “4 (ottima);
  • la stima di quanto tempo impiegherebbe un hacker a violarla in base a vari scenari di attacco;
  • suggerimenti su come migliorare eventualmente la password.

zxcvbn era una libreria javascript orginariamente sviluppata da Dropbox e ora disponibile in tante forme: go, python, c++.

L'originale Dropbox in javascript, non più manutenuto, può essere trovata qui: https://github.com/dropbox/zxcvbn.

Benché esistano diversi porting in python, se c'è l'esigenza di usare la versione legacy, gli stessi sviluppatori dell'originale zxcvbn consigliano questa versione: https://github.com/dwolfhub/zxcvbn-python, che può essere installata con pip.

In realtà la versione migliore è un fork in typescript, zxcvbn-ts che offre modularità (a differenza della versione python che è monolitica), maggior sicurezza, risoluzione di bug, aggiornamento continuo dizionari compresi.

Per capirci, mentre ent usa l'entropia di Shannon per valutare la probabilità statistica dei byte, zxcvbn cerca di calcolare una stima dei tempi necessari per indovinare la password.

Una passphrase su ent avrebbe un punteggio risibile perché le entropie di parole comuni sono molto basse. Su zxcvbn invece avrebbe un punteggio molto alto perché l'entropia di una parola viene calcolata sulla posizione del dizionario che la contiene per cui un hacker dovrebbe provare milioni di combinazioni prima di trovarla.

Allo stesso modo, password che per ent sarebbero ottime, per zxcvbn sarebbero da evitare perché legate a pattern o a ripetizioni.

Riassumendo

Se si deve testare una password / passphrase, sicuramente zxcvbn. Se si deve testare un generatore di casualità o un keyfile di almeno 2k, sicuramente ent.

Metodo Diceware

Visto che nell'ultima parte abbiamo evidenziato l'anomalia che sorge nel momento in cui si valuta un oggetto casuale o dal punto di vista puramente statistico o dal punto di vista euristico, vale la pena di spendere due parole sulla modalità di creazione delle passphrase usando il metodo Diceware.

Usando come password parole estratte dal linguaggio naturale bisogna fare i conti col problema della prevedibilità. Shannon ha dimostrato che la lingua italiana (o inglese) ha un'entropia molto bassa (circa 1-1.5 bit per lettera) perché dopo una “q” ci si aspetta quasi sempre una “u”, e dopo un soggetto ci si aspetta un verbo. E così via. Ecco perché, piuttosto che valutare l'entropia nel suo complesso e provare ogni possibile combinazione, un moderno calcolatore inzia col far ricorso a “pattern” umani per violare password in pochi minuti invece che millenni.

Per unire la sicurezza del calcolo casuale alla comodità di una password menmonica, si ricorre al metodo Diceware che consiste nel far uso di un dizionario di migliaia di parole.

Quello classico, di 7776 parole inglesi, curato dall EFF si può trovare qui:

curl -L https://www.eff.org/files/2016/07/18/eff_large_wordlist.txt > dic_diceware.txt

Altrimenti Tarin Gamberini espone il suo dizionario diceware , aggiornato al 2019, qui: https://www.taringamberini.com/downloads/diceware_it_IT/lista-di-parole-diceware-in-italiano/4/word_list_diceware_it-IT-4.txt.

Questo dizionario contiene 65 parole numerate da 11111 a 66666. La passphrase è composta da n di queste parole il cui indice è ricavato lanciando un dado (o un analogo virtuale) per 5 volte. In questo modo le parole non sono correlate fra di loro come si potrebbero trovare in una frase, vanificando ogni possibile speculazione sulla sua composizione.

Volendo fare un calcolo dell'entropia, supponendo di costruire una passphrase di 6 parole:

E = L * log2 R = 6 * log2 7776 ~ 77,6

Nella password classiche basate su un alfabeto di R simboli, il mattoncino è rappresentato dal singolo carattere che ha una probabilità 1/R di essere estratto.

Con Diceware, il mattoncino è la parola che ha una probabilità su 7776 di essere estratta. Ogni parola in più, aggiunge una quantità enorme di incertezza.

Ecco perché con sole 6 parole abbiamo già una passphrase molto robusta e con 10 parole siamo di fronte ad una passphrase inattacabile, almeno dal punto di vista dell'analisi statistica (E > 129) e imperforabile anche ricorrendo ad analisi euristiche.

Regola aurea: la scelta delle parole deve essere realmente casuale e non seguire regole grammaticali o preferenze personali. Altrimenti sarà un gioco da ragazzi violarla con un approccio a-là zxcvbn.

#entropy #shannon #bruteforce #ent #zxcvbn #diceware #passphrase #PatternMatching

]]> https://noblogo.org/aytin/come-valutare-la-resistenza-di-una-password-trilogia-della-password-2-di-3 Thu, 22 Jan 2026 19:04:39 +0000 Come generare una password o un keyfile sicuri (Trilogia Della Password - 1 di 3) https://noblogo.org/aytin/come-generare-una-password-o-un-keyfile-sicuri-trilogia-della-password-1-di <![CDATA[password La generazione di una password o di un keyfile si basa sulla casualità ossia sulla capacità del sistema di generare sequenze di simboli non prevedibili. In questo contesto bisogna avere chiari 3 concetti legati fra loro: casualità, sorgente d'entropia, entropia della password. !--more-- Definizioni varie Entropia del kernel (CSPRNG) Come generare password e keyfile Analisi Valutazione Conclusione Bonus - Modalità paranoia Generazione password Generazione keyfile GPG Random Riepilogo finale 2) Keyfile binario 3) Password complessa con caratteri stampabili 5) Keyfile binario con openssl Definizioni varie Casualità In generale, posso parlare di casualità quando non riesco ad individuare un pattern o un'organizzazione deterministica in una sequenza di dati. Da un punto di vista crittografico, una sequenza è considerata "casuale" se non esiste un algoritmo che possa prevedere il bit successivo con una probabilità superiore al 50% (puro caso). Sorgente d'entropia La casualità è resa possibile dalla sorgente d'entropia che è il dispositivo o il processo fisico che genera il rumore grezzo per produrre dati casuali. È l'origine dell'incertezza e il suo grado di "purezza" è fondamentale per la produzione della casualità. Le sorgenti di entropia possono essere fisiche (TRNG) o software (PRNG). In quest'ultimo caso si parla di pseudo-casualità perché si tratta di algoritmi che espandono un seed (un seme) casuale in una sequenza anche arbitrariamente lunga che sembra casuale. Bit di entropia di una sequenza O entropia della sequenza, è la misura numerica di quanto sia imprevedibile la sequenza casuale di dati. Quindi: la sorgente di entropia è il nostro generatore di incertezza; la casualità, la cui qualità dipende totalmente dalla prima, è il processo che produce la sequenza di dati; l'entropia, in termini di bit, che è funzione della lunghezza della sequenza e del set di simboli a disposizione, è la misura di quanto la sequenza sia crittograficamente non prevedibile. Entropia del kernel (CSPRNG) Su una qualunque linuxbox il protagonista per la generazione dell'entropia necessaria è ovviamente sua maestà il kernel, che è fatto per essere anche un CSPRNG, impronunciabile acronimo che sta per Cryptographically Secure Pseudo-Random Number Generator. Il kernel infatti, già dall'avvio, raccoglie entropia (entropy harvesting), rumore casuale direttamente dall'hardware (interrupt del disco, tastiera, mouse, istruzioni CPU come RDRAND). Questi dati grezzi vengono mescolati in un serbatoio (l'entropy pool) da cui l'algoritmo (ChaCha20) pesca per espandere questi dati in un flusso infinito di dati pseudo casuali. Per avere una misura di quanta casualità abbia il sistema possiamo ricorrere al seguente costrutto: cat /proc/sys/kernel/random/entropyavail un valore da 256 in poi ci dice abbiamo entropia sufficiente per generare chiavi e quant'altro. Finita la parte di teoria, vediamo in quanti modi possiamo generare una password bella robusta o un keyfile. Come generare password e keyfile Per generare sequenze di dati casuali possiamo seguire 2 vie: attingere direttamente alla sorgente di entropia fornita dal kernel; usare la sorgente per prelevare un seme e generare la sequenza casuale via software che è la via di openssl e di pwgen. Modalità dd if=/dev/urandom of=mykey.bin bs=4096 count=1 iflag=fullblock status=none head -c 4K /dev/urandom mykey.bin tr -dc '[:graph:]' /dev/urandom | head -c 4096 mykey.txt pwgen -s 4095 1 mykey.txt openssl rand -out mykey.bin 4096 Analisi Come si comportano questi procedimenti? Proviamo ad analizzarli. Casualità Una prima distinzione va fatta sulla modalità di creazione della casualità. I primi 3 metodi fanno riferimento direttamente alla sorgente senza introdurre altre stratificazioni software. Sul piano teorico, rappresentano il punto più vicino alla casualità fisica che si possa avere su un computer. Openssl e pwgen no, sono due consumatori per /dev/urandom. Devono prima pescare un seme da /dev/urandom. Una volta ottenuto il seme, usano i propri algoritmi (quelli di openssl sono solitamente basati su AES-CTR o SHA2) per generare una sequenza infinita di numeri casuali. Pwgen fa una cosa simile ma è stato progettato di base per costruire password pronunciabili (minore entropia intrinseca). Velocità Openssl, fra tutti, è il più veloce, soprattutto se si ha l'esigenza di produrre casualità per volumi di decine di giga o di tera. Ciò è dovuto al fatto che openssl effettua pochissime syscall per prelevare il seme per poi spremere solo la cpu che, supportando quasi certamente le istruzioni hardware AES-NI, rende il processo poco impegnativo per la cpu stessa e brutalmene efficiente. Agire solo sul kernel, pur conservando la purezza della casualità, causa un rallentamento notevole dovuto al grandissimo numero di syscall necessarie e dalla corrispondente attivazione degli algoritmi di cifratura. Inoltre, mentre dd può contare su un buffer relativamente più capiente, cat, tr, head o qualuque altro oggetto che "beva" direttamente da /dev/urandom, hanno dei buffer molto più piccoli a disposizione, 1MB vs 8-16KB, il cui rapporto funge da moltiplicatore sul numero di operazioni necessarie. Sicurezza Tutti i procedimenti indicati, sono estremamente sicuri, anzi, crittograficamente sicuri. Fermo restando che vale sempre l'osservazione fatta sopra sulla metrica dell'entropia di una sequenza casuale: è funzione del set di caratteri e della lunghezza della sequenza. Conti alla mano, con un alfabeto di una settantina di caratteri, una sequenza di almeno 20 caratteri possiederà un'entropia di circa 120 bit che la rendono impenetrabile per gli attuali sistemi di calcolo. Usare direttamente la sorgente d'entropia, è sicuramente più vantaggioso perché ci fidiamo del kernel. Inoltre è più isolato perché lavora a livello del kernel dove i processi utente, anche quelli malevoli, non possono accedere alle sue zone di memoria. Openssl, pwgen e tutti quelli che sono generatori secondari, possono incorrere in quella che si diefinisce duplicazione della casualità. Se l'applicazione non è scritta bene, c'è il rischio che il processo, forkandosi, possa "duplicare" la casualità. In sostanza, i processi padre e figlio finiranno per produrre la stessa sequenza di simboli casuali. Una catastrofe. Vecchie versioni di openssl, ante 1.1.1 per es., hanno sofferto di questa anomalia. Valutazione I metodi 1,2,5 producono un keyfile di dati binari, quindi con un entropia enorme quasi vicina all'ottimo teorico. Come detto, openssl è mostruosamente più veloce. Volendo essere purista, per un keyfile i metodi 1 e 2 (praticamente equivalenti) sono da preferire. Per produrre tera di dati casuali (storage, test di rete) sicuramente openssl. Se il volume non dovesse essere esagerato e siamo paranoici, anche il metodo 1 può andare bene. Per la produzione di una password complessa con simboli stampabili (non necessariamente pronunciabile altrimenti l'entropia sarebbe ancora più bassa) il metodo 3 è da preferire da un punto di vista matematico. Mettendo da parte openssl che fa comunque un ottimo lavoro (universalmente riconosciuto con tanto di certificazioni FIPS-2), voglio spendere due parole su pwgen. pwgen, con il flag -s, crea delle sequenze completamente randomiche su un alfabeto di 62 caratteri. Se la lunghezza della sequenza è = 20, e quindi con un'entropia teorica di ~115-120, avremo delle password abbastanza inviolabili dagli attuali sistemi di calcolo. Usare il flag -y potrebbe sembrare una buona idea perché si forza ad estendere il set di caratteri. Sicuramente da una parte aumenta l'entropia della sequenza generata, visto che l'alfabeto è molto più vasto. Dall'altra però la forzatura va a compromettere l'uniformità della distribuzione casuale dei simboli. Conclusione password/keyfile stampabile: tr -dc '[:graph:]' /dev/urandom | head -c [n] mykey.txt password/keyfile binario: head -c [n] /dev/urandom mykey.bin (equivalentemente dd if=/dev/urandom of=mykey.bin bs=4096 count=1 iflag=fullblock status=none) cancellazione disco: openssl rand [dimdisco] | dd of=/dev/sdX bs=1M status=progress Bonus - Modalità paranoia Generazione password Se non ci fidassimo della sorgente di casualità, possiamo aggiungere alla sorgente di entropia un nostro segreto personale e "mescolarli" attraverso una funzione sha256 o sha512 rendendo il tutto ancora crittograficamente sicuro. (head -c 4K /dev/urandom ; read -s -p "Per aumentare l'entropia inserisci una frase segreta o premi tasti a caso: " secret) | sha512sum | cut -d' ' -f1 mykey.txt. È certamente una password molto robusta per violare la quale occorrerebbe compromettere la sorgente d'entropia e indovinare il segreto personale (N.B. stiamo facendo l'ipotesi che si provi a rompere il meccanismo di generazione della chiave non che si provi l'enumerazione attraverso un attacco brute-force). Generazione keyfile Per produrre un keyfile di 4096 bytes con la stessa premessa, faremo uso di openssl. si genera esplicitamente un seme dalla sorgente di entropia del kernel come prima, con sha2 si mescola il seme con un nostro segreto si dà in pasto ad openssl. Creiamo un seme unico mescolando /dev/urandom e il mio input con sha512 Usiamo quel seme per generare 4KB di dati casuali "espansi" (head -c 256 /dev/urandom; read -s -p "Per aumentare l'entropia inserisci una frase segreta o premi tasti a caso: " secret; echo "$secret") | sha512sum | cut -d " " -f1 | openssl enc -aes-256-ctr -pbkdf2 -pass stdin -nosalt -in /dev/zero | head -c 4096 mykey.bin L'errore che compare alla fine è un falso negativo, dovuto al fatto che openssl sta ancora provando a scrivere dati e head li tronca all'improvviso. Giusto due righe di spiegazione: head -c 256 /dev/urandom: preleva un po' di dati casuali "puri" read -sp secret: si inserisce una password, una frase o tasti schiacciati a caso per aumentare l'entropia sha512sum | cut -d " " -f1: si mescola tutto e si preleva solo l'esadecimale di 64 bytes openssl enc -aes-256-ctr -pbkdf2 -pass stdin -nosalt -in /dev/zero: openssl, che riceve il seme sullo stdin, fa la sua magia producendo un fiume di dati casuali head -c 4096: tronca il "fiume" alla lunghezza voluta per il nostro keyfile Quindi: Contro i bug del kernel: se la nostra sorgente d'entropia fosse compromessa e diventasse deterministica, occorrerebbe comunque conoscere il nostro segreto Contro il keylogging: anche se il nostro segreto potesse essere svelato, la sorgente d'entropia garantirebbe comunque l'inviolabilità della nostra password GPG Random Quando si parla di paranoia, un altro ottimo candidato per produrre password e keyfile è certamente GPG. GPG non si llimita a copiare dati da /dev/urandom ma utilizza una propria libreria crittografica chiamata Libgcrypt, che implementa un generatore di numeri pseudocasuali, crittograficamente sicuro, molto sofisticato. A differenza di ciò che abbiamo visto finora, GPG permette di impostare un livello di qualità per la casualità da produrre. livello 0 (Debole): per scopi didatti, usato raramente. livello 1 (Avanzato): adatto per chiavi di sessione e cifratura standard. Corrisponde ad una casualità di alta qualità livello 2 (Forte): utilizzato per le chiavi a lungo termine (le chiavi private di GPG). È un livello estremamente conservativo. Se GPG valuta di non avere entropia sufficientemente fresca, si mette in attesa. GPG non si fida ciecamente del kernel e così Libgcrypt crea un proprio pool di entropia in user space. Libgcrypt pesca al solito un seme da /dev/urandom il seme viene rimescolato con sha2 o aes per evitare che i dati casuali finiscano sullo swap, libgcrypt usa pagine di memoria protetta (mlock) Impostando il livello 2, libgcrypt può decidere di scartare molti più dati se ritiene che il pool di entropia non sia abbastanza "fresco". Inoltre, in virtù della sua diffidenza, non consegna mai tutto ciò che arriva dal pool di entropia del kernel così come viene, ma viene rimescolato con sha2 o simili e al livello 2 tutto questo, oltre che avvenire con molta più intensità, avviene anche con molta più frequenza (GPG "chiede" spesso bit freschi al kernel) per scongiurare l'eventualità che un attaccante possa prevedere i bit successivi basandosi su quelli passati Inoltre, GPG salva una parte di questa entropia "pregiata" in ~/.gnupg/randomseed per avere una base di casualità sicura dalle sessioni precedenti nel caso in cui un computer, appena avviato, non avesse ancora accumulato sufficiente entropia. Si capisce bene come il livello di paranoia di GPG sia fuori scala ma per fortuna tutta questa potenza è totalmente nascosta sotto il cofano di GPG. Infatti per produrre il nostro keyfile binario basta: gpg --dev-random 2 4096 Riepilogo finale E dunque, 3 delle 5 modalità sopra descritte, la 2, la 3 e la 5, possono essere ripensate con l'entropia di GPG invee che con quella tipica del kernel. 2) Keyfile binario Kernel entropy head -c 4K /dev/urandom mykey.bin Libgcrypt entropy gpg --dev-random 2 4096 -o mykeygpg.bin 3) Password complessa con caratteri stampabili Kernel entropy tr -dc '[:graph:]' /dev/urandom | head -c 4096 mykey.txt Libgcrypt entropy gpg --gen-random 1 10000 | tr -dc 'A-Za-z0-9' | head -c 4096 mykeygpg.txt 5) Keyfile binario con openssl Kernel entropy openssl rand -out mykey.bin 4096 Libgcrypt entropy (gpg --gen-random 2 128) | openssl rand -out mykey_gpg.bin -rand /dev/stdin 4096 #entropy #shannon #csprng #password #keyfile #dd #openssl #pwgen #AesCtr #AesNi #sha2 #gpg #bruteforce]]> password

La generazione di una password o di un keyfile si basa sulla casualità ossia sulla capacità del sistema di generare sequenze di simboli non prevedibili. In questo contesto bisogna avere chiari 3 concetti legati fra loro: casualità, sorgente d'entropia, entropia della password.

Definizioni varie

Casualità In generale, posso parlare di casualità quando non riesco ad individuare un pattern o un'organizzazione deterministica in una sequenza di dati.

Da un punto di vista crittografico, una sequenza è considerata “casuale” se non esiste un algoritmo che possa prevedere il bit successivo con una probabilità superiore al 50% (puro caso).

Sorgente d'entropia La casualità è resa possibile dalla sorgente d'entropia che è il dispositivo o il processo fisico che genera il rumore grezzo per produrre dati casuali. È l'origine dell'incertezza e il suo grado di “purezza” è fondamentale per la produzione della casualità.

Le sorgenti di entropia possono essere fisiche (TRNG) o software (PRNG). In quest'ultimo caso si parla di pseudo-casualità perché si tratta di algoritmi che espandono un seed (un seme) casuale in una sequenza anche arbitrariamente lunga che sembra casuale.

Bit di entropia di una sequenza O entropia della sequenza, è la misura numerica di quanto sia imprevedibile la sequenza casuale di dati.

Quindi:

  • la sorgente di entropia è il nostro generatore di incertezza;
  • la casualità, la cui qualità dipende totalmente dalla prima, è il processo che produce la sequenza di dati;
  • l'entropia, in termini di bit, che è funzione della lunghezza della sequenza e del set di simboli a disposizione, è la misura di quanto la sequenza sia crittograficamente non prevedibile.

Entropia del kernel (CSPRNG)

Su una qualunque linuxbox il protagonista per la generazione dell'entropia necessaria è ovviamente sua maestà il kernel, che è fatto per essere anche un CSPRNG, impronunciabile acronimo che sta per Cryptographically Secure Pseudo-Random Number Generator.

Il kernel infatti, già dall'avvio, raccoglie entropia (entropy harvesting), rumore casuale direttamente dall'hardware (interrupt del disco, tastiera, mouse, istruzioni CPU come RDRAND). Questi dati grezzi vengono mescolati in un serbatoio (l'entropy pool) da cui l'algoritmo (ChaCha20) pesca per espandere questi dati in un flusso infinito di dati pseudo casuali.

Per avere una misura di quanta casualità abbia il sistema possiamo ricorrere al seguente costrutto:

cat /proc/sys/kernel/random/entropy_avail

un valore da 256 in poi ci dice abbiamo entropia sufficiente per generare chiavi e quant'altro.

Finita la parte di teoria, vediamo in quanti modi possiamo generare una password bella robusta o un keyfile.

Come generare password e keyfile

Per generare sequenze di dati casuali possiamo seguire 2 vie:

  1. attingere direttamente alla sorgente di entropia fornita dal kernel;
  2. usare la sorgente per prelevare un seme e generare la sequenza casuale via software che è la via di openssl e di pwgen.

Modalità

  1. dd if=/dev/urandom of=mykey.bin bs=4096 count=1 iflag=fullblock status=none
  2. head -c 4K /dev/urandom > mykey.bin
  3. tr -dc '[:graph:]' < /dev/urandom | head -c 4096 > mykey.txt
  4. pwgen -s 4095 1 > mykey.txt
  5. openssl rand -out mykey.bin 4096

Analisi

Come si comportano questi procedimenti? Proviamo ad analizzarli.

Casualità Una prima distinzione va fatta sulla modalità di creazione della casualità.

I primi 3 metodi fanno riferimento direttamente alla sorgente senza introdurre altre stratificazioni software. Sul piano teorico, rappresentano il punto più vicino alla casualità fisica che si possa avere su un computer.

Openssl e pwgen no, sono due consumatori per /dev/urandom. Devono prima pescare un seme da /dev/urandom. Una volta ottenuto il seme, usano i propri algoritmi (quelli di openssl sono solitamente basati su AES-CTR o SHA2) per generare una sequenza infinita di numeri casuali. Pwgen fa una cosa simile ma è stato progettato di base per costruire password pronunciabili (minore entropia intrinseca).

Velocità Openssl, fra tutti, è il più veloce, soprattutto se si ha l'esigenza di produrre casualità per volumi di decine di giga o di tera. Ciò è dovuto al fatto che openssl effettua pochissime syscall per prelevare il seme per poi spremere solo la cpu che, supportando quasi certamente le istruzioni hardware AES-NI, rende il processo poco impegnativo per la cpu stessa e brutalmene efficiente. Agire solo sul kernel, pur conservando la purezza della casualità, causa un rallentamento notevole dovuto al grandissimo numero di syscall necessarie e dalla corrispondente attivazione degli algoritmi di cifratura. Inoltre, mentre dd può contare su un buffer relativamente più capiente, cat, tr, head o qualuque altro oggetto che “beva” direttamente da /dev/urandom, hanno dei buffer molto più piccoli a disposizione, 1MB vs 8-16KB, il cui rapporto funge da moltiplicatore sul numero di operazioni necessarie.

Sicurezza Tutti i procedimenti indicati, sono estremamente sicuri, anzi, crittograficamente sicuri. Fermo restando che vale sempre l'osservazione fatta sopra sulla metrica dell'entropia di una sequenza casuale: è funzione del set di caratteri e della lunghezza della sequenza. Conti alla mano, con un alfabeto di una settantina di caratteri, una sequenza di almeno 20 caratteri possiederà un'entropia di circa 120 bit che la rendono impenetrabile per gli attuali sistemi di calcolo.

Usare direttamente la sorgente d'entropia, è sicuramente più vantaggioso perché ci fidiamo del kernel. Inoltre è più isolato perché lavora a livello del kernel dove i processi utente, anche quelli malevoli, non possono accedere alle sue zone di memoria.

Openssl, pwgen e tutti quelli che sono generatori secondari, possono incorrere in quella che si diefinisce duplicazione della casualità. Se l'applicazione non è scritta bene, c'è il rischio che il processo, forkandosi, possa “duplicare” la casualità. In sostanza, i processi padre e figlio finiranno per produrre la stessa sequenza di simboli casuali. Una catastrofe. Vecchie versioni di openssl, ante 1.1.1 per es., hanno sofferto di questa anomalia.

Valutazione

I metodi 1,2,5 producono un keyfile di dati binari, quindi con un entropia enorme quasi vicina all'ottimo teorico. Come detto, openssl è mostruosamente più veloce.

Volendo essere purista, per un keyfile i metodi 1 e 2 (praticamente equivalenti) sono da preferire. Per produrre tera di dati casuali (storage, test di rete) sicuramente openssl. Se il volume non dovesse essere esagerato e siamo paranoici, anche il metodo 1 può andare bene.

Per la produzione di una password complessa con simboli stampabili (non necessariamente pronunciabile altrimenti l'entropia sarebbe ancora più bassa) il metodo 3 è da preferire da un punto di vista matematico.

Mettendo da parte openssl che fa comunque un ottimo lavoro (universalmente riconosciuto con tanto di certificazioni FIPS-2), voglio spendere due parole su pwgen. pwgen, con il flag -s, crea delle sequenze completamente randomiche su un alfabeto di 62 caratteri. Se la lunghezza della sequenza è >= 20, e quindi con un'entropia teorica di ~115-120, avremo delle password abbastanza inviolabili dagli attuali sistemi di calcolo. Usare il flag -y potrebbe sembrare una buona idea perché si forza ad estendere il set di caratteri. Sicuramente da una parte aumenta l'entropia della sequenza generata, visto che l'alfabeto è molto più vasto. Dall'altra però la forzatura va a compromettere l'uniformità della distribuzione casuale dei simboli.

Conclusione

  1. password/keyfile stampabile: tr -dc '[:graph:]' < /dev/urandom | head -c [n] > mykey.txt
  2. password/keyfile binario: head -c [n] /dev/urandom > mykey.bin (equivalentemente dd if=/dev/urandom of=mykey.bin bs=4096 count=1 iflag=fullblock status=none)
  3. cancellazione disco: openssl rand [dim_disco] | dd of=/dev/sdX bs=1M status=progress

Bonus – Modalità paranoia

Generazione password

Se non ci fidassimo della sorgente di casualità, possiamo aggiungere alla sorgente di entropia un nostro segreto personale e “mescolarli” attraverso una funzione sha256 o sha512 rendendo il tutto ancora crittograficamente sicuro.

(head -c 4K /dev/urandom ; read -s -p "Per aumentare l'entropia inserisci una frase segreta o premi tasti a caso: " secret) | sha512sum | cut -d' ' -f1 > mykey.txt.

È certamente una password molto robusta per violare la quale occorrerebbe compromettere la sorgente d'entropia e indovinare il segreto personale (N.B. stiamo facendo l'ipotesi che si provi a rompere il meccanismo di generazione della chiave non che si provi l'enumerazione attraverso un attacco brute-force).

Generazione keyfile

Per produrre un keyfile di 4096 bytes con la stessa premessa, faremo uso di openssl.

  1. si genera esplicitamente un seme dalla sorgente di entropia del kernel
  2. come prima, con sha2 si mescola il seme con un nostro segreto
  3. si dà in pasto ad openssl.
# Creiamo un seme unico mescolando /dev/urandom e il mio input con sha512
# Usiamo quel seme per generare 4KB di dati casuali "espansi"
(head -c 256 /dev/urandom; read -s -p "Per aumentare l'entropia inserisci una frase segreta o premi tasti a caso: " secret; echo "$secret") | sha512sum | cut -d " " -f1 | openssl enc -aes-256-ctr -pbkdf2 -pass stdin -nosalt -in /dev/zero | head -c 4096 > mykey.bin

L'errore che compare alla fine è un falso negativo, dovuto al fatto che openssl sta ancora provando a scrivere dati e head li tronca all'improvviso.

Giusto due righe di spiegazione:

  1. head -c 256 /dev/urandom: preleva un po' di dati casuali “puri”
  2. read -sp secret: si inserisce una password, una frase o tasti schiacciati a caso per aumentare l'entropia
  3. sha512sum | cut -d " " -f1: si mescola tutto e si preleva solo l'esadecimale di 64 bytes
  4. openssl enc -aes-256-ctr -pbkdf2 -pass stdin -nosalt -in /dev/zero: openssl, che riceve il seme sullo stdin, fa la sua magia producendo un fiume di dati casuali
  5. head -c 4096: tronca il “fiume” alla lunghezza voluta per il nostro keyfile

Quindi:

  1. Contro i bug del kernel: se la nostra sorgente d'entropia fosse compromessa e diventasse deterministica, occorrerebbe comunque conoscere il nostro segreto
  2. Contro il keylogging: anche se il nostro segreto potesse essere svelato, la sorgente d'entropia garantirebbe comunque l'inviolabilità della nostra password

GPG Random

Quando si parla di paranoia, un altro ottimo candidato per produrre password e keyfile è certamente GPG. GPG non si llimita a copiare dati da /dev/urandom ma utilizza una propria libreria crittografica chiamata Libgcrypt, che implementa un generatore di numeri pseudocasuali, crittograficamente sicuro, molto sofisticato.

A differenza di ciò che abbiamo visto finora, GPG permette di impostare un livello di qualità per la casualità da produrre.

  1. livello 0 (Debole): per scopi didatti, usato raramente.
  2. livello 1 (Avanzato): adatto per chiavi di sessione e cifratura standard. Corrisponde ad una casualità di alta qualità
  3. livello 2 (Forte): utilizzato per le chiavi a lungo termine (le chiavi private di GPG). È un livello estremamente conservativo. Se GPG valuta di non avere entropia sufficientemente fresca, si mette in attesa.

GPG non si fida ciecamente del kernel e così Libgcrypt crea un proprio pool di entropia in user space.

  1. Libgcrypt pesca al solito un seme da /dev/urandom
  2. il seme viene rimescolato con sha2 o aes
  3. per evitare che i dati casuali finiscano sullo swap, libgcrypt usa pagine di memoria protetta (mlock)

Impostando il livello 2, libgcrypt può decidere di scartare molti più dati se ritiene che il pool di entropia non sia abbastanza “fresco”. Inoltre, in virtù della sua diffidenza, non consegna mai tutto ciò che arriva dal pool di entropia del kernel così come viene, ma viene rimescolato con sha2 o simili e al livello 2 tutto questo, oltre che avvenire con molta più intensità, avviene anche con molta più frequenza (GPG “chiede” spesso bit freschi al kernel) per scongiurare l'eventualità che un attaccante possa prevedere i bit successivi basandosi su quelli passati

Inoltre, GPG salva una parte di questa entropia “pregiata” in ~/.gnupg/random_seed per avere una base di casualità sicura dalle sessioni precedenti nel caso in cui un computer, appena avviato, non avesse ancora accumulato sufficiente entropia.

Si capisce bene come il livello di paranoia di GPG sia fuori scala ma per fortuna tutta questa potenza è totalmente nascosta sotto il cofano di GPG. Infatti per produrre il nostro keyfile binario basta:

gpg --dev-random 2 4096

Riepilogo finale

E dunque, 3 delle 5 modalità sopra descritte, la 2, la 3 e la 5, possono essere ripensate con l'entropia di GPG invee che con quella tipica del kernel.

2) Keyfile binario

  • Kernel entropy

    head -c 4K /dev/urandom > mykey.bin

  • Libgcrypt entropy

    gpg --dev-random 2 4096 -o mykey_gpg.bin

3) Password complessa con caratteri stampabili

  • Kernel entropy

    tr -dc '[:graph:]' < /dev/urandom | head -c 4096 > mykey.txt

  • Libgcrypt entropy

    gpg --gen-random 1 10000 | tr -dc 'A-Za-z0-9' | head -c 4096 > mykey_gpg.txt

5) Keyfile binario con openssl

  • Kernel entropy

    openssl rand -out mykey.bin 4096

  • Libgcrypt entropy

    (gpg --gen-random 2 128) | openssl rand -out mykey_gpg.bin -rand /dev/stdin 4096

#entropy #shannon #csprng #password #keyfile #dd #openssl #pwgen #AesCtr #AesNi #sha2 #gpg #bruteforce

]]> https://noblogo.org/aytin/come-generare-una-password-o-un-keyfile-sicuri-trilogia-della-password-1-di Mon, 12 Jan 2026 14:39:55 +0000 Cifrare directory con gocryptfs https://noblogo.org/aytin/come-cifrare-file-e-directory-con-gocryptfs <![CDATA[gocryptfs Encfs è stata per tanto tempo la mia soluzione preferita per conservare velocemente i dati che volevo tenere riservati su uno storage esterno o su un cloud storage. Almeno fino al 2014 quando encfs è risultato estremamente fragile. Alcuni buchi sono stati coperti ma altri no, con la promessa che l'eventuale 2.0 avrebbe risolto tutti i problemi. !--more-- "Eventuale" perché lo sviluppo s'è fermato e lo stesso manteiner consiglia di ricorrere ad altre soluzioni più valide. Come gocryptfs (https://github.com/vgough/encfs?tab=readme-ov-file#status), appunto. Come EncFS e i suoi omologhi (cryfs, eCryptfs), gocryptfs è uno "stackable filesystem". Ma cos'è uno stackable filesystem? Analogamente a device mapper, il framework che fornisce funzionalità aggiuntive (cifratura, volumi logici, raid) ai dispositivi a blocchi a livello del kernel, gli stackable filesystem sono file system "impilati" (e non poteva essere altrimenti) sopra un altro file system per fornire funzionalità aggiuntive (cifratura, viste in lettura e/o scrittura) a livello di file/directory nello spazio utente grazie a FUSE. Essendo complementari, device mapper e stackable filesystem possono dunque cooperare. Ecco perché posso avere: due dischi fisici (block device) che divido in volumi logici (device mapper), ognuno dei quali formattato in ext4 (il file system) a cui aggiungo funzionalità di cifratura con gocryptfs (stackable filesystem) Un altro celebre stackable filesystem è quello di tipo "unionale" nelle sue varie declinazioni come unionfs prima, aufs poi, per finire a overlayfs, lo standard in ambito container per la manipolazione delle immagini. Gocryptfs: è facile da usare è in pieno sviluppo non ha i problemi stringenti di sicurezza del suo "collega" è tuttavia suscettibile ad attacchi statistici e di watermarking strutturale (effettuato sui metadati, come la dimensione dei file e la struttura delle directory) by design Su una cifratura file-based, raggiungere la triangolazione perfetta fra performance, full-privacy e ottimizzazione dello spazio, è quasi impossibile. Gocryptfs non è l'optimum ma costituisce una valida alternativa ad EncFS, avendo dalla sua la stessa facilità d'uso, maggior robustezza (l'uso di AES-GCM impedisce di rompere matematicamente la cifratura dei dati, come invece succedeva su EncFS) e, come EncFS, ha ottime performance. Anche Gocryptfs prevede due modalità distinte di funzionamento: forward mode e reverse mode Nella prima, si battezza la directory che conterrà tutto ciò che vorrò cifrare. Localmente avrò un punto di montaggio su cui depositare i file in chiaro che verranno cifrati e memorizzati on-fly. Nel secondo caso, ribalto i termini della cifratura. Battezzerò una directory in chiaro il cui punto di montaggio sarà una directory che fornirà al volo i file cifrati. La prima modalità è comoda per la sincronizzazione su storage esterni o su cloud storage. La seconda, dal momento che può fornire una vista cifrata di qualunque cartella, è utile quando si vuole effettuare velocemente un backup cifrato dei propri file !!! Attenzione !!! Come tutte le crittografie file-based suscettibili di attacchi di tipo statistico e watermarking strutturale, nel caso del reverse mode, il watermarking diventa ancora più insidioso perché, dovendo funzionare presumibilmente con strumenti tipo rsync per il backup, il reverse mode di gocryptfs fa uso di un algoritmo, AES-SIV, deterministico per design cosi che lo stesso file, cifrato due volte, possa produrre lo stesso, identico risultato. Comodo per rsync ma un paradiso per il watermarking. Tuttavia, anche così risulta più robusto di EncFS perché è una vulnerabilità che, a differenza del primo, non rompe matematicamente la cifratura esponendo il testo in chiaro pur consentendo attacchi di watermarking passivo per la rilevabilità dei file. Prove sul campo Gocryptfs, nella fase di inizializzazione, crea il file gocryptfs.conf contenente la password cifrata ed altri elementi di configurazione. In Forward Mode, tale file è situato nella root della directory cifrata, quella che presumibilmente finirà nello storage esterno/cloud. Forward mode classico 1. Inizializzazione: creazione della directory cifrata e della directory in chiaro mkdir $HOME/{cipherdir,plaindir} inizializzazione della cartella cifrata gocryptfs -init $HOME/cipherdir Choose a password for protecting your files. Password: Repeat: Your master key is: 93499318-58f766af-6a172304-114cab2c- 7e9d6a6e-48f38c7a-b00a8e04-3b2e0583 If the gocryptfs.conf file becomes corrupted or you ever forget your password, there is only one hope for recovery: The master key. Print it to a piece of paper and store it in a drawer. This message is only printed once. The gocryptfs filesystem has been created successfully. You can now mount it using: gocryptfs cipherdir MOUNTPOINT Nella fase di inizializzazione viene generata una master key cifrata con una password che verrà chiesta durante la fase di init e che finirà nel file di configurazione gocryptfs.conf situato di default nella cartella cifrata. small N.B. È bene conservare la master key in un luogo sicuro perché, in caso di malfunzionamenti, potrebbe essere l'unico modo di recuperare la visibilità della cartella cifrata /small 2. Mount: gocryptfs cipherdir plaindir Nella fase di mount, viene chiesta la password, gocryptfs legge il file di configurazione e decripta la master key che servirà per la cifratura dei file presenti nel mountpoint in chiaro e che verranno cifrati al volo e scritti nella cartella cifrata. 3. Unmount: fusermount -u plaindir Nella fase di unmount si "libera" il mountpoint lasciando la sola cartella cifrata. small Note: Occorre prestare attenzione al file gocryptfs.conf. Visto che contiene la master key cifrata, senza questo file la decifratura sarebbe impossibile. Come suggerito durante la fase di inizializzazione, è bene conservare la master key così che, nel caso si perda o si corrompa il file gocryptfs.conf, sia possibile rigenerarlo con la master key. /small Forward Mode su cloud storage (es. Dropbox) In questo caso, sia il file di configurazione contenente la master key cifrata che la password di decifratura, saranno allocate esternamente alla directory cifrata su Dropbox. In questo modo, anche guadagnando l'accesso al clud storage, ci sarebbero solo dei file cifrati senza avere nemmeno la possibilità di tentare attacchi di forza bruta sulla master key cifrata. Visto che la password sarà scritta su un file, e non avrò bisogno di ricordarla a memoria, verrà generata ricorrendo al generatore di pseudo-casualità del kernel /dev/urandom e sarà lunga il massimo consentito, 2048 bytes. 1. Inizializzazione creazione della directory cifrata e della directory in chiaro mkdir $HOME/Dropbox/.cipherdir $HOME/plaindir creazione di un keyfile di 2k (la massima lunghezza possibile) umask 077 && tr -dc '[:graph:]' /dev/urandom | head -c 2048 /run/media/$USER/pendrive/mykey.txt inizializzazione della cartella cifrata gocryptfs \ -passfile /run/media/$USER/pendrive/mykey.txt \ -config /run/media/$USER/pendrive/gocryptfs.conf \ -init $HOME/Dropbox/.cipherdir Using config file at custom location /run/media/$USER/pendrive/gocryptfs.conf Choose a password for protecting your files. passfile: reading from file "/run/media/$USER/pendrive/mykey.txt" Your master key is: dcceb426-75724350-f53566f6-2991cfa9- 7a091a4f-397eab55-170c3363-a16b0ab3 If the gocryptfs.conf file becomes corrupted or you ever forget your password, there is only one hope for recovery: The master key. Print it to a piece of paper and store it in a drawer. This message is only printed once. The gocryptfs filesystem has been created successfully. You can now mount it using: gocryptfs cipherdir MOUNTPOINT 2. Mount gocryptfs \ -config /run/media/$USER/pendrive/gocryptfs.conf \ -passfile /run/media/$USER/pendrive/mykey.txt $HOME/Dropbox/.cipherdir $HOME/plaindir 3. Unmount fusermount -u $HOME/plaindir Reverse mode Questa modalità torna utile quando si vuole offrire al volo una vista cifrata di una determinata directory, ad es. quando vogliamo fare un backup cifrato. Supponiamo di volere effettuare un backup cifrato della directory "myDocuments" 1. Inizializzazione gocryptfs -init -reverse $HOME/myDocuments Choose a password for protecting your files. Password: Repeat: Your master key is: cda5cac4-5435e8e8-68d6d038-451a6955- c269c57c-d8b5fe5e-4d5ca589-4eb5e7ac If the gocryptfs.conf file becomes corrupted or you ever forget your password, there is only one hope for recovery: The master key. Print it to a piece of paper and store it in a drawer. This message is only printed once. The gocryptfs-reverse filesystem has been created successfully. You can now mount it using: gocryptfs -reverse plaindir MOUNTPOINT Nella directory "myDocuments" sarà presente il file di configurazione, di default .gocryptfs.reverse.conf 2. Mount mkdir $HOME/cipherdirreverse gocryptfs -reverse $HOME/myDocuments $HOME/cipherdirreverse Dopo il mount, il file .gocryptfs.reverse.conf verrà "copiato" nel punto di montaggio come gocryptfs.conf in modo che il backup possa essere montato direttamente in forward mode. 3. Unmont fusermount -u $HOME/cipherdirreverse Nulla vieta che anche nel reverse mode si possa ricorrere a password e file di configurazione "detachable". gocryptfs \ -passfile /run/media/$USER/pendrive/mykey.txt \ -config /run/media/$USER/pendrive/gocryptfs.reverse.conf \ -init -reverse $HOME/myDocuments smallN.B. In questo caso anche il backup avrà bisogno del file di configurazione e della password per essere montato./small Varie ed eventuali Cambio password Supponiamo di voler cambiare la password (keyfile) della nostra directory cifrata su Dropbox gocryptfs \ -config /run/media/$USER/pendrive/gocryptfs.conf -passfile /run/media/$USER/pendrive/mykey.txt -passwd $HOME/Dropbox/.cipherdir Using config file at custom location /run/media/$USER/pendrive/gocryptfs.conf Password: Decrypting master key Please enter your new password. Password: Repeat: smallN.B. Non è possibile specificare un keyfile come nuova password (possibile solo durante l'init). Il keyfile in questo caso servirà solo a decriptare la master key che verrà cifrata con la nuova password./small Mount automatico Nel caso di forward mode, può tornare comodo il mount automatico della directory cifrata. È sufficiente definire un piccolo script che esegua il montaggio e che parta in esecuzione automatica dopo il login. Due osservazioni: Conviene che la password sia stoccata nel keyring (di Gnome nel mio caso) così da rendere la password inaccessibile senza il login. il file di configurazione può continuare a rimanere al di fuori della directory cifrata (soprattutto nel caso cloud storage) purché sia accessibile dopo il login. 1. Generazione password suppongo che la password sia stata generata come in forward mode e che stia in un file di testo che ora memorizzerò nel keyring con secret-tool cat mykey.txt | secret-tool store --label="gocryptfs" myCipherDir myPassword 2. Creazione script cat $HOME/mountgocryptfs.sh << EOF !/bin/bash gocryptfs \ -config $HOME/gocryptfs.conf \ -extpass="secret-tool lookup myCipherDir myPassword" \ $HOME/Dropbox/.cipherdir $HOME/plaindir EOF chmod 700 $HOME/mountgocryptfs.sh 3. Creazione del launcher cat $HOME/.config/autostart/mountGocryptfs.desktop << EOF [Desktop Entry] Name=mountgocryptfs GenericName=mountgocryptfs Comment=Monta la cartella cifrata con gocryptfs Exec=/home/user/mountgocryptfs.sh Terminal=false Type=Application X-GNOME-Autostart-enabled=true Comment[itIT]= EOF In questo modo, dopo il login, verrà eseguito lo script (grazie a $HOME/.config/autostart/) che recupererà la password via secret-tool dal keyring. Rigenerazione del file gocryptfs.conf Ma se smarrissi il file gocryptfs.conf, o mi si corrompe il supporto esterno che lo contiene? O se dimenticassi / perdessi la password? È un grosso guaio. La directory cifrata non sarà più accessibile. O meglio. Lo sarà solo avendo la master key. E con questa possiamo, non solo montare la directory cifrata, ma anche ricostruire il file di configurazione. Innanzitutto verifichiamo se l'accesso diretto con la master key funzioni: Accesso con la master key gocryptfs \ -masterkey dcceb426-75724350-f53566f6-2991cfa9-7a091a4f-397eab55-170c3363-a16b0ab3 \ $HOME/Dropbox/.cipherdir $HOME/plaindir Using explicit master key. THE MASTER KEY IS VISIBLE VIA "ps ax" AND MAY BE STORED IN YOUR SHELL HISTORY! ONLY USE THIS MODE FOR EMERGENCIES Filesystem mounted and ready. Per evitare il warning, si può ricorrere al flag stdin che obbliga all'inserimento manuale da tastiera della master key: gocryptfs -masterkey stdin $HOME/Dropbox/.cipherdir $HOME/plaindir Masterkey: Using explicit master key. Filesystem mounted and ready. Caso 1: Smarrimento password Se è solo la password, basterà accedere alla directory cifrata con la master key usando lo stesso file di configurazone e inserire una nuova password: Cambio password gocryptfs \Inserimento -masterkey dcceb426-75724350-f53566f6-2991cfa9-7a091a4f-397eab55-170c3363-a16b0ab3 \ -config /run/media/$USER/pendrive/gocryptfs.conf \ -passwd $HOME/Dropbox/.cipherdir Using config file at custom location /run/media/$USER/pendrive/gocryptfs.conf Using explicit master key. THE MASTER KEY IS VISIBLE VIA "ps ax" AND MAY BE STORED IN YOUR SHELL HISTORY! ONLY USE THIS MODE FOR EMERGENCIES Please enter your new password. Password: Repeat: A copy of the old config file has been created at "/run/media/$USER/pendrive/gocryptfs.conf.bak". Delete it after you have verified that you can access your files with the new password. Password changed. smallN.B. Siccome il file di configurazione verrà modificato con un nuovo salt e una nuova password, del file di configurazione verrà fatta una copia di backup precauzionale,/small Caso 2: Ricostruzione file di configurazione È praticamente lo stesso procedimentod di prima solo che in questo caso occorre ricostruire il file di configurazione. Si ricrea un file di configurazione con -init avente cura di replicare le stesse impostazioni di quello compromesso (nel mio caso è semplice, tutto default) su una directory cifrata temporanea il file di configurazione così ottenuto, si sposta nella directory cifrata effettiva e si imposta la nuova password inizializzo una directory cifrata temporanea gocryptfs -init $HOME/ciphertemp Sposto il nuovo file di configurazione dalla directory temporanea cifrata al punto in cui si trovava in precedenza (la nostra nuova pendrive) mv $HOME/ciphertemp/gocryptfs.conf /run/media/$USER/nuovapendrive/gocryptfs.conf Inserimento password gocryptfs \ -masterkey dcceb426-75724350-f53566f6-2991cfa9-7a091a4f-397eab55-170c3363-a16b0ab3 \ -config /run/media/$USER/nuovapendrive/gocryptfs.conf \ -passwd $HOME/Dropbox/.cipherdir Using config file at custom location /run/media/$USER/nuovapendrive/gocryptfs.conf Using explicit master key. THE MASTER KEY IS VISIBLE VIA "ps ax" AND MAY BE STORED IN YOUR SHELL HISTORY! ONLY USE THIS MODE FOR EMERGENCIES Please enter your new password. Password: Repeat: A copy of the old config file has been created at "/run/media/$USER/nuovapendrive/gocryptfs.conf.bak". Delete it after you have verified that you can access your files with the new password. Password changed. E ora il volume può essere montato nuovamente. ]]> gocryptfs

Encfs è stata per tanto tempo la mia soluzione preferita per conservare velocemente i dati che volevo tenere riservati su uno storage esterno o su un cloud storage.

Almeno fino al 2014 quando encfs è risultato estremamente fragile. Alcuni buchi sono stati coperti ma altri no, con la promessa che l'eventuale 2.0 avrebbe risolto tutti i problemi. “Eventuale” perché lo sviluppo s'è fermato e lo stesso manteiner consiglia di ricorrere ad altre soluzioni più valide. Come gocryptfs (https://github.com/vgough/encfs?tab=readme-ov-file#status), appunto.

Come EncFS e i suoi omologhi (cryfs, eCryptfs), gocryptfs è uno “stackable filesystem”.

Ma cos'è uno stackable filesystem?

Analogamente a device mapper, il framework che fornisce funzionalità aggiuntive (cifratura, volumi logici, raid) ai dispositivi a blocchi a livello del kernel, gli stackable filesystem sono file system “impilati” (e non poteva essere altrimenti) sopra un altro file system per fornire funzionalità aggiuntive (cifratura, viste in lettura e/o scrittura) a livello di file/directory nello spazio utente grazie a FUSE.

Essendo complementari, device mapper e stackable filesystem possono dunque cooperare.

Ecco perché posso avere:

  • due dischi fisici (block device)
  • che divido in volumi logici (device mapper),
  • ognuno dei quali formattato in ext4 (il file system)
  • a cui aggiungo funzionalità di cifratura con gocryptfs (stackable filesystem)

Un altro celebre stackable filesystem è quello di tipo “unionale” nelle sue varie declinazioni come unionfs prima, aufs poi, per finire a overlayfs, lo standard in ambito container per la manipolazione delle immagini.

Gocryptfs:

  • è facile da usare
  • è in pieno sviluppo
  • non ha i problemi stringenti di sicurezza del suo “collega”
  • è tuttavia suscettibile ad attacchi statistici e di watermarking strutturale (effettuato sui metadati, come la dimensione dei file e la struttura delle directory) by design

Su una cifratura file-based, raggiungere la triangolazione perfetta fra performance, full-privacy e ottimizzazione dello spazio, è quasi impossibile.

Gocryptfs non è l'optimum ma costituisce una valida alternativa ad EncFS, avendo dalla sua la stessa facilità d'uso, maggior robustezza (l'uso di AES-GCM impedisce di rompere matematicamente la cifratura dei dati, come invece succedeva su EncFS) e, come EncFS, ha ottime performance.

Anche Gocryptfs prevede due modalità distinte di funzionamento: forward mode e reverse mode

Nella prima, si battezza la directory che conterrà tutto ciò che vorrò cifrare. Localmente avrò un punto di montaggio su cui depositare i file in chiaro che verranno cifrati e memorizzati on-fly.

Nel secondo caso, ribalto i termini della cifratura. Battezzerò una directory in chiaro il cui punto di montaggio sarà una directory che fornirà al volo i file cifrati.

La prima modalità è comoda per la sincronizzazione su storage esterni o su cloud storage. La seconda, dal momento che può fornire una vista cifrata di qualunque cartella, è utile quando si vuole effettuare velocemente un backup cifrato dei propri file

!!! Attenzione !!! Come tutte le crittografie file-based suscettibili di attacchi di tipo statistico e watermarking strutturale, nel caso del reverse mode, il watermarking diventa ancora più insidioso perché, dovendo funzionare presumibilmente con strumenti tipo rsync per il backup, il reverse mode di gocryptfs fa uso di un algoritmo, AES-SIV, deterministico per design cosi che lo stesso file, cifrato due volte, possa produrre lo stesso, identico risultato. Comodo per rsync ma un paradiso per il watermarking. Tuttavia, anche così risulta più robusto di EncFS perché è una vulnerabilità che, a differenza del primo, non rompe matematicamente la cifratura esponendo il testo in chiaro pur consentendo attacchi di watermarking passivo per la rilevabilità dei file.

Prove sul campo

Gocryptfs, nella fase di inizializzazione, crea il file gocryptfs.conf contenente la password cifrata ed altri elementi di configurazione.

In Forward Mode, tale file è situato nella root della directory cifrata, quella che presumibilmente finirà nello storage esterno/cloud.

Forward mode classico

1. Inizializzazione:

# creazione della directory cifrata e della directory in chiaro
mkdir $HOME/{cipherdir,plaindir}

# inizializzazione della cartella cifrata
gocryptfs -init $HOME/cipherdir

Choose a password for protecting your files.
Password: 
Repeat: 

Your master key is:

    93499318-58f766af-6a172304-114cab2c-
    7e9d6a6e-48f38c7a-b00a8e04-3b2e0583

If the gocryptfs.conf file becomes corrupted or you ever forget your password, there is only one hope for recovery: The master key. Print it to a piece of paper and store it in a drawer. This message is only printed once.
The gocryptfs filesystem has been created successfully.
You can now mount it using: gocryptfs cipherdir MOUNTPOINT

Nella fase di inizializzazione viene generata una master key cifrata con una password che verrà chiesta durante la fase di init e che finirà nel file di configurazione gocryptfs.conf situato di default nella cartella cifrata.

N.B. È bene conservare la master key in un luogo sicuro perché, in caso di malfunzionamenti, potrebbe essere l'unico modo di recuperare la visibilità della cartella cifrata

2. Mount:

gocryptfs cipherdir plaindir

Nella fase di mount, viene chiesta la password, gocryptfs legge il file di configurazione e decripta la master key che servirà per la cifratura dei file presenti nel mountpoint in chiaro e che verranno cifrati al volo e scritti nella cartella cifrata.

3. Unmount:

fusermount -u plaindir

Nella fase di unmount si “libera” il mountpoint lasciando la sola cartella cifrata.

Note:

  1. Occorre prestare attenzione al file gocryptfs.conf. Visto che contiene la master key cifrata, senza questo file la decifratura sarebbe impossibile.
  2. Come suggerito durante la fase di inizializzazione, è bene conservare la master key così che, nel caso si perda o si corrompa il file gocryptfs.conf, sia possibile rigenerarlo con la master key.

Forward Mode su cloud storage (es. Dropbox)

In questo caso, sia il file di configurazione contenente la master key cifrata che la password di decifratura, saranno allocate esternamente alla directory cifrata su Dropbox. In questo modo, anche guadagnando l'accesso al clud storage, ci sarebbero solo dei file cifrati senza avere nemmeno la possibilità di tentare attacchi di forza bruta sulla master key cifrata.

Visto che la password sarà scritta su un file, e non avrò bisogno di ricordarla a memoria, verrà generata ricorrendo al generatore di pseudo-casualità del kernel /dev/urandom e sarà lunga il massimo consentito, 2048 bytes.

1. Inizializzazione

# creazione della directory cifrata e della directory in chiaro
mkdir $HOME/Dropbox/.cipherdir $HOME/plaindir

# creazione di un keyfile di 2k (la massima lunghezza possibile)
umask 077 && tr -dc '[:graph:]' < /dev/urandom | head -c 2048 > /run/media/$USER/<pendrive>/mykey.txt
 
# inizializzazione della cartella cifrata
gocryptfs \
  -passfile /run/media/$USER/<pendrive>/mykey.txt \
  -config /run/media/$USER/<pendrive>/gocryptfs.conf \
  -init $HOME/Dropbox/.cipherdir
Using config file at custom location /run/media/$USER/<pendrive>/gocryptfs.conf
Choose a password for protecting your files.
passfile: reading from file "/run/media/$USER/<pendrive>/mykey.txt"

Your master key is:

    dcceb426-75724350-f53566f6-2991cfa9-
    7a091a4f-397eab55-170c3363-a16b0ab3

If the gocryptfs.conf file becomes corrupted or you ever forget your password,
there is only one hope for recovery: The master key. Print it to a piece of
paper and store it in a drawer. This message is only printed once.
The gocryptfs filesystem has been created successfully.
You can now mount it using: gocryptfs cipherdir MOUNTPOINT

2. Mount

gocryptfs \
  -config /run/media/$USER/<pendrive>/gocryptfs.conf \
  -passfile /run/media/$USER/<pendrive>/mykey.txt 
  $HOME/Dropbox/.cipherdir $HOME/plaindir

3. Unmount

fusermount -u $HOME/plaindir

Reverse mode

Questa modalità torna utile quando si vuole offrire al volo una vista cifrata di una determinata directory, ad es. quando vogliamo fare un backup cifrato.

Supponiamo di volere effettuare un backup cifrato della directory “myDocuments”

1. Inizializzazione

gocryptfs -init -reverse $HOME/myDocuments
Choose a password for protecting your files.
Password:
Repeat:

Your master key is:

    cda5cac4-5435e8e8-68d6d038-451a6955-
    c269c57c-d8b5fe5e-4d5ca589-4eb5e7ac

If the gocryptfs.conf file becomes corrupted or you ever forget your password,
there is only one hope for recovery: The master key. Print it to a piece of
paper and store it in a drawer. This message is only printed once.
The gocryptfs-reverse filesystem has been created successfully.
You can now mount it using: gocryptfs -reverse plaindir MOUNTPOINT

Nella directory “myDocuments” sarà presente il file di configurazione, di default .gocryptfs.reverse.conf

2. Mount

mkdir $HOME/cipherdir_reverse
gocryptfs -reverse $HOME/myDocuments $HOME/cipherdir_reverse

Dopo il mount, il file .gocryptfs.reverse.conf verrà “copiato” nel punto di montaggio come gocryptfs.conf in modo che il backup possa essere montato direttamente in forward mode.

3. Unmont

fusermount -u $HOME/cipherdir_reverse

Nulla vieta che anche nel reverse mode si possa ricorrere a password e file di configurazione “detachable”.

gocryptfs \
  -passfile /run/media/$USER/<pendrive>/mykey.txt \
  -config /run/media/$USER/<pendrive>/gocryptfs.reverse.conf \
  -init -reverse $HOME/myDocuments

N.B. In questo caso anche il backup avrà bisogno del file di configurazione e della password per essere montato.

Varie ed eventuali

Cambio password

Supponiamo di voler cambiare la password (keyfile) della nostra directory cifrata su Dropbox

gocryptfs \
  -config /run/media/$USER/<pendrive>/gocryptfs.conf 
  -passfile /run/media/$USER/<pendrive>/mykey.txt
  -passwd $HOME/Dropbox/.cipherdir
Using config file at custom location /run/media/$USER/<pendrive>/gocryptfs.conf
Password:
Decrypting master key
Please enter your new password.
Password:
Repeat:

N.B. Non è possibile specificare un keyfile come nuova password (possibile solo durante l'init). Il keyfile in questo caso servirà solo a decriptare la master key che verrà cifrata con la nuova password.

Mount automatico

Nel caso di forward mode, può tornare comodo il mount automatico della directory cifrata. È sufficiente definire un piccolo script che esegua il montaggio e che parta in esecuzione automatica dopo il login.

Due osservazioni:

  1. Conviene che la password sia stoccata nel keyring (di Gnome nel mio caso) così da rendere la password inaccessibile senza il login.
  2. il file di configurazione può continuare a rimanere al di fuori della directory cifrata (soprattutto nel caso cloud storage) purché sia accessibile dopo il login.

1. Generazione password

# suppongo che la password sia stata generata come in forward
# mode e che stia in un file di testo che ora memorizzerò nel
# keyring con secret-tool
cat mykey.txt | secret-tool store --label="gocryptfs" myCipherDir myPassword

2. Creazione script

cat > $HOME/mount_gocryptfs.sh << EOF
#!/bin/bash
gocryptfs \
  -config $HOME/gocryptfs.conf \
  -extpass="secret-tool lookup myCipherDir myPassword" \
  $HOME/Dropbox/.cipherdir $HOME/plaindir
EOF
chmod 700 $HOME/mount_gocryptfs.sh

3. Creazione del launcher

cat > $HOME/.config/autostart/mountGocryptfs.desktop << EOF
[Desktop Entry]
Name=mount_gocryptfs
GenericName=mount_gocryptfs
Comment=Monta la cartella cifrata con gocryptfs
Exec=/home/<user>/mount_gocryptfs.sh
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true
Comment[it_IT]=
EOF

In questo modo, dopo il login, verrà eseguito lo script (grazie a $HOME/.config/autostart/) che recupererà la password via secret-tool dal keyring.

Rigenerazione del file gocryptfs.conf

Ma se smarrissi il file gocryptfs.conf, o mi si corrompe il supporto esterno che lo contiene? O se dimenticassi / perdessi la password?

È un grosso guaio. La directory cifrata non sarà più accessibile. O meglio. Lo sarà solo avendo la master key. E con questa possiamo, non solo montare la directory cifrata, ma anche ricostruire il file di configurazione.

Innanzitutto verifichiamo se l'accesso diretto con la master key funzioni:

Accesso con la master key

gocryptfs \
  -masterkey dcceb426-75724350-f53566f6-2991cfa9-7a091a4f-397eab55-170c3363-a16b0ab3 \
  $HOME/Dropbox/.cipherdir $HOME/plaindir
Using explicit master key.
THE MASTER KEY IS VISIBLE VIA "ps ax" AND MAY BE STORED IN YOUR SHELL HISTORY!
ONLY USE THIS MODE FOR EMERGENCIES
Filesystem mounted and ready.

Per evitare il warning, si può ricorrere al flag stdin che obbliga all'inserimento manuale da tastiera della master key:

gocryptfs -masterkey stdin $HOME/Dropbox/.cipherdir $HOME/plaindir
Masterkey:
Using explicit master key.
Filesystem mounted and ready.

Caso 1: Smarrimento password Se è solo la password, basterà accedere alla directory cifrata con la master key usando lo stesso file di configurazone e inserire una nuova password:

# Cambio password
gocryptfs \Inserimento
  -masterkey dcceb426-75724350-f53566f6-2991cfa9-7a091a4f-397eab55-170c3363-a16b0ab3 \
  -config /run/media/$USER/<pendrive>/gocryptfs.conf \
  -passwd
  $HOME/Dropbox/.cipherdir
Using config file at custom location /run/media/$USER/<pendrive>/gocryptfs.conf
Using explicit master key.
THE MASTER KEY IS VISIBLE VIA "ps ax" AND MAY BE STORED IN YOUR SHELL HISTORY!
ONLY USE THIS MODE FOR EMERGENCIES
Please enter your new password.
Password:
Repeat:
A copy of the old config file has been created at "/run/media/$USER/<pendrive>/gocryptfs.conf.bak".
Delete it after you have verified that you can access your files with the new password.
Password changed.

N.B. Siccome il file di configurazione verrà modificato con un nuovo salt e una nuova password, del file di configurazione verrà fatta una copia di backup precauzionale,

Caso 2: Ricostruzione file di configurazione È praticamente lo stesso procedimentod di prima solo che in questo caso occorre ricostruire il file di configurazione.

  1. Si ricrea un file di configurazione con -init avente cura di replicare le stesse impostazioni di quello compromesso (nel mio caso è semplice, tutto default) su una directory cifrata temporanea
  2. il file di configurazione così ottenuto, si sposta nella directory cifrata effettiva e si imposta la nuova password
# inizializzo una directory cifrata temporanea
gocryptfs -init $HOME/cipher_temp

# Sposto il nuovo file di configurazione dalla directory
# temporanea cifrata al punto in cui si trovava in precedenza 
# (la nostra nuova pendrive)
mv $HOME/cipher_temp/gocryptfs.conf /run/media/$USER/<nuova_pendrive>/gocryptfs.conf

# Inserimento password
gocryptfs \
  -masterkey dcceb426-75724350-f53566f6-2991cfa9-7a091a4f-397eab55-170c3363-a16b0ab3 \
  -config /run/media/$USER/<nuova_pendrive>/gocryptfs.conf \
  -passwd
  $HOME/Dropbox/.cipherdir
Using config file at custom location /run/media/$USER/<nuova_pendrive>/gocryptfs.conf
Using explicit master key.
THE MASTER KEY IS VISIBLE VIA "ps ax" AND MAY BE STORED IN YOUR SHELL HISTORY!
ONLY USE THIS MODE FOR EMERGENCIES
Please enter your new password.
Password:
Repeat:
A copy of the old config file has been created at "/run/media/$USER/<nuova_pendrive>/gocryptfs.conf.bak".
Delete it after you have verified that you can access your files with the new password.
Password changed.

E ora il volume può essere montato nuovamente.

]]> https://noblogo.org/aytin/come-cifrare-file-e-directory-con-gocryptfs Mon, 05 Jan 2026 15:30:07 +0000 Audit per client e server ssh https://noblogo.org/aytin/audit-per-client-e-server-ssh <![CDATA[ssh-audit ssh-audit è un un comodo tool per l'audit di sicurezza del server e del client SSH (banner, scambio di chiavi, crittografia, mac, compressione, compatibilità, sicurezza, ecc.) Il sito di riferimento: https://www.ssh-audit.com/ da cui si può effettuare una scansione sia del proprio client che di un server. !--more-- Questa sezione https://www.ssh-audit.com/hardeningguides.html invece fornisce una serie di configurazioni rapide e sicure per la pletora di client e server più noti. ssh-audit permette di eseguire delle scansioni generiche client e/o server o di controllare una specifica compliance (ne parlerò più avanti) in base al sistema in uso Installare ssh-audit Trattandosi di una utility via CLI, la installerò con pipx che mi garantisce il necessario isolamento e un link all'eseguibile che sia "globale" per l'utente. pipx install ssh-audit o pipx install ssh-audit --python pythonversione se si vuole una versione di python specifica Se non dovesse essere presente pipx, nella nostra home: aggiornamento e installazione pip, pipx pip install --user -U pip pipx ssh-audit può essere usato per il check e la configurazione di un server ssh o del client. Scansione server Semplice. ssh-audit -p porta ssh ip / server ssh effettua la scansione di un server ssh. Il risultato consisterà in una serie di informazioni sulle direttive riguardanti cipher, klex, mac ecc. che saranno: [info] di colore verde o bianco corrispondenti a configurazioni corrette [warning] di colore giallo, corrispondenti a configurazioni da attenzionare [fail] di colore rosso, corrispondenti a configurazioni palesemente critiche e da correggere urgentemente. Ecco un es. di scansione sul default ssh server di una debian 13 (RaspBI 2): general (gen) banner: SSH-2.0-OpenSSH10.0p2 Raspbian-7 (gen) software: OpenSSH 10.0p2 (gen) compatibility: OpenSSH 9.9+, Dropbear SSH 2020.79+ (gen) compression: enabled (zlib@openssh.com) key exchange algorithms (kex) mlkem768x25519-sha256 -- [info] available since OpenSSH 9.9 `- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm (kex) sntrup761x25519-sha512 -- [info] available since OpenSSH 9.9 `- [info] default key exchange since OpenSSH 9.9 `- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm (kex) sntrup761x25519-sha512@openssh.com -- [info] available since OpenSSH 8.5 `- [info] default key exchange from OpenSSH 9.0 to 9.8 `- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm (kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76 `- [info] default key exchange from OpenSSH 7.4 to 8.9 (kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62 `- [info] default key exchange from OpenSSH 6.5 to 7.3 (kex) ecdh-sha2-nistp256 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (kex) ecdh-sha2-nistp384 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (kex) ecdh-sha2-nistp521 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (kex) ext-info-s -- [info] available since OpenSSH 9.6 `- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions (kex) kex-strict-s-v00@openssh.com -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795) host-key algorithms (key) rsa-sha2-512 (3072-bit) -- [info] available since OpenSSH 7.2 (key) rsa-sha2-256 (3072-bit) -- [info] available since OpenSSH 7.2, Dropbear SSH 2020.79 (key) ecdsa-sha2-nistp256 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [warn] using weak random number generator could reveal the key `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (key) ssh-ed25519 -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79 encryption algorithms (ciphers) (enc) chacha20-poly1305@openssh.com -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79 `- [info] default cipher since OpenSSH 6.9 (enc) aes128-gcm@openssh.com -- [info] available since OpenSSH 6.2 (enc) aes256-gcm@openssh.com -- [info] available since OpenSSH 6.2 (enc) aes128-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52 (enc) aes192-ctr -- [info] available since OpenSSH 3.7 (enc) aes256-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52 message authentication code algorithms (mac) umac-64-etm@openssh.com -- [warn] using small 64-bit tag size `- [info] available since OpenSSH 6.2 (mac) umac-128-etm@openssh.com -- [info] available since OpenSSH 6.2 (mac) hmac-sha2-256-etm@openssh.com -- [info] available since OpenSSH 6.2 (mac) hmac-sha2-512-etm@openssh.com -- [info] available since OpenSSH 6.2 (mac) hmac-sha1-etm@openssh.com -- [fail] using broken SHA-1 hash algorithm `- [info] available since OpenSSH 6.2 (mac) umac-64@openssh.com -- [warn] using encrypt-and-MAC mode `- [warn] using small 64-bit tag size `- [info] available since OpenSSH 4.7 (mac) umac-128@openssh.com -- [warn] using encrypt-and-MAC mode `- [info] available since OpenSSH 6.2 (mac) hmac-sha2-256 -- [warn] using encrypt-and-MAC mode `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56 (mac) hmac-sha2-512 -- [warn] using encrypt-and-MAC mode `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56 (mac) hmac-sha1 -- [fail] using broken SHA-1 hash algorithm `- [warn] using encrypt-and-MAC mode `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28 fingerprints (fin) ssh-ed25519: SHA256:MQLZsXQca6z39VMYmL3a+BkZCbBSQywXlwUQ7t/SJJc (fin) ssh-rsa: SHA256:rSR43CCF4H6QSMPR+TudpYEMuH0xQ/61iE4ktcidw2c additional info (nfo) Be aware that, while this target properly supports the strict key exchange method (via the kex-strict-?-v00@openssh.com marker) needed to protect against the Terrapin vulnerability (CVE-2023-48795), all peers must also support this feature as well, otherwise the vulnerability will still be present. The following algorithms would allow an unpatched peer to create vulnerable SSH channels with this target: chacha20-poly1305@openssh.com. If any CBC ciphers are in this list, you may remove them while leaving the -etm@openssh.com MACs in place; these MACs are fine while paired with non-CBC cipher types. Per la scansione del server ssh basta: ssh-audit serverssh se la porta è di default, se no occorre specificarla. Altrimenti se si vuole verificare la compliance con un target specifico, si può usare il flag -P Ad es. per verificare la configurazione ottimale rispetto ad una debian 12 di riferimento. ssh-audit -P "Hardened Debian 12 (version 2)" serverssh e l'argomento di P è dato da una delle policies della seguente lista: ssh-audit -L La versione attuale di ssh-audit è la 3.3.0 che supporta al max. OpenSSH 9.9, Debian 12, Ubuntu 24 ecc. Con la 3.4.0, ci sarà il supporto a OpenSSH 10, Debian 13, si rimuoverà sshv1 ecc. (per maggiori info https://github.com/jtesta/ssh-audit) Se avessi più server da verificare? ssh-audit -t host.txt dove host.txt è un file contente una lista host, uno per linea, dal formato: HOST[:PORT] Scansione client Prima si fa partire un server ssh-audit sulla porta 2222 (default, altrimenti si può cambiare con -p) ssh-audit -c e poi si prova la connessione ssh sulla porta 2222 (o su quella impostata su localhost) ssh -p2222 127.0.0.1 Come per il server, il risultato con una configurazione di default, di solito, non è molto incoraggiante: Connection closed by 127.0.0.1 port 2222 general (gen) client IP: 127.0.0.1 (gen) banner: SSH-2.0-OpenSSH10.0 (gen) software: OpenSSH 10.0 (gen) compression: enabled (zlib@openssh.com) key exchange algorithms (kex) mlkem768x25519-sha256 -- [info] available since OpenSSH 9.9 `- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm (kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76 `- [info] default key exchange from OpenSSH 7.4 to 8.9 (kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62 `- [info] default key exchange from OpenSSH 6.5 to 7.3 (kex) ecdh-sha2-nistp256 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (kex) ecdh-sha2-nistp384 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (kex) ecdh-sha2-nistp521 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (kex) diffie-hellman-group-exchange-sha256 -- [info] available since OpenSSH 4.4 (kex) diffie-hellman-group14-sha256 -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength `- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73 (kex) diffie-hellman-group16-sha512 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73 (kex) diffie-hellman-group18-sha512 -- [info] available since OpenSSH 7.3 (kex) ext-info-c -- [info] available since OpenSSH 7.2 `- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions (kex) kex-strict-c-v00@openssh.com -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795) host-key algorithms (key) ssh-ed25519-cert-v01@openssh.com -- [info] available since OpenSSH 6.5 (key) ecdsa-sha2-nistp256-cert-v01@openssh.com -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [warn] using weak random number generator could reveal the key `- [info] available since OpenSSH 5.7 (key) ecdsa-sha2-nistp384-cert-v01@openssh.com -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [warn] using weak random number generator could reveal the key `- [info] available since OpenSSH 5.7 (key) ecdsa-sha2-nistp521-cert-v01@openssh.com -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [warn] using weak random number generator could reveal the key `- [info] available since OpenSSH 5.7 (key) sk-ssh-ed25519-cert-v01@openssh.com -- [info] available since OpenSSH 8.2 (key) sk-ecdsa-sha2-nistp256-cert-v01@openssh.com -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [warn] using weak random number generator could reveal the key `- [info] available since OpenSSH 8.2 (key) rsa-sha2-512-cert-v01@openssh.com -- [info] available since OpenSSH 7.8 (key) rsa-sha2-256-cert-v01@openssh.com -- [info] available since OpenSSH 7.8 (key) ssh-ed25519 -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79 (key) ecdsa-sha2-nistp256 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [warn] using weak random number generator could reveal the key `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (key) ecdsa-sha2-nistp384 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [warn] using weak random number generator could reveal the key `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (key) ecdsa-sha2-nistp521 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [warn] using weak random number generator could reveal the key `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (key) sk-ssh-ed25519@openssh.com -- [info] available since OpenSSH 8.2 (key) sk-ecdsa-sha2-nistp256@openssh.com -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency `- [warn] using weak random number generator could reveal the key `- [info] available since OpenSSH 8.2 (key) rsa-sha2-512 -- [info] available since OpenSSH 7.2 (key) rsa-sha2-256 -- [info] available since OpenSSH 7.2, Dropbear SSH 2020.79 encryption algorithms (ciphers) (enc) aes256-gcm@openssh.com -- [info] available since OpenSSH 6.2 (enc) chacha20-poly1305@openssh.com -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79 `- [info] default cipher since OpenSSH 6.9 (enc) aes256-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52 (enc) aes128-gcm@openssh.com -- [info] available since OpenSSH 6.2 (enc) aes128-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52 message authentication code algorithms (mac) hmac-sha2-256-etm@openssh.com -- [info] available since OpenSSH 6.2 (mac) hmac-sha1-etm@openssh.com -- [fail] using broken SHA-1 hash algorithm `- [info] available since OpenSSH 6.2 (mac) umac-128-etm@openssh.com -- [info] available since OpenSSH 6.2 (mac) hmac-sha2-512-etm@openssh.com -- [info] available since OpenSSH 6.2 (mac) hmac-sha2-256 -- [warn] using encrypt-and-MAC mode `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56 (mac) hmac-sha1 -- [fail] using broken SHA-1 hash algorithm `- [warn] using encrypt-and-MAC mode `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28 (mac) umac-128@openssh.com -- [warn] using encrypt-and-MAC mode `- [info] available since OpenSSH 6.2 (mac) hmac-sha2-512 -- [warn] using encrypt-and-MAC mode `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56 additional info (nfo) Be aware that, while this target properly supports the strict key exchange method (via the kex-strict-?-v00@openssh.com marker) needed to protect against the Terrapin vulnerability (CVE-2023-48795), all peers must also support this feature as well, otherwise the vulnerability will still be present. The following algorithms would allow an unpatched peer to create vulnerable SSH channels with this target: chacha20-poly1305@openssh.com. If any CBC ciphers are in this list, you may remove them while leaving the -etm@openssh.com MACs in place; these MACs are fine while paired with non-CBC cipher types. Hardening Le scansioni dei client e dei server contengono numerosi suggerimenti per il miglioramento delle configurazioni. La conoscenza a grandi linee degli algoritmi usati da openssh per contrattare una connessione (e su questo può venire in aiuto, benché datato, il sito a cui ssh-audit.com si ispira: https://blog.stribik.technology/2015/01/04/secure-secure-shell.html) aiuterebbe. Oppure si può ricorrere o alle configurazioni "precotte" che potete trovare qui e magari partendo da quelle, limarle in base alle nostre esigenze. Come regola generale, in sintesi, ricordarsi di evitare in prima battuta: chiavi rsa < 3072 bit dsa le curve nist qualunque algoritmo che usi sha1 Per il resto, basterebbe eliminare tutti gli algoritmi che risultano fail e warning dalla scansione e includere, in ordine decrescente, gli algoritmi più robusti che scaturiscono dalle liste degli algoritmi supportati dalla versione ssh in uso disponibili con ssh -Q: key exchange ssh -Q kex cifratura simmetrica e simmetrica-autenticata ssh -Q [ cipher | cipher-auth ] key types, CA signatures, certificate key types, tutti ssh -Q [ key | key-ca-sign | key-cert | key-sig ] algoritmi di firma ssh-Q sig L'hardenizzazione di un servizio come ssh passa anche da altro. Esigerebbe una stretta sui metodi di autenticazione (la sola public key), restrizioi a utenti o gruppi di utenti ecc. (accennavo qualcosa qui) Ad ogni modo, una volta effettuato l'hardening del server, ecco come si può presentare la scansione: general (gen) banner: SSH-2.0-OpenSSH10.0p2 Raspbian-7 (gen) software: OpenSSH 10.0p2 (gen) compatibility: OpenSSH 9.6+, Dropbear SSH 2020.79+ (gen) compression: enabled (zlib@openssh.com) key exchange algorithms (kex) sntrup761x25519-sha512@openssh.com -- [info] available since OpenSSH 8.5 `- [info] default key exchange from OpenSSH 9.0 to 9.8 `- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm (kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76 `- [info] default key exchange from OpenSSH 7.4 to 8.9 (kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62 `- [info] default key exchange from OpenSSH 6.5 to 7.3 (kex) diffie-hellman-group16-sha512 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73 (kex) diffie-hellman-group18-sha512 -- [info] available since OpenSSH 7.3 (kex) diffie-hellman-group-exchange-sha256 (3072-bit) -- [info] available since OpenSSH 4.4 `- [info] OpenSSH's GEX fallback mechanism was triggered during testing. Very old SSH clients will still be able to create connections using a 2048-bit modulus, though modern clients will use 3072. This can only be disabled by recompiling the code (see https://github.com/openssh/openssh-portable/blob/V94/dh.c#L477). (kex) ext-info-s -- [info] available since OpenSSH 9.6 `- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions (kex) kex-strict-s-v00@openssh.com -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795) host-key algorithms (key) ssh-ed25519 -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79 encryption algorithms (ciphers) (enc) aes256-gcm@openssh.com -- [info] available since OpenSSH 6.2 (enc) aes256-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52 (enc) aes192-ctr -- [info] available since OpenSSH 3.7 (enc) aes128-gcm@openssh.com -- [info] available since OpenSSH 6.2 (enc) aes128-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52 message authentication code algorithms (mac) hmac-sha2-256-etm@openssh.com -- [info] available since OpenSSH 6.2 (mac) hmac-sha2-512-etm@openssh.com -- [info] available since OpenSSH 6.2 (mac) umac-128-etm@openssh.com -- [info] available since OpenSSH 6.2 fingerprints (fin) ssh-ed25519: SHA256:MQLZsXQca6z39VMYmL3a+BkZCbBSQywXlwUQ7t/SJJc Tutto molto verde, molto più rassicurante Idem dicasi per il client: general (gen) client IP: 127.0.0.1 (gen) banner: SSH-2.0-OpenSSH_10.0 (gen) software: OpenSSH 10.0 (gen) compression: enabled (zlib@openssh.com) key exchange algorithms (kex) sntrup761x25519-sha512@openssh.com -- [info] available since OpenSSH 8.5 `- [info] default key exchange from OpenSSH 9.0 to 9.8 `- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm (kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76 `- [info] default key exchange from OpenSSH 7.4 to 8.9 (kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62 `- [info] default key exchange from OpenSSH 6.5 to 7.3 (kex) diffie-hellman-group16-sha512 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73 (kex) diffie-hellman-group18-sha512 -- [info] available since OpenSSH 7.3 (kex) diffie-hellman-group-exchange-sha256 -- [info] available since OpenSSH 4.4 (kex) ext-info-c -- [info] available since OpenSSH 7.2 `- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions (kex) kex-strict-c-v00@openssh.com -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795) host-key algorithms (key) sk-ssh-ed25519-cert-v01@openssh.com -- [info] available since OpenSSH 8.2 (key) ssh-ed25519-cert-v01@openssh.com -- [info] available since OpenSSH 6.5 (key) rsa-sha2-512-cert-v01@openssh.com -- [info] available since OpenSSH 7.8 (key) rsa-sha2-256-cert-v01@openssh.com -- [info] available since OpenSSH 7.8 (key) sk-ssh-ed25519@openssh.com -- [info] available since OpenSSH 8.2 (key) ssh-ed25519 -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79 (key) rsa-sha2-512 -- [info] available since OpenSSH 7.2 (key) rsa-sha2-256 -- [info] available since OpenSSH 7.2, Dropbear SSH 2020.79 encryption algorithms (ciphers) (enc) aes256-gcm@openssh.com -- [info] available since OpenSSH 6.2 (enc) aes256-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52 (enc) aes192-ctr -- [info] available since OpenSSH 3.7 (enc) aes128-gcm@openssh.com -- [info] available since OpenSSH 6.2 (enc) aes128-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52 message authentication code algorithms (mac) hmac-sha2-256-etm@openssh.com -- [info] available since OpenSSH 6.2 (mac) hmac-sha2-512-etm@openssh.com -- [info] available since OpenSSH 6.2 (mac) umac-128-etm@openssh.com -- [info] available since OpenSSH 6.2 Connection closed by 127.0.0.1 port 2222 Giusto per completezza, anche se la scansione generica può essere positiva, non è detto che lo sia l'aderenza ad una specifica compliance. Una scansione di questo tipo infatti tiene conto di tutti gli algoritmi che devono essere presenti. E nell'ordine stabilito.]]> ssh-audit

ssh-audit è un un comodo tool per l'audit di sicurezza del server e del client SSH (banner, scambio di chiavi, crittografia, mac, compressione, compatibilità, sicurezza, ecc.)

Il sito di riferimento: https://www.ssh-audit.com/ da cui si può effettuare una scansione sia del proprio client che di un server. Questa sezione https://www.ssh-audit.com/hardening_guides.html invece fornisce una serie di configurazioni rapide e sicure per la pletora di client e server più noti.

ssh-audit permette di eseguire delle scansioni generiche client e/o server o di controllare una specifica compliance (ne parlerò più avanti) in base al sistema in uso

Installare ssh-audit

Trattandosi di una utility via CLI, la installerò con pipx che mi garantisce il necessario isolamento e un link all'eseguibile che sia “globale” per l'utente.

pipx install ssh-audit
# o pipx install ssh-audit --python python<versione>
# se si vuole una versione di python specifica

Se non dovesse essere presente pipx, nella nostra home:

# aggiornamento e installazione pip, pipx
pip install --user -U pip pipx

ssh-audit può essere usato per il check e la configurazione di un server ssh o del client.

Scansione server

Semplice.

ssh-audit -p <porta ssh> <ip / server ssh>

effettua la scansione di un server ssh. Il risultato consisterà in una serie di informazioni sulle direttive riguardanti cipher, klex, mac ecc. che saranno:

  • [info] di colore verde o bianco corrispondenti a configurazioni corrette
  • [warning] di colore giallo, corrispondenti a configurazioni da attenzionare
  • [fail] di colore rosso, corrispondenti a configurazioni palesemente critiche e da correggere urgentemente.

Ecco un es. di scansione sul default ssh server di una debian 13 (RaspBI 2):

# general
(gen) banner: SSH-2.0-OpenSSH_10.0p2 Raspbian-7
(gen) software: OpenSSH 10.0p2
(gen) compatibility: OpenSSH 9.9+, Dropbear SSH 2020.79+
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) mlkem768x25519-sha256               -- [info] available since OpenSSH 9.9
                                          `- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm
(kex) sntrup761x25519-sha512              -- [info] available since OpenSSH 9.9
                                          `- [info] default key exchange since OpenSSH 9.9
                                          `- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm
(kex) sntrup761x25519-sha512@openssh.com  -- [info] available since OpenSSH 8.5
                                          `- [info] default key exchange from OpenSSH 9.0 to 9.8
                                          `- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm
(kex) curve25519-sha256                   -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
                                          `- [info] default key exchange from OpenSSH 7.4 to 8.9
(kex) curve25519-sha256@libssh.org        -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
                                          `- [info] default key exchange from OpenSSH 6.5 to 7.3
(kex) ecdh-sha2-nistp256                  -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                          `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384                  -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                          `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521                  -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                          `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ext-info-s                          -- [info] available since OpenSSH 9.6
                                          `- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions
(kex) kex-strict-s-v00@openssh.com        -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)

# host-key algorithms
(key) rsa-sha2-512 (3072-bit)             -- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (3072-bit)             -- [info] available since OpenSSH 7.2, Dropbear SSH 2020.79
(key) ecdsa-sha2-nistp256                 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                          `- [warn] using weak random number generator could reveal the key
                                          `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ssh-ed25519                         -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com       -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79
                                          `- [info] default cipher since OpenSSH 6.9
(enc) aes128-gcm@openssh.com              -- [info] available since OpenSSH 6.2
(enc) aes256-gcm@openssh.com              -- [info] available since OpenSSH 6.2
(enc) aes128-ctr                          -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                          -- [info] available since OpenSSH 3.7
(enc) aes256-ctr                          -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52

# message authentication code algorithms
(mac) umac-64-etm@openssh.com             -- [warn] using small 64-bit tag size
                                          `- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com            -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256-etm@openssh.com       -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com       -- [info] available since OpenSSH 6.2
(mac) hmac-sha1-etm@openssh.com           -- [fail] using broken SHA-1 hash algorithm
                                          `- [info] available since OpenSSH 6.2
(mac) umac-64@openssh.com                 -- [warn] using encrypt-and-MAC mode
                                          `- [warn] using small 64-bit tag size
                                          `- [info] available since OpenSSH 4.7
(mac) umac-128@openssh.com                -- [warn] using encrypt-and-MAC mode
                                          `- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256                       -- [warn] using encrypt-and-MAC mode
                                          `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha2-512                       -- [warn] using encrypt-and-MAC mode
                                          `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha1                           -- [fail] using broken SHA-1 hash algorithm
                                          `- [warn] using encrypt-and-MAC mode
                                          `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28

# fingerprints
(fin) ssh-ed25519: SHA256:MQLZsXQca6z39VMYmL3a+BkZCbBSQywXlwUQ7t/SJJc
(fin) ssh-rsa: SHA256:rSR43CCF4H6QSMPR+TudpYEMuH0xQ/61iE4ktcidw2c

# additional info
(nfo) Be aware that, while this target properly supports the strict key exchange method (via the kex-strict-?-v00@openssh.com marker) needed to protect against the Terrapin vulnerability (CVE-2023-48795), all peers must also support this feature as well, otherwise the vulnerability will still be present.  The following algorithms would allow an unpatched peer to create vulnerable SSH channels with this target: chacha20-poly1305@openssh.com.  If any CBC ciphers are in this list, you may remove them while leaving the *-etm@openssh.com MACs in place; these MACs are fine while paired with non-CBC cipher types.

Per la scansione del server ssh basta:

ssh-audit server_ssh 
# se la porta è di default, se no occorre specificarla.

Altrimenti se si vuole verificare la compliance con un target specifico, si può usare il flag -P Ad es. per verificare la configurazione ottimale rispetto ad una debian 12 di riferimento.

ssh-audit -P "Hardened Debian 12 (version 2)" <server_ssh>

e l'argomento di P è dato da una delle policies della seguente lista:

ssh-audit -L

La versione attuale di ssh-audit è la 3.3.0 che supporta al max. OpenSSH 9.9, Debian 12, Ubuntu 24 ecc.

Con la 3.4.0, ci sarà il supporto a OpenSSH 10, Debian 13, si rimuoverà sshv1 ecc. (per maggiori info https://github.com/jtesta/ssh-audit)

Se avessi più server da verificare?

ssh-audit -t host.txt

dove host.txt è un file contente una lista host, uno per linea, dal formato: HOST[:PORT]

Scansione client

Prima si fa partire un server ssh-audit sulla porta 2222 (default, altrimenti si può cambiare con -p)

ssh-audit -c

e poi si prova la connessione ssh sulla porta 2222 (o su quella impostata su localhost)

ssh -p2222 127.0.0.1

Come per il server, il risultato con una configurazione di default, di solito, non è molto incoraggiante:

Connection closed by 127.0.0.1 port 2222
# general
(gen) client IP: 127.0.0.1
(gen) banner: SSH-2.0-OpenSSH_10.0
(gen) software: OpenSSH 10.0
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) mlkem768x25519-sha256                        -- [info] available since OpenSSH 9.9
                                                   `- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm
(kex) curve25519-sha256                            -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
                                                   `- [info] default key exchange from OpenSSH 7.4 to 8.9
(kex) curve25519-sha256@libssh.org                 -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
                                                   `- [info] default key exchange from OpenSSH 6.5 to 7.3
(kex) ecdh-sha2-nistp256                           -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                                   `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384                           -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                                   `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521                           -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                                   `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256         -- [info] available since OpenSSH 4.4
(kex) diffie-hellman-group14-sha256                -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
                                                   `- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group16-sha512                -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512                -- [info] available since OpenSSH 7.3
(kex) ext-info-c                                   -- [info] available since OpenSSH 7.2
                                                   `- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions
(kex) kex-strict-c-v00@openssh.com                 -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)

# host-key algorithms
(key) ssh-ed25519-cert-v01@openssh.com             -- [info] available since OpenSSH 6.5
(key) ecdsa-sha2-nistp256-cert-v01@openssh.com     -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                                   `- [warn] using weak random number generator could reveal the key
                                                   `- [info] available since OpenSSH 5.7
(key) ecdsa-sha2-nistp384-cert-v01@openssh.com     -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                                   `- [warn] using weak random number generator could reveal the key
                                                   `- [info] available since OpenSSH 5.7
(key) ecdsa-sha2-nistp521-cert-v01@openssh.com     -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                                   `- [warn] using weak random number generator could reveal the key
                                                   `- [info] available since OpenSSH 5.7
(key) sk-ssh-ed25519-cert-v01@openssh.com          -- [info] available since OpenSSH 8.2
(key) sk-ecdsa-sha2-nistp256-cert-v01@openssh.com  -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                                   `- [warn] using weak random number generator could reveal the key
                                                   `- [info] available since OpenSSH 8.2
(key) rsa-sha2-512-cert-v01@openssh.com            -- [info] available since OpenSSH 7.8
(key) rsa-sha2-256-cert-v01@openssh.com            -- [info] available since OpenSSH 7.8
(key) ssh-ed25519                                  -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79
(key) ecdsa-sha2-nistp256                          -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                                   `- [warn] using weak random number generator could reveal the key
                                                   `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ecdsa-sha2-nistp384                          -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                                   `- [warn] using weak random number generator could reveal the key
                                                   `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ecdsa-sha2-nistp521                          -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                                   `- [warn] using weak random number generator could reveal the key
                                                   `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) sk-ssh-ed25519@openssh.com                   -- [info] available since OpenSSH 8.2
(key) sk-ecdsa-sha2-nistp256@openssh.com           -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                                   `- [warn] using weak random number generator could reveal the key
                                                   `- [info] available since OpenSSH 8.2
(key) rsa-sha2-512                                 -- [info] available since OpenSSH 7.2
(key) rsa-sha2-256                                 -- [info] available since OpenSSH 7.2, Dropbear SSH 2020.79

# encryption algorithms (ciphers)
(enc) aes256-gcm@openssh.com                       -- [info] available since OpenSSH 6.2
(enc) chacha20-poly1305@openssh.com                -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79
                                                   `- [info] default cipher since OpenSSH 6.9
(enc) aes256-ctr                                   -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes128-gcm@openssh.com                       -- [info] available since OpenSSH 6.2
(enc) aes128-ctr                                   -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52

# message authentication code algorithms
(mac) hmac-sha2-256-etm@openssh.com                -- [info] available since OpenSSH 6.2
(mac) hmac-sha1-etm@openssh.com                    -- [fail] using broken SHA-1 hash algorithm
                                                   `- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com                     -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com                -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256                                -- [warn] using encrypt-and-MAC mode
                                                   `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha1                                    -- [fail] using broken SHA-1 hash algorithm
                                                   `- [warn] using encrypt-and-MAC mode
                                                   `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28
(mac) umac-128@openssh.com                         -- [warn] using encrypt-and-MAC mode
                                                   `- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512                                -- [warn] using encrypt-and-MAC mode
                                                   `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56

# additional info
(nfo) Be aware that, while this target properly supports the strict key exchange method (via the kex-strict-?-v00@openssh.com marker) needed to protect against the Terrapin vulnerability (CVE-2023-48795), all peers must also support this feature as well, otherwise the vulnerability will still be present.  The following algorithms would allow an unpatched peer to create vulnerable SSH channels with this target: chacha20-poly1305@openssh.com.  If any CBC ciphers are in this list, you may remove them while leaving the *-etm@openssh.com MACs in place; these MACs are fine while paired with non-CBC cipher types.

Hardening

Le scansioni dei client e dei server contengono numerosi suggerimenti per il miglioramento delle configurazioni.

La conoscenza a grandi linee degli algoritmi usati da openssh per contrattare una connessione (e su questo può venire in aiuto, benché datato, il sito a cui ssh-audit.com si ispira: https://blog.stribik.technology/2015/01/04/secure-secure-shell.html) aiuterebbe.

Oppure si può ricorrere o alle configurazioni “precotte” che potete trovare qui e magari partendo da quelle, limarle in base alle nostre esigenze.

Come regola generale, in sintesi, ricordarsi di evitare in prima battuta:

  • chiavi rsa < 3072 bit
  • dsa
  • le curve nist
  • qualunque algoritmo che usi sha1

Per il resto, basterebbe eliminare tutti gli algoritmi che risultano fail e warning dalla scansione e includere, in ordine decrescente, gli algoritmi più robusti che scaturiscono dalle liste degli algoritmi supportati dalla versione ssh in uso disponibili con ssh -Q:

# key exchange
ssh -Q kex

# cifratura simmetrica e simmetrica-autenticata
ssh -Q [ cipher | cipher-auth ]

# key types, CA signatures, certificate key types, tutti
ssh -Q [ key | key-ca-sign | key-cert | key-sig ]

# algoritmi di firma
ssh-Q sig

L'hardenizzazione di un servizio come ssh passa anche da altro. Esigerebbe una stretta sui metodi di autenticazione (la sola public key), restrizioi a utenti o gruppi di utenti ecc. (accennavo qualcosa qui)

Ad ogni modo, una volta effettuato l'hardening del server, ecco come si può presentare la scansione:

# general
(gen) banner: SSH-2.0-OpenSSH_10.0p2 Raspbian-7
(gen) software: OpenSSH 10.0p2
(gen) compatibility: OpenSSH 9.6+, Dropbear SSH 2020.79+
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) sntrup761x25519-sha512@openssh.com    -- [info] available since OpenSSH 8.5
                                            `- [info] default key exchange from OpenSSH 9.0 to 9.8
                                            `- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm
(kex) curve25519-sha256                     -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
                                            `- [info] default key exchange from OpenSSH 7.4 to 8.9
(kex) curve25519-sha256@libssh.org          -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
                                            `- [info] default key exchange from OpenSSH 6.5 to 7.3
(kex) diffie-hellman-group16-sha512         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512         -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group-exchange-sha256 (3072-bit) -- [info] available since OpenSSH 4.4
                                                      `- [info] OpenSSH's GEX fallback mechanism was triggered during testing. Very old SSH clients will still be able to create connections using a 2048-bit modulus, though modern clients will use 3072. This can only be disabled by recompiling the code (see https://github.com/openssh/openssh-portable/blob/V_9_4/dh.c#L477).
(kex) ext-info-s                            -- [info] available since OpenSSH 9.6
                                            `- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions
(kex) kex-strict-s-v00@openssh.com          -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)

# host-key algorithms
(key) ssh-ed25519                           -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79

# encryption algorithms (ciphers)
(enc) aes256-gcm@openssh.com                -- [info] available since OpenSSH 6.2
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                            -- [info] available since OpenSSH 3.7
(enc) aes128-gcm@openssh.com                -- [info] available since OpenSSH 6.2
(enc) aes128-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52

# message authentication code algorithms
(mac) hmac-sha2-256-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com              -- [info] available since OpenSSH 6.2

# fingerprints
(fin) ssh-ed25519: SHA256:MQLZsXQca6z39VMYmL3a+BkZCbBSQywXlwUQ7t/SJJc

Tutto molto verde, molto più rassicurante

Idem dicasi per il client:

# general
(gen) client IP: 127.0.0.1
(gen) banner: SSH-2.0-OpenSSH_10.0
(gen) software: OpenSSH 10.0
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) sntrup761x25519-sha512@openssh.com    -- [info] available since OpenSSH 8.5
                                            `- [info] default key exchange from OpenSSH 9.0 to 9.8
                                            `- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm
(kex) curve25519-sha256                     -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
                                            `- [info] default key exchange from OpenSSH 7.4 to 8.9
(kex) curve25519-sha256@libssh.org          -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
                                            `- [info] default key exchange from OpenSSH 6.5 to 7.3
(kex) diffie-hellman-group16-sha512         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512         -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group-exchange-sha256  -- [info] available since OpenSSH 4.4
(kex) ext-info-c                            -- [info] available since OpenSSH 7.2
                                            `- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions
(kex) kex-strict-c-v00@openssh.com          -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)

# host-key algorithms
(key) sk-ssh-ed25519-cert-v01@openssh.com   -- [info] available since OpenSSH 8.2
(key) ssh-ed25519-cert-v01@openssh.com      -- [info] available since OpenSSH 6.5
(key) rsa-sha2-512-cert-v01@openssh.com     -- [info] available since OpenSSH 7.8
(key) rsa-sha2-256-cert-v01@openssh.com     -- [info] available since OpenSSH 7.8
(key) sk-ssh-ed25519@openssh.com            -- [info] available since OpenSSH 8.2
(key) ssh-ed25519                           -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79
(key) rsa-sha2-512                          -- [info] available since OpenSSH 7.2
(key) rsa-sha2-256                          -- [info] available since OpenSSH 7.2, Dropbear SSH 2020.79

# encryption algorithms (ciphers)
(enc) aes256-gcm@openssh.com                -- [info] available since OpenSSH 6.2
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                            -- [info] available since OpenSSH 3.7
(enc) aes128-gcm@openssh.com                -- [info] available since OpenSSH 6.2
(enc) aes128-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52

# message authentication code algorithms
(mac) hmac-sha2-256-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com              -- [info] available since OpenSSH 6.2
Connection closed by 127.0.0.1 port 2222

Giusto per completezza, anche se la scansione generica può essere positiva, non è detto che lo sia l'aderenza ad una specifica compliance.

Una scansione di questo tipo infatti tiene conto di tutti gli algoritmi che devono essere presenti. E nell'ordine stabilito.

]]> https://noblogo.org/aytin/audit-per-client-e-server-ssh Sat, 13 Dec 2025 11:08:44 +0000 La risposta alla vita, l'universo e a tutto quanto: Fedora 42 https://noblogo.org/aytin/la-risposta-alla-vita-luniverso-e-a-tutto-quanto-fedora-42 <![CDATA[Fedora 42 smallida: a href="https://fedoramagazine.org/whats-new-fedora-workstation-42"fedoramagazine.org/a/i/small L'aggiornamento a fedora 42 scorre abbastanza tranquillamente con dnf-plugin-system-upgrade nel mio solito modo, ormai consolidato dal passaggio di 7 major release. Sempre sul filo del rasoio, con poco spazio (dovrò decidermi a ridimensionare un po' di volumi) ma i (più di) 6 giga di aggiornamento vanno via lisci. !--more-- Dopo l'aggiornamento non noto particolari problemi. Un po' di estensioni saltate per aria (fisiologico), qualche repository ancora non aggiornato, Niente di tragico. dnf repo list --disabled mi dà le indicazioni dei repo disabilitati. Fra i tanti (sono di tipo “test” e “source” al 99%) ne spiccano due che non godono ancora della visibilità a fedora 42. Sono quelli relativi a vagrant e virtualbox. I binari di fedora 41 sono ancora compatibili con fedora 42 per cui, per non lasciare disabilitati questi repo o per non vedere gli irritanti errori 404 durante l'update, compio un'azione un po' indiscriminata: riabilito i repo (e fin qui…) dnf config-manager setopt hashicorp.enabled=1 dnf config-manager setopt virtualbox.enabled=1 modifico brutalmente il baseurl scolpendo il numero di versione: dnf config-manager setopt hashicorp.baseurl=https://rpm.releases.hashicorp.com/fedora/41/x8664/stable dnf config-manager setopt virtualbox.baseurl="http://download.virtualbox.org/virtualbox/rpm/fedora/41/x8664" smallNota a margine: quest'operazione mi ha dato modo di approfondire un po' la conoscenza di dnf5. La vecchia cartella /etc/yum/repos.d per le configurazioni dei repo viene mantenuta ancora per legacy. Le modifiche fatte attraverso dnf config-manager vengono mantenute in un file, solitamente 99-configmanager.repo posizionato in /etc/dnf/repos.override.d./small Sistemati i repository volevo rimettere a posto l'estensione per le notifiche delle app nella tray, visto che AppIndicator and KStatusNotifierItem Support si è rotta dopo l'aggiornamento. La installo dal repository e semplicemente creo un link simbolico in ~/.local/share ln -s /usr/share/gnome-shell/extensions/appindicatorsupport@rgcjonas.gmail.com ~/.local/share/gnome-shell/extensions/appindicatorsupport@rgcjonas.gmail.com Così funziona. Mah… Tutto il resto sembra ok. Mi ritrovo con i profili per il risparmio energetico finalmente funzionanti senza ricorrere a strani sotterfugi (prima per passare da un profilo all'altro dovevo staccare l'alimentazione, se no gli rimbalzava. Ora funziona), un nuovo font, il monitoraggio per il consumo, nuove notifiche ecc. (rif. https://fedoramagazine.org/whats-new-fedora-workstation-42/) Insomma la solita Fedora, aggiornata e soddisfacentemente stabile. #fedora42 #fedora #upgrade]]> Fedora 42 da: fedoramagazine.org

L'aggiornamento a fedora 42 scorre abbastanza tranquillamente con dnf-plugin-system-upgrade nel mio solito modo, ormai consolidato dal passaggio di 7 major release.

Sempre sul filo del rasoio, con poco spazio (dovrò decidermi a ridimensionare un po' di volumi) ma i (più di) 6 giga di aggiornamento vanno via lisci. Dopo l'aggiornamento non noto particolari problemi. Un po' di estensioni saltate per aria (fisiologico), qualche repository ancora non aggiornato, Niente di tragico.

dnf repo list --disabled mi dà le indicazioni dei repo disabilitati.

Fra i tanti (sono di tipo “test” e “source” al 99%) ne spiccano due che non godono ancora della visibilità a fedora 42. Sono quelli relativi a vagrant e virtualbox. I binari di fedora 41 sono ancora compatibili con fedora 42 per cui, per non lasciare disabilitati questi repo o per non vedere gli irritanti errori 404 durante l'update, compio un'azione un po' indiscriminata:

  • riabilito i repo (e fin qui…)
dnf config-manager setopt hashicorp.enabled=1
dnf config-manager setopt virtualbox.enabled=1
  • modifico brutalmente il baseurl scolpendo il numero di versione:
dnf config-manager setopt hashicorp.baseurl=https://rpm.releases.hashicorp.com/fedora/41/x86_64/stable
dnf config-manager setopt virtualbox.baseurl="http://download.virtualbox.org/virtualbox/rpm/fedora/41/x86_64"

Nota a margine: quest'operazione mi ha dato modo di approfondire un po' la conoscenza di dnf5. La vecchia cartella /etc/yum/repos.d per le configurazioni dei repo viene mantenuta ancora per legacy. Le modifiche fatte attraverso dnf config-manager vengono mantenute in un file, solitamente 99-config_manager.repo posizionato in /etc/dnf/repos.override.d.

Sistemati i repository volevo rimettere a posto l'estensione per le notifiche delle app nella tray, visto che AppIndicator and KStatusNotifierItem Support si è rotta dopo l'aggiornamento.

La installo dal repository e semplicemente creo un link simbolico in ~/.local/share

ln -s /usr/share/gnome-shell/extensions/appindicatorsupport@rgcjonas.gmail.com ~/.local/share/gnome-shell/extensions/appindicatorsupport@rgcjonas.gmail.com

Così funziona. Mah…

Tutto il resto sembra ok. Mi ritrovo con i profili per il risparmio energetico finalmente funzionanti senza ricorrere a strani sotterfugi (prima per passare da un profilo all'altro dovevo staccare l'alimentazione, se no gli rimbalzava. Ora funziona), un nuovo font, il monitoraggio per il consumo, nuove notifiche ecc. (rif. https://fedoramagazine.org/whats-new-fedora-workstation-42/)

Insomma la solita Fedora, aggiornata e soddisfacentemente stabile.

#fedora42 #fedora #upgrade

]]> https://noblogo.org/aytin/la-risposta-alla-vita-luniverso-e-a-tutto-quanto-fedora-42 Tue, 22 Apr 2025 11:46:23 +0000 Signal è davvero sicuro? https://noblogo.org/aytin/signal-e-davvero-sicuro <![CDATA[signal smallicenterFonte: a href="https://en.wikipedia.org/wiki/Signal%28software%29"logo Signal su en.wikipedia.org/a/center/i/small Molti avranno sentito parlare del polverone che si è sollevato attorno a Signal in relazione all'incidente di sicurezza avvenuto in seno all'amministrazione Trump. Il fatto Il consigliere per la sicurezza nazionale degli Usa, Michael Waltz, inserisce per errore il giornlsta Jeffrey Goldberg dell'Atlantic in un gruppo ristretto su Signal, comprendente fra gli altri anche il vice di Trump, J.D. Vance e il direttore della CIA John Ratcliffe, dove si discuteva di piani, strategie militari e di relazioni diplomatiche molto delicate. !--more-- La conseguenza Questo incidente, una volta venuto alla luce, ha scatenato com'è comprensibile, un vero putiferio per tanti motivi, uno fra tutti: perché il consiglio di sicurezza nazionale usa Signal, contravvenendo a tutti i protocolli interni di sicurezza che prevedono l'uso di protocolli e strumenti strettamente approvati (e Signal chiaramente non è fra questi)? Dagli USA c'è stato un ovvio, disperato, e molto goffo tentativo ridimensionamento che ha avuto il solo risultato di provocare un boom di download di Signal negli USA di +45% Mentre ancora non si registra nessuna vera risposta alla domanda "perché usare Signal", anche se i fortissimi sospetti di una violazione estesa dei sistemi di comunicazioni statunitensi da parte della Cina sembrano suggerirla, il dibattito locale sul tema è veramente desolante. È la stampa, bellezza! In particolare, due reazioni mi hanno veramente divertito (si ride amaro, eh) quella partorita da Rai News (veramente vergognosa) e quella involontariamente esilarante di FanPage. Nella prima, già provocatoria dal titolo "La chat su Signal: ma è davvero sicura?", si comincia con l'analisi del fatto fino a cadere nel ridicolo quando cerca di demonizzare un app, che nonostante i suoi limiti rimane una delle più sicure in circolazione, nel paragrafo lapidario "La bufala della sicurezza di Signal" affermando nella premessa ad effetto: "Certo, non è whatsapp e nemmeno telegram ma certo è che quella chat non è sicura e per diversi motivi." Senza spiegare MAI quali siano questi motivi se non provando ad attribuire a Signal, con una supercazzola magistrale, la cappella atomica fatta da Michael Waltz che ha aggiunto un giornalista ad una chat ristretta, Seguendo questo ragionamento illuminante, allo stesso modo potrei aprire il cancello di un recinto che custodisce un gregge di pecore per far entrare un lupo e dare la colpa al cancello. Infine, mi ha molto divertito anche la posizione di FanPage (che è fanpage, vabbè. È solo folklore) nell'articolo "Perché Signal non può essere utilizzata per condividere piani di guerra" di Elisabetta Rosso, dove, dopo la presentazione del contesto e una descrizione anche apprezzabile di Signal, FanPage, come e peggio di RaiNews, non teme di sprofondare nel ridicolo quando la giornalista affronta il tema della presunta "inadeguatezza" nel paragrafo "Perché Signal non è adatta per le comunicazioni governative" Secondo Elisabetta Rosso "Uno dei problemi principali è la mancanza di integrazione con le infrastrutture governative" in virtù, spiega, della necessità di una "integrazione con i sistemi di sicurezza nazionale" E, nonostante si possa essere abbastanza d'accordo, subito dopo raggiunge e supera le intuizioni di RaiNews facendo diventare tutto meravigliosamente grottesco quando sottolinea che l'integrazione di cui sopra è necessaria al fine di "garantire il pieno controllo sui dati e sugli accessi." È scritto proprio così ed è così evidente l'incomprensione della bestialità dichiarata che subito dopo rincara la dose sostenendo che: siccome Signal è una piattaforma indipendente, espone comunicazioni a potenziali vulnerabilità (quali? dove? È tutto aperto e analizzabile. Audit di sicurezza indipendenti non li hanno ancora trovati ma Elisabetta Rosso sì) siccome è un servizio esterno, "il governo non può monitorare direttamente le comunicazioni, né applicare misure di sicurezza specifiche per proteggere informazioni sensibili." E sarebbe proprio quest'ultimo punto la pistola fumante che attesta l'insicurezza di Signal. "Non stupisce quindi che persone non autorizzate possano accedere a conversazioni riservate, come dimostra il caso del giornalista nella chat dell'amministrazione Trump", senza considerare che è proprio nel momento in cui ti inserisco in un gruppo che ti sto autorizzando ad accedere. Sarebbe stato diverso se questo giornalista fosse riuscito a catturare quelle conversazioni senza appartenere a quel gruppo. La fiera dell'assurdo. In altre parole, l'insicurezza di Signal per Elisabetta Rosso risiede nel fatto che il governo non possa introdurre trojan che intercettino le comunicazioni. E ripensando al pericolo cinese, è probabilmente proprio questo il motivo per cui è stato usato. "Come bisognerebbe comunicare?", domanda la giornalista dal profondo della sua sapienza. Chi vuole, legga anche quest'ultimo paragrafo. Aggiungo solo che, secondo lei, una comunicazione, per essere veramente sicura, deve anche consentire una supervisione interna. Quindi violabile. È tutto molto divertente ed è evidente come i concetti di sicurezza possano essere molto diversi. Wired dal canto suo è uno dei pochissimi che analizza la questione molto bene(Caso Signal, e se l’uso dell’app da parte dei vertici del governo Usa non fosse un errore?). Tutto il resto che si trova in giro, per quello che ho potuto leggere, è un vero pianto. #signal #sicurezza]]> signal Fonte: logo Signal su en.wikipedia.org

Molti avranno sentito parlare del polverone che si è sollevato attorno a Signal in relazione all'incidente di sicurezza avvenuto in seno all'amministrazione Trump.

Il fatto Il consigliere per la sicurezza nazionale degli Usa, Michael Waltz, inserisce per errore il giornlsta Jeffrey Goldberg dell'Atlantic in un gruppo ristretto su Signal, comprendente fra gli altri anche il vice di Trump, J.D. Vance e il direttore della CIA John Ratcliffe, dove si discuteva di piani, strategie militari e di relazioni diplomatiche molto delicate. La conseguenza Questo incidente, una volta venuto alla luce, ha scatenato com'è comprensibile, un vero putiferio per tanti motivi, uno fra tutti: perché il consiglio di sicurezza nazionale usa Signal, contravvenendo a tutti i protocolli interni di sicurezza che prevedono l'uso di protocolli e strumenti strettamente approvati (e Signal chiaramente non è fra questi)?

Dagli USA c'è stato un ovvio, disperato, e molto goffo tentativo ridimensionamento che ha avuto il solo risultato di provocare un boom di download di Signal negli USA di +45%

Mentre ancora non si registra nessuna vera risposta alla domanda “perché usare Signal”, anche se i fortissimi sospetti di una violazione estesa dei sistemi di comunicazioni statunitensi da parte della Cina sembrano suggerirla, il dibattito locale sul tema è veramente desolante.

È la stampa, bellezza! In particolare, due reazioni mi hanno veramente divertito (si ride amaro, eh) quella partorita da Rai News (veramente vergognosa) e quella involontariamente esilarante di FanPage.

Nella prima, già provocatoria dal titolo “La chat su Signal: ma è davvero sicura?”, si comincia con l'analisi del fatto fino a cadere nel ridicolo quando cerca di demonizzare un app, che nonostante i suoi limiti rimane una delle più sicure in circolazione, nel paragrafo lapidario “La bufala della sicurezza di Signal” affermando nella premessa ad effetto: “Certo, non è whatsapp e nemmeno telegram ma certo è che quella chat non è sicura e per diversi motivi.“

Senza spiegare MAI quali siano questi motivi se non provando ad attribuire a Signal, con una supercazzola magistrale, la cappella atomica fatta da Michael Waltz che ha aggiunto un giornalista ad una chat ristretta,

Seguendo questo ragionamento illuminante, allo stesso modo potrei aprire il cancello di un recinto che custodisce un gregge di pecore per far entrare un lupo e dare la colpa al cancello.

Infine, mi ha molto divertito anche la posizione di FanPage (che è fanpage, vabbè. È solo folklore) nell'articolo “Perché Signal non può essere utilizzata per condividere piani di guerra” di Elisabetta Rosso, dove, dopo la presentazione del contesto e una descrizione anche apprezzabile di Signal, FanPage, come e peggio di RaiNews, non teme di sprofondare nel ridicolo quando la giornalista affronta il tema della presunta “inadeguatezza” nel paragrafo “Perché Signal non è adatta per le comunicazioni governative“

Secondo Elisabetta Rosso “Uno dei problemi principali è la mancanza di integrazione con le infrastrutture governative” in virtù, spiega, della necessità di una “integrazione con i sistemi di sicurezza nazionale“ E, nonostante si possa essere abbastanza d'accordo, subito dopo raggiunge e supera le intuizioni di RaiNews facendo diventare tutto meravigliosamente grottesco quando sottolinea che l'integrazione di cui sopra è necessaria al fine di “garantire il pieno controllo sui dati e sugli accessi.“

È scritto proprio così ed è così evidente l'incomprensione della bestialità dichiarata che subito dopo rincara la dose sostenendo che:

  1. siccome Signal è una piattaforma indipendente, espone comunicazioni a potenziali vulnerabilità (quali? dove? È tutto aperto e analizzabile. Audit di sicurezza indipendenti non li hanno ancora trovati ma Elisabetta Rosso sì)
  2. siccome è un servizio esterno, “il governo non può monitorare direttamente le comunicazioni, né applicare misure di sicurezza specifiche per proteggere informazioni sensibili.“

E sarebbe proprio quest'ultimo punto la pistola fumante che attesta l'insicurezza di Signal. “Non stupisce quindi che persone non autorizzate possano accedere a conversazioni riservate, come dimostra il caso del giornalista nella chat dell'amministrazione Trump”, senza considerare che è proprio nel momento in cui ti inserisco in un gruppo che ti sto autorizzando ad accedere. Sarebbe stato diverso se questo giornalista fosse riuscito a catturare quelle conversazioni senza appartenere a quel gruppo. La fiera dell'assurdo.

In altre parole, l'insicurezza di Signal per Elisabetta Rosso risiede nel fatto che il governo non possa introdurre trojan che intercettino le comunicazioni. E ripensando al pericolo cinese, è probabilmente proprio questo il motivo per cui è stato usato.

“Come bisognerebbe comunicare?”, domanda la giornalista dal profondo della sua sapienza. Chi vuole, legga anche quest'ultimo paragrafo. Aggiungo solo che, secondo lei, una comunicazione, per essere veramente sicura, deve anche consentire una supervisione interna. Quindi violabile.

È tutto molto divertente ed è evidente come i concetti di sicurezza possano essere molto diversi.

Wired dal canto suo è uno dei pochissimi che analizza la questione molto bene(Caso Signal, e se l’uso dell’app da parte dei vertici del governo Usa non fosse un errore?).

Tutto il resto che si trova in giro, per quello che ho potuto leggere, è un vero pianto.

#signal #sicurezza

]]> https://noblogo.org/aytin/signal-e-davvero-sicuro Sat, 29 Mar 2025 17:13:46 +0000 Pillole di Virtualbox https://noblogo.org/aytin/pillole-di-virtualbox <![CDATA[virtualbox VirtualBox è una buona soluzione di virtualizzazione, comoda per tirare su velocemente e con poco sforzo, piccoli laboratori di test anche relativamente articolati (cfr. fwknop: proteggere servizi con Single Packet Authorization (SPA)). !--more-- A differenza di kvm+qemu, VirtualBox è un hosted hypervisor (Tipo-2), meno efficiente ma con un'ottima cli che viene rimappata integralmente dalla gui. È uno di quei rari casi in cui l'uso di una gui non comporta perdita di funzionalità. La cli di VirtualBox e ben strutturata e ordinata e si basa fondamentalmente sul tool VBoxManage. VBoxManage a sua volta ha una lista infinita di sottocomandi con i quali coprono ogni aspetto della manipolazione di una vm, dalla sua creazione alla gestione di tutti i suoi dispositivi, passando per clonazion, snapshot, encrypting ecc. Di seguito, un elenco, assolutamente non esaustivo, dei principali comandi utilizzabili per avere informazioni sull'host o per agire in maniera elementare sulle vm (stop, start, savestate ecc..) Host info Elenca tutte le vm dell'host: VBoxManage list vms Elenca le vm in esecuzione: VBoxManage list runningvms Elenca le extension pack installate: VBoxManage list extpacks Elenca le info sull'host: VBoxManage list hostinfo Elenca le info dell'hypervisor: VBoxManage list systemproperties Installa l'extension pack scaricato sull'host: VBoxManage extpack install --accept-license=sha256 /tmp/OracleVirtualBoxExtensionPack-7.1.6.vbox-extpack VM operations Mostra le info della vm: VBoxManage showvminfo "debian" Restituisce lo stato della vm: VBoxManage controlvm "debian" status Pause vm: VBoxManage controlvm "debian" pause Resume vm: VBoxManage controlvm "debian" resume Restart vm: VBoxManage controlvm "debian" reboot Spegne la vm: VBoxManage controlvm "debian" poweroff Greaceful shutdown: VBoxManage controlvm "debian" acpipowerbutton Hibernate: VBoxManage controlvm savestate "debian" Avvio "headless" (senza finestra) della vm: VBoxManage startvm -t headless "debian" Avvio "headless" in modalità debug: VBoxHeadless -s Debian Ora vediamo qualcosa di leggermente più complesso come la creazione di una vm. Esempio Passo 1: Creare una vm con debian, disco da 20GB , scheda di rete nat , 1 cpu e 1 GB di ram. Passo 2: Clonazione della vm e aggiunta di una interfaccia host-only Creazion VM VBoxManage createvm --name "myDebian" --ostype "Debian1264" --register Configurazione ram e cpu VBoxManage modifyvm "myDebian" --memory 512 --cpus 1 Creazione HD da 20GB VBoxManage createhd --filename "~/VirtualBox VMs/myDebian/myDebian.vdi" --size 20000 --format VDI Creazione e attach del controller SATA VBoxManage storagectl "myDebian" --name "SATA Controller" --add sata --controller IntelAhci VBoxManage storageattach "myDebian" --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium "~/VirtualBox VMs/myDebian/myDebian.vdi" Configurazione rete (NAT) VBoxManage modifyvm "myDebian" --nic1 nat Aggiunta di un lettore CD per l'installer su iso VBoxManage storagectl "myDebian" --name "IDE Controller" --add ide VBoxManage storageattach "myDebian" --storagectl "IDE Controller" --port 0 --device 0 --type dvddrive --medium "~/VirtualBox VMs/iso/debian-12.8.0-amd64-netinst.iso" Start VM VBoxManage startvm "myDebian" -t headless E procedo con l'installazione. Una volta finito, posso clonarla aggiungendo la seconda interfaccia di rete. Clona la VM in modo che gli UUID di tutti gli oggetti clonati siano diversi VBoxManage clonevm "myDebian" --name "myDebianclone" --register --mode all Aggiungo una scheda di rete "Solo Host" VBoxManage hostonlyif create Configuro la rete "Solo Host" VBoxManage modifyvm "myDebian_clone" --nic2 hostonly --hostonlyadapter2 "vboxnet0" Si può capire quanto sia facile a questo punto "codificare" la creazione/gestione di una o più vm. Talmente facile che approdare ad un paradigma di tipo IAC (Infrastructure As Code) anche con VirtualBox non sembra così irrealizzabile. Qualcuno ha detto vagrant? #virtualbox #vm #hypervisor #kvm #qemu #vagrant ]]> virtualbox VirtualBox è una buona soluzione di virtualizzazione, comoda per tirare su velocemente e con poco sforzo, piccoli laboratori di test anche relativamente articolati (cfr. fwknop: proteggere servizi con Single Packet Authorization (SPA)). A differenza di kvm+qemu, VirtualBox è un hosted hypervisor (Tipo-2), meno efficiente ma con un'ottima cli che viene rimappata integralmente dalla gui. È uno di quei rari casi in cui l'uso di una gui non comporta perdita di funzionalità.

La cli di VirtualBox e ben strutturata e ordinata e si basa fondamentalmente sul tool VBoxManage. VBoxManage a sua volta ha una lista infinita di sottocomandi con i quali coprono ogni aspetto della manipolazione di una vm, dalla sua creazione alla gestione di tutti i suoi dispositivi, passando per clonazion, snapshot, encrypting ecc.

Di seguito, un elenco, assolutamente non esaustivo, dei principali comandi utilizzabili per avere informazioni sull'host o per agire in maniera elementare sulle vm (stop, start, savestate ecc..)

Host info

Elenca tutte le vm dell'host:

VBoxManage list vms

Elenca le vm in esecuzione:

VBoxManage list runningvms

Elenca le extension pack installate:

VBoxManage list extpacks

Elenca le info sull'host:

VBoxManage list hostinfo

Elenca le info dell'hypervisor:

VBoxManage list systemproperties

Installa l'extension pack scaricato sull'host:

VBoxManage extpack install --accept-license=sha256 /tmp/Oracle_VirtualBox_Extension_Pack-7.1.6.vbox-extpack

VM operations

Mostra le info della vm:

VBoxManage showvminfo "debian"

Restituisce lo stato della vm:

VBoxManage controlvm "debian" status

Pause vm:

VBoxManage controlvm "debian" pause

Resume vm:

VBoxManage controlvm "debian" resume

Restart vm:

VBoxManage controlvm "debian" reboot

Spegne la vm:

VBoxManage controlvm "debian" poweroff

Greaceful shutdown:

VBoxManage controlvm "debian" acpipowerbutton

Hibernate:

VBoxManage controlvm savestate "debian"

Avvio “headless” (senza finestra) della vm:

VBoxManage startvm -t headless "debian"

Avvio “headless” in modalità debug:

VBoxHeadless -s Debian

Ora vediamo qualcosa di leggermente più complesso come la creazione di una vm.

Esempio

Passo 1: Creare una vm con debian, disco da 20GB , scheda di rete nat , 1 cpu e 1 GB di ram. Passo 2: Clonazione della vm e aggiunta di una interfaccia host-only

# Creazion VM
VBoxManage createvm --name "myDebian" --ostype "Debian12_64" --register

# Configurazione ram e cpu
VBoxManage modifyvm "myDebian" --memory 512 --cpus 1

# Creazione HD da 20GB
VBoxManage createhd --filename "~/VirtualBox VMs/myDebian/myDebian.vdi" --size 20000 --format VDI

# Creazione e attach del controller SATA
VBoxManage storagectl "myDebian" --name "SATA Controller" --add sata --controller IntelAhci
VBoxManage storageattach "myDebian" --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium "~/VirtualBox VMs/myDebian/myDebian.vdi"

# Configurazione rete (NAT)
VBoxManage modifyvm "myDebian" --nic1 nat

# Aggiunta di un lettore CD per l'installer su iso
VBoxManage storagectl "myDebian" --name "IDE Controller" --add ide
VBoxManage storageattach "myDebian" --storagectl "IDE Controller" --port 0 --device 0 --type dvddrive --medium "~/VirtualBox VMs/iso/debian-12.8.0-amd64-netinst.iso"

# Start VM
VBoxManage startvm "myDebian" -t headless

E procedo con l'installazione. Una volta finito, posso clonarla aggiungendo la seconda interfaccia di rete.

# Clona la VM in modo che gli UUID di tutti gli oggetti clonati siano diversi
VBoxManage clonevm "myDebian" --name "myDebian_clone" --register --mode all

# Aggiungo una scheda di rete "Solo Host"
VBoxManage hostonlyif create

# Configuro la rete "Solo Host"
VBoxManage modifyvm "myDebian_clone" --nic2 hostonly --hostonlyadapter2 "vboxnet0"

Si può capire quanto sia facile a questo punto “codificare” la creazione/gestione di una o più vm.

Talmente facile che approdare ad un paradigma di tipo IAC (Infrastructure As Code) anche con VirtualBox non sembra così irrealizzabile.

Qualcuno ha detto vagrant?

#virtualbox #vm #hypervisor #kvm #qemu #vagrant

]]> https://noblogo.org/aytin/pillole-di-virtualbox Sat, 01 Mar 2025 17:45:03 +0000