Un’esigenza analoga, su un filesystem partizionato in 3 parti in maniera canonica, è un mezzo incubo perché il ridimensionamento della partizione centrale prevede un discreto numero di salti mortali per manenere la contiguità e per non rischiare di lasciare buchetti inutilizzabili fra una partizione e l’altra.

• 1. Cose che è bene ricordare quando si manipolano i volumi logici
• 2. Scenario 1: Estensione e riduzione di volumi logici
  • 2.1. Step 0: curiosità
  • 2.2. Step 1: Smontare i dischi
  • 2.3. Step 2: Riduzione del filesystem
  • 2.4. Step 3: Ridimensionare i volumi logici
  • 2.5. Step 4: Estendere il volume logico
  • 2.6. Step 5: Bonus
• 3. Scenario 2: Estensione e riduzione di gruppi di volume
• 4. Conclusione

Provo a buttare giù due righe su quello che mi verrebbe di fare:

1. riduco la prima partizione
2. riduco la terza partizione
3. sposto la terza partizione fino alla fine del disco
4. sposto la seconda partizione fino alla fine della prima partizione
5. estendo la seconda partizione fino alla fine della prima

Tutto questo tenendo presente che l’unità minima allocabile è il blocco (512 bytes) e che l’operazione che mi fa più paura è il move della partizione. parted non ha un comando “move” diretto. La procedura richiede di calcolare i nuovi settori, spostare i dati e aggiornare la tabella delle partizioni.

Senza una GUI come quella di gparted, bisogna farsi letteralmente i conti con carta e penna prima di agire e c’è il rischio, comunque molto alto, di commettere errori che sarebbero disastrosi.

LVM, al confronto, è una boccata d’ossigeno.

LVM dà la possibilità di ridimensionare volumi in maniera più semplice rispetto al partizionamento più tradizionale perché la dimensione della partizione è disaccoppiata da concetti di contiguità e dalla geometria del disco.

Nel caso del partizionamento tradizionale infatti le partizioni sono dei blocchi di settori consecutivi in cui ogni partizione inizia in un settore finisce in un altro.

Con LVM invece l’approccio è radicalmente diverso. La minima unità allocabile è l’extent (default 4 MiB) che serve per mappare un volume fisico in un volume logico.

Se immaginiamo che il volume fisico possa essere spezzettato in altrettanti extents in una sorta di “paniere”, il volume group, il volume logico non è altro che un insieme di questi extents pescati dal volume group (senza alcuna pretesa d’ordinamento) a cui posso:

• aggiungere extents prelevandoli dal volume group
• levare extents riponendoli nel volume group (o assegnandoli ad altri volumi logici).

Queste proprietà conferiscono una grande flessibilità alle operazioni di riduzione ed estensione dei volumi.

1. Cose che è bene ricordare quando si manipolano i volumi logici.

Partizioni Quando si riduce o aumenta un filesystem, è bene smontare le partizioni e volumi logici.

Ridurre un volume logico Quando si riduce un volume logico, si deve:

1. fare un check del filesystem
2. ridurre il filesystem
3. ridurre il volume logico

Estendere un volume logico Quando si aumenta un volume logico, al contrario, si deve:

1. estendere il volume logico
2. estendere il filesystem
3. fare un check del filesystem

Calcolare lo spazio allocabile Un volume logico è composto da un insieme di extents, blocchi grandi di default 4 MiB, che sono la minima unità allocabile. Un volume logico è quindi sempre corrispondente ad un multiplo di 4 MiB, n extents di cui n-1 allocabili, il rimanente per i metadati. Ad es. un volume logico di 2 GiB è composta da 512 extents di cui 511 allocabili.

La potenza di due Si deve tenere sempre presente che, nella matematica del calcolo dello spazio, si considerano le potenze di 2. Non di 10. Quindi un GiB equivale a 1024 MiB, non a 1000. Di conseguenza, se dividessi un GiB in due parti uguali avrei 2 blocchi da 512 MiB non da 500.

Estensione e riduzione Nelle istruzioni di estensione (lvextend) e riduzione (lvreduce) possiamo scegliere ciò che va specificato fra 4 modalità:

1. il numero totale di extents
2. il delta in aggiunta o in diminuzione degli extents (a seconde che l’operazione sia rispettivamente di estensione o di riduzione)
3. la dimensione totale espressa in KiB-MiB-GiB-TiB
4. come prima, il delta in aggiunta o in diminuzione della dimensione espresso in KiB-MiB-GiB-TiB

2. Scenario 1: Estensione e riduzione di volumi logici

Supponiamo di avere un disco da 2 GiB (2048 MiB) diviso in 3 volumi logici da 550 MiB, 350 MiB e 1148 MiB di e di volerne ridurre due per ampliare il terzo.

Vogliamo ridurre il primo di 150 MiB, il terzo di 330 MiB e aumentare corrispondentemente il secondo volume di 480 MiB.

Prepariamo il laboratorio col solito file appiccicato ad un loop device. Su quello definirò il volume group, il mio “paniere” di extents.

# creazione device
fallocate -l 2GiB disk_1.img

# creazione device e volum group
vgcreate vg_lab $(losetup -Pf --show disk_1.img)

# creazione volumi logici
lvcreate -n lv_lab_1 vg_lab -L 550M
lvcreate -n lv_lab_2 vg_lab -L 350M
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

# formattazione volumi logici
mkfs.ext4 /dev/vg_lab/lv_lab_1
mkfs.ext4 /dev/vg_lab/lv_lab_2
mkfs.ext4 /dev/vg_lab/lv_lab_3

# mount dei volumi
mkdir vol_1 vol_2 vol_3
mount -t ext4 -o defaults /dev/vg_lab/lv_lab_1 vol_1
mount -t ext4 -o defaults /dev/vg_lab/lv_lab_2 vol_2
mount -t ext4 -o defaults /dev/vg_lab/lv_lab_3 vol_3

2.1. Step 0: curiosità

Prima di cominciare esaminiamo un po’ di dati, ad es. di quanti extents sono composti i nostri oggetti.

pvdisplay /dev/loop9
  --- Physical volume ---
  PV Name               /dev/loop9
  VG Name               vg_lab
  PV Size               2,00 GiB / not usable 4,00 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              511
  Free PE               0
  Allocated PE          511
  PV UUID               YmLOru-bIdL-iqGb-vJfI-RsTk-yhv7-vSJhkX

pvdisplay mi dà informazioni sul disco fisico che andrò ad aggiungere nel volume group. Fra queste:

• PV Name: il nome del device, /dev/loop9
• VG Name: è il nome del gruppo di volume, vg_lab, visibile solo perché abbiamo creato il gruppo di volume direttamente sul dispositivo invece che passare prima da pvcreate.
• PV Size: 2 GiB, la dimensione del nostro “disco”
• PE Size: dove PE sta Physical Extent, è di 4 MiB
• Total PE sono i PE totali e sono 511, come previsto.

vgdisplay vg_lab
  --- Volume group ---
  VG Name               vg_lab
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <2,00 GiB
  PE Size               4,00 MiB
  Total PE              511
  Alloc PE / Size       0 / 0
  Free  PE / Size       511 / <2,00 GiB
  VG UUID               6D89ck-c2Ni-XlMN-5Was-rh5j-vi2t-5juCXt

vgdisplay mi dà informazioni sul gruppo di volumi. Fra queste, disitnguiamo

• VG Name: il nome del volume group, già visto in pvdisplay, vg_lab
• VG Size: la dimensione del volume group, minore di 2 GiB perché ci sono i metadati da considerari
• PE Size: la dimensione di un extent, 4 MiB
• Total PE / Size: Il numero totale di extent allocabili, che conferma VG Size, pari a 511 invece che 512.
• Alloc PE: il numero totale di extent allocati, momento della creazione del volume group è 0
• Free PE / Size: il numero totale di extent liberi, prima della creazione dei volumi logici è 511

Cosa succede quando creerò i volumi logici? Che cambia il numero di PE liberi e allocati. Siccome userò tutti gli extent disponibili, i valori per Alloc PE e Free PE si invertiranno rispetto a prima.

Infatti dopo la creazione dei volumi logici, vgdisplay mi dirà:

vgdisplay vg_lab
  --- Volume group ---
  VG Name               vg_lab
  ...
  Alloc PE / Size       511 / <2,00 GiB
  Free  PE / Size       0 / 0
  ...  

511 extents allocati come confermato dai dati desumibili dei 3 volumi logici

lvdisplay vg_lab
 --- Logical volume ---
  LV Path                /dev/vg_lab/lv_lab_1
  LV Name                lv_lab_1
  VG Name                vg_lab
...
  LV Size                552,00 MiB
  Current LE             138
...
 --- Logical volume ---
  LV Path                /dev/vg_lab/lv_lab_2
  LV Name                lv_lab_2
  VG Name                vg_lab
...
  LV Size                352,00 MiB
  Current LE             88
...
 --- Logical volume ---
  LV Path                /dev/vg_lab/lv_lab_3
  LV Name                lv_lab_2
  VG Name                vg_lab
...
  LV Size                1,11 GiB
  Current LE             285
...

Per il primo, il secondo e il terzo volume logico abbiamo rispettivamente:

• 138, 88, 285 extents corrispondenti a
• 552 MiB, 352 MiB e 1140 MiB (1,11 GiB)
• per un totale di 2044 MiB, al netto dei metadati.

Possiamo notare subito che le dimensioni non corrispondono a quanto indicato in lvcreate.

lvcreate -n lv_lab_1 vg_lab -L 550M
lvcreate -n lv_lab_2 vg_lab -L 350M
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

Questo succede perché vengono sempre approssimate all’extent più vicino. Ecco perché il primo e il secondo volume sono diventati di 552 (138 extents) e 352 MiB (88 extents).

Sempre ricordando la particolarità dei multipli di 4 MiB legati a LVM, anche la riduzione di 150 MiB e di 330 MiB dei due volumi saranno approssimate sempre all’extent più vicino (152 MiB=38 extents e 332=83 extents). Questo dettaglio si rivelerà fondamentale quando dovremo ridimensionare il filesystem.

Con questa rinnovata consapevolezza cominciamo a ridimensionare.

2.2. Step 1: Smontare i dischi

umount /dev/vg_lab/lv_lab_1
umount /dev/vg_lab/lv_lab_2
umount /dev/vg_lab/lv_lab_3

2.3. Step 2: Riduzione del filesystem

Se dovessi ridimensionare solo il filesystem, sarebbe sufficiente considerare dimensioni che siano potenze di 2 e non di 10.

Ma sapendo che sotto c’è un LVM, sappiamo che per mantenere l’allineamento fra filesystem e volumi logici, oltre che potenze di due le dimensioni devono essere anche multipli di 4MiB.

Ecco perché anche nel resize reale del filesystem non dovrò levare 150 MiB e 330 MiB ma 148 MiB (37 PE) e 328 (82 PE) (è buona norma approssimare per difetto all’extent più vicino per maggior prudenza) per un totale effettivo di 476 MiB (119 PE)

Il filesystem del primo volume sarà dunque di 552 MiB – 148 MiB = 404 MiB. Il filesystem del terzo volume sarà di 1140 MiB – 328 MiB = 812 MiB.

# check dei filesystem
e2fsck -f /dev/vg_lab/lv_lab_1
e2fsck -f /dev/vg_lab/lv_lab_2
e2fsck -f /dev/vg_lab/lv_lab_3

# Riduco il primo filesystem di 148 MiB
resize2fs /dev/vg_lab/lv_lab_1 404M

# Riduco il terzo filesystem di 328 MiB
resize2fs /dev/vg_lab/lv_lab_3 812M

2.4. Step 3: Ridimensionare i volumi logici

La riduzione del volume logico può essere fatta in 4 modi come sappiamo, ad es. sul primo volume:

# il numero totale di extents, 138 PE - 37 PE = 101 PE
lvreduce -l 101 /dev/vg_lab/lv_lab_1 #oppure

# il numero di exrtents da sottrarre, 38 PE
lvreduce -l -37 /dev/vg_lab/lv_lab_1 #oppure

# la dimensione totale da ottenere, 404 MiB
lvreduce -L 404M /dev/vg_lab/lv_lab_1 #oppure

# il numero di MiB da sottrarre, 148 MiB
lvreduce -L -148M /dev/vg_lab/lv_lab_1 #oppure

Per maggior chiarezza userò il size assoluto in modo da farlo corrispondere a resize2fs

# Riduco il primo volume logico di 148 Mib
lvreduce -L 404M /dev/vg_lab/lv_lab_1

# Riduco il terzo volume logico di 328 Mib
lvreduce -L 812M /dev/vg_lab/lv_lab_3

Verifichiamo quanti siano i PE residui

vgdisplay vg_lab | grep "Free  PE"
 Free  PE / Size       119 / 476,00 MiB

119 extents, come previsto.

2.5. Step 4: Estendere il volume logico

Dopo aver ridotto il primo e il terzo volume, non ci rimane che estendere il secondo in base alla scaletta indicata prima:

1. si estende il secondo volume logico
2. si estende il filesystem
3. si esegue il check fnale del filesystem

L’estensione del volume, come ormai ben sappiamo, non sarà di 480 MiB ma di 476 MiB (37 PE + 82 PE = 119 PE) per via degli arrotondamenti effettuati nella riduzione degli altri volumi logici.

# specifico gli extent che so essere residui
lvextend -l +119 /dev/vg_lab/lv_lab_2
# o, equivalentemente
# lvextend -L +476M /dev/vg_lab/lv_lab_2

# estendo il filesystem
resize2fs /dev/vg_lab/lv_lab_2 828M

# check filesystem
e2fsck -f /dev/vg_lab/lv_lab_2

2.6. Step 5: Bonus

Come premio per essere arrivato in fondo, posso rivelare come fare in un colpo solo tutte le operazioni descritte sopra.

È vero che c'è poco da considerare, giusto tenere a mente che su LVM ogni oggetto è multiplo di 4 MiB e che bisogna ridimensionare filesystem e volumi logici in ugual modo per non generare pericolose anomalie, ma tutte le operazioni che ho descritto nei passi 2-4 possono essere fatte con un unico comando che provvederà ad eseguire nell'ordine corretto e con le giuste approssimazioni:

• il check del filesystem
• il ridimensionamento del filesystem
• il ridimensionamento dei volumi logici

Dunque, tutto il pippone atomico precedente può essere condensato in un unico, solido comando:

# Riduce il primo volume logico e il filesystem
lvreduce -r -L -150M /dev/vg_lab/lv_lab_1

# Riduce il terzo volume logico e il filesystem
lvreduce -r -L -330M /dev/vg_lab/lv_lab_3

# Estende il secondo volume logico e il filesystem
lvextend -r -l +119 /dev/vg_lab/lv_lab_2

Ora spieghiamo il perché soprattutto dell'extend, che è interessante.

Diciamo che è tutto molto guidato e le eventuali correzioni da apportare, senza spaccarsi troppo il cervello, sono suggerite con estrema chiarezza, basta leggere.

lvreduce -r -L -150M /dev/vg_lab/lv_lab_1
 Rounding size to boundary between physical extents: 148.00 MiB.
  File system ext4 found on vg_lab/lv_lab_1.
  File system size (552.00 MiB) is larger than the requested size (404.00 MiB).
  File system reduce is required using resize2fs.
...
  Size of logical volume vg_lab/lv_lab_1 changed from 552.00 MiB (138 extents) to 404.00 MiB (101 extents).
  Logical volume vg_lab/lv_lab_1 successfully resized.

Ci dice innanzitutto che:

• c'è stato un arrotondamento a 148 MiB (37 extents);
• il filesystem è più grande del volume richiesto pertanto va subito ridimensionato;
• infine si ridimensiona il volume logico da 552 MiB (138 extents) a 404 MiB (101 extents).

Anche il secondo lvreduce ha un risultato analogo

lvreduce -r -L -330M /dev/vg_lab/lv_lab_3
  Rounding size to boundary between physical extents: 328.00 MiB.
  File system ext4 found on vg_lab/lv_lab_3.
  File system size (1.11 GiB) is larger than the requested size (812.00 MiB).
  File system reduce is required using resize2fs.
...
  Size of logical volume vg_lab/lv_lab_3 changed from 1.11 GiB (285 extents) to 812.00 MiB (203 extents).
  Logical volume vg_lab/lv_lab_3 successfully resized.

• anche qui abbiamo un arrotondamento a 328 MiB (82 extents);
• il filesystem è più grande del volume richiesto pertanto va subito ridimensionato;
• infine si ridimensiona il volume logico da 1140 MiB (285 extents) a 812 MiB (203 extents).

È facilissimo desumere che la massima dimensione dell'estensione sia 148 MiB + 328 MiB = 476 MiB (119 extents), basta fare una somma.

Ma supponiamo di essere particolarmente distratti e proviamo ad estendere considerando le quantità iniziali: 150 MiB + 330 MiB = 480 MiB

lvextend -r -L +480M /dev/vg_lab/lv_lab_2
  File system ext4 found on vg_lab/lv_lab_2.
  File system fsck will be run before extend.
  Insufficient free space: 120 extents needed, but only 119 available

Nonostante la mia distrazione, come si può vedere, non si producono danni perché l'ouput è categorico: “non faccio nulla. Se vuoi, puoi aumentare al max di 476 MiB (119 extents)”. Non ci sono danni e anzi c'è pure il suggerimento risolutivo.

Ed ecco spiegato il mio extend di prima.

3. Scenario 2: Estensione e riduzione di gruppi di volume

Esaminiamo le possibilità di aggiungere o rimuovere dispositivi ad un volume group esistente.

Ricreiamo il laboratorio partendo da 3 dischi, poi aggiungeremo due nuovi dischi e ne rimuoveremo altrettanti, il tutto senza intaccare l'integrità dei dati.

# creazione di 5 device
for i in {1..9}: do fallocate -l 1GiB disk_${i}.img; done

# creazione del gruppo di volumi con 3 device
vgcreate vg_lab \
  $(losetup -Pf --show disk_1.img) \
  $(losetup -Pf --show disk_2.img) \
  $(losetup -Pf --show disk_3.img)

# crezione di 3 volumi logici
lvcreate -n lv_lab_1 vg_lab -l 300
lvcreate -n lv_lab_2 vg_lab -l 250
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

# formattazione dei 3 dispositivi
mkfs.ext4 /dev/vg_lab/lv_lab_1
mkfs.ext4 /dev/vg_lab/lv_lab_2
mkfs.ext4 /dev/vg_lab/lv_lab_3

Ecco come sono distribuiti i volumi logici all'interno dei dischi fisici

lsblk -o NAME,FSTYPE,SIZE,TYPE
  NAME               FSTYPE        SIZE      TYPE
  loop9              LVM2_member     1G      loop
  └─vg_lab-lv_lab_1                1,2G      lvm
  loop10             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_1                1,2G      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop11             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_2               1000M      lvm
  └─vg_lab-lv_lab_3                860M      lvm

Il gruppo di volumi è composto da 3 volumi fisici tutti attivi

vgdisplay vg_lab |grep PV
  Max PV                0
  Cur PV                3
  Act PV                3

Andiamo ad estendere il nostro gurppo di volumi con altri due device

vgextend vg_lab $(losetup -Pf --show disk_4.img) $(losetup -Pf --show disk_5.img)

I nuovi dischi sono visibili in fondo, come si può vedere anche da vgdisplay che mostra i 5 dischi tutti attivi.

lsblk -o NAME,FSTYPE,SIZE,TYPE
  NAME               FSTYPE        SIZE      TYPE
  loop9              LVM2_member     1G      loop
  └─vg_lab-lv_lab_1                1,2G      lvm
  loop10             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_1                1,2G      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop11             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_2               1000M      lvm
  └─vg_lab-lv_lab_3                860M      lvmchan
  loop12             LVM2_member     1G      loop
  loop13             LVM2_member     1G      loop

vgdisplay vg_lab |grep PV
  Max PV                0
  Cur PV                5
  Act PV                5

Potremo usare i nuovi dischi per estendere i volumi logici esistenti ma li impiegheremo invece per rimpiazzare i primi due dischi.

pvmove distribuisce tutti gli extents del disco fra tutti i volumi fisici che hanno spazio a sufficienza. Se non dovesse essercene, restituirà un messaggio d'errore.

pvmove /dev/loop9
  /dev/loop9: Moved: 3,14%
  /dev/loop9: Moved: 100,00%

Alla fine dell'operazione il disco s'è liberato di tutti i suoi extents e può essere rimosso

lsblk -o NAME,FSTYPE,SIZE,TYPE
  NAME               FSTYPE        SIZE      TYPE
  loop9              LVM2_member     1G      loop
  loop10             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_1                1,2G      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop11             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_2               1000M      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop12             LVM2_member     1G      loop
  └─vg_lab-lv_lab_1                1,2G      lvm
  loop13             LVM2_member     1G      loop

Prima si estrae il volume fisico dal gruppo di volumi e poi si rimuove il volume fisico e così può essere scollegato.

vgreduce vg_lab /dev/loop9
pvremove /dev/loop9

Verifichiamo che il volume fisico non sia più presente.

vgdisplay vg_lab |grep PV
  Max PV                0
  Cur PV                4
  Act PV                4

Procediamo allo stesso modo col secondo disco.

pvmove /dev/loop10
  /dev/loop10: Moved: 9,80%
  /dev/loop10: Moved: 17,65%
  /dev/loop10: Moved: 100,00%

vgreduce vg_lab /dev/loop10
  Removed "/dev/loop10" from volume group "vg_lab"

pvremove /dev/loop10
  Labels on physical volume "/dev/loop10" successfully wiped.

In conclusione possiamo vedere il gruppo di volumi con solo 3 dischi, gli altri due completamente disimpegnati col gruppo di volumi ricostituitosi attorno ai 3 dischi rimanenti. E tutto spostando semplicemente gli extents dove c'era disponibilità in maniera totalmente trasparente per il filesystem.

vgdisplay vg_lab |grep PV
  Max PV                0
  Cur PV                3
  Act PV                3


lsblk -o NAME,FSTYPE,SIZE,TYPE
  NAME               FSTYPE        SIZE      TYPE
  loop9                              1G      loop
  loop10                             1G      loop
  loop11             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_2               1000M      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop12             LVM2_member     1G      loop
  └─vg_lab-lv_lab_1                1,2G      lvm
  loop13             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_1                1,2G      lvm
  └─vg_lab-lv_lab_3                860M      lvm

4. Conclusione

Ho solo sfiorato la complessità e le capacità offerte da LVM.

L'estensione e la riduzione di volumi logici e di gruppi di volumi sono scenari di base. Tuttavia sono sufficienti per mostrare come sia semplice, con i volumi logici, compiere operazioni che con un filesystem partizionato in maniera classica sarebbero complicatissime.

#lvm #volumegroup #logicalvolume #filesystem #devicemapper

• 1. Cos’è la normalizzazione
• 2. Come misurare il “picco”?
• 3. Come leggere correttamente questa misura
  • 3.1. Perché usare il loudness invece di RMS?
• 4. Come ti normalizzo il file
  • 4.1. Peak normalization
  • 4.2. Loudness Normalization
    • 4.2.1. Loudness Normalization statica (ffmpeg)
    • 4.2.2. Loudness Normalization dinamica
    • 4.2.3. Loudness Normalization statica (rsgain)

1. Cos'è la normalizzazione

La normalizzazione è un'operazione lineare che consiste nell'analisi del file audio, nel calcolare la differenza (offset) fra il volume attuale ed un volume target, nell'applicare una correzione di guadagno (Gain).

La normalizzazione può essere distinta in base al “come” e al “dove”.

Il “come” La normalizzazione classica si basa sui picchi. Cerca il punto più alto della forma d'onda e lo porta a un valore massimo (es. 0 dB). Ignora la percezione umana; un brano con un singolo “click” molto forte risulterà comunque silenzioso perché quel picco blocca l'aumento del volume.

La normalizzazione più moderna si basa sui LUFS, ossia su come, mediamente, l'audio viene effettivamente percepito dall'orecchio umano (psicoacustica). Porta l'intero brano a un livello di pressione sonora media costante, rendendo l'ascolto uniforme tra diverse tracce.

Il “dove” Quando si normalizza una traccia audio si può scegliere di farla modificando ogni singolo sample della traccia audio oppure di agire sui metadati.

Nel primo caso il file originale viene modificato (ricodifica quasi sempre lossy), nel secondo viene lasciato inalterato.

Altro fattore di cui tenere conto è che una normalizzazione lossy funziona su ogni player, una normalizzazione che agisce sui metadati funziona solo se il player è in grado di leggerli.

Possiamo fare quindi una prima distinzione:

1. normalizzazione di picco (RMS) o Peak Normalization: applicazione di un guadagno statico (RMS) in modalità lossy: non altera la dinamica del brano, richiede una ricodifica;
2. normalizzazione della sonorità (LUFS) o Loudness Normalization:
   1. applicazione di un guadagno statico (LUFS) in modalità lossy: non altera la dinamica del brano, richiede una ricodifica;
   2. applicazione di un guadagno statico (LUFS) basato su tag: non altera la dinamica del brano, lascia il file inalterato (rsgain);
   3. agisce con un compressore / limiter in modalità lossy: altera la dinamica del brano, richiede una ricodifica.

A questo punto la domanda diventa: quale scegliere?

Per quel che mi riguarda, la salomonica risposta è: dipende.

Come si può immaginare, non c'è una risposta definitiva ma dipende dalla qualità della traccia, dal contesto ecc.

2. Come misurare il “picco”?

C'è bisogno di un elemento misurabile che mi permetta di capire come agire con la normalizzazione.

RMS (Root Mean Square): è un calcolo matematico asciutto su quanto sia potente elettricamente/digitalmente il segnale audio. È utile per capire l'energia costante, ma non tiene conto del fatto che l'orecchio umano è più sensibile ad alcune frequenze rispetto ad altre.

LUFS (Loudness Units Full Scale): È lo standard moderno (EBU R128). Simula l'udito umano applicando dei filtri che pesano maggiormente le frequenze medie.

Per misurare il picco RMS posso ricorrere ad ffmpeg

ffmpeg -hide_banner -i "audio.m4a" -filter:a "volumedetect" -f null -
...
[...] n_samples: 18522112
[...] mean_volume: -20.3 dB
[...] max_volume: -5.4 dB
[...] histogram_5db: 40
[...] histogram_6db: 1436
[...] histogram_7db: 6443
[...] histogram_8db: 18606
...

che mi mostrerà:

• il numero dei samples di cui si compone la traccia
• il volume medio (mean_volume)
• il picco (max_volume)

Il picco mi dice di quanto possa alzare il volume (fino al limite fisico di 0dB) staticamente senza causare distorsioni.

La differenza fra volume medio e picco mi dà informazioni sulla dinamica del brano. Maggiore è la differenza, maggiore è la dinamica. Tipicamente:

• valori < 5 sono tipici della musica dance, forte, uniforme, e molto compressa.
• valori fra 5 e 15 sono tipici di brani pop-rock, ben bilanciati
• valori > 15 sono attribuibili a brani di musica classica, jazz, con una dinamica ricca.

Per misurare il loudness, sempre con ffmpeg:

ffmpeg -hide_banner -i "audio.m4a" -filter:a "ebur128=peak=true" -f null - 
...
 Integrated loudness:
    I:         -18.1 LUFS
    Threshold: -28.4 LUFS

  Loudness range:
    LRA:         4.1 LU
    Threshold: -38.3 LUFS
    LRA low:   -21.2 LUFS
    LRA high:  -17.1 LUFS

  True peak:
    Peak:       -5.4 dBFS

La misurazione è più articolata rispetto alla precedente.

FFmpeg innanzitutto mostra due sezioni: Integrated Loudness, rappresentante il volume medio complessivo del file e la Loudness Range che mi descrive la dinamica del brano come differenza di volume fra le parti più silenziose e quelle più rumorose.

1. Sezione Integrated loudness:
   • I: è il valore più importante. È il volume medio percepito dell'intero brano (come si può vedere, diverso rispetto all'RMS di prima. Il primo è pura potenza digitale, il secondo è volume percepito).
   • Threshold: è la soglia usata per evitare che i silenzi abbassino artificialmente la media del volume. L'algoritmo ignora tutto ciò che sta sotto questa soglia nel calcolo dell'Integrated Loudness.
2. Sezione Loudness range:
   • LRA: è un indice della variazione dinamica del brano. Più è basso, più il suono tende ad essere uniforme e probabilmente compresso
   • Threshold: come prima, è la soglia oltre la quale i suoni vengono ignorati nel calcolo del range dinamico.
   • LRA Low: indica il limite inferiore del loudness
   • LRA High: indica il limite superiore
     quindi LRA = LRA High – LRA Low
3. Sezione True peak:
   • Peak: Simile al max_volume dell'RMS, indica il picco reale del brano in termini di sonorità.

Un altro modo, forse meno pratico ma decisamente più scenografico, per analizzare un file audio è questo:

ffplay -f lavfi -i "amovie=audio.m4a,ebur128=video=1:meter=18 [out0][out1]"

Disegna un grafico dell'onda sonora in tempo reale.

3. Come leggere correttamente questa misura

L'integrated loudness mi dice qual è il volume medio del brano. True peak mi dice di quanto posso alzare prima di distorcere. Queste sono le due informazioni cruciali sufficienti per applicare un guadagno statico senza fare danni.

I valori High e Low del Loudness Range, che racchiudono asintoticamente il brano, tornano utili quando bisogna agire sulla dinamica.

Notare che Integrated loudness è sempre compreso fra LRA Low e LRA High.

3.1. Perché usare il loudness invece di RMS?

L'RMS è un calcolo puramente matematico che non tiene conto del fatto che l'orecchio umano è molto più sensibile alle frequenze medie che non ai bassi estemi e agli acuti altissimi.

A questo provvede il LUFS che è un'evoluzione dell'RMS perché include dei filtri di ponderazione che, prima di calcolare la media, esaltano le frequenze medie attenuando quelle basse.

La conseguenza è che se agisco sul volume dei brani prendendo LUFS come riferimento, questi suoneranno tutti allo stesso volume. Se considerassi un adeguamento basato su RMS, i brani con più bassi sembreranno avere meno volume di quelli con frequenze medie più marcate.

4. Come ti normalizzo il file

La scelta fra una normalizzazione di picco e una di volume (loudness) è abbastanza semplice in realtà.

A parte poche eccezioni in cui può avere senso avere RMS come riferimento, è sempre preferibile una normalizzazione della sonorità.

Quest'ultima può essere fatta modificando solo i metadati o agendo chirurgicamente sul file ricodificandolo.

4.1. Peak normalization

Una volta noti i dati di Max Volume e Mean Volume visti in precedenza, la normalizzazione è piuttosto semplice.

Supponendo Max Volume = 6dB

ffmpeg -i audio.m4a -filter:a "volume=6dB" -c:a aac -b:a 192k audio_normalized.m4a

Dovendo ricodificare, scelgo un bitrate piuttosto alto per limitare la perdita fisiologica di una ricodifica lossy.

Come si può immaginare, è una aggiunta lineare secca a tutta la traccia a cui aumento solo la potenza digitale senza tenere conto della percezione sonora.

Piccola nota: Conviene scegliere un valore che si avvicini, ma non equivalga, al limite di 0 dB perché altrimenti FFmpeg taglierà brutalmente le creste dell'onda sonora che superano lo zero, creando quella tipica distorsione metallica grattata chiamata clipping.

4.2. Loudness Normalization

La normalizzazione di volume, in base alla nostra scelta di alterare o meno la dinamica del brano, può essere fatta come detto applicando:

• un guadagno statico LUFS (lossy)
• un guadagno statico LUFS sui metadati (non lossy)
• compressore / limiter (sempre lossy)

Il guadagno statico, quello con i metadati, avverrà con rsgain.

La normalizzazione con perdita di qualità (lossy) avverrà con ffmpeg usando il filtro loudnorm che dispone di un compressore/limiter piuttosto efficace.

Questo filtro è un processore dinamico (dual-pass o single-pass). Non si limita ad alzare il volume; se trova una parte troppo forte, può comprimere leggermente solo quella parte per permettere al resto della canzone di suonare più forte.

loudnorm porta il loudness di default a -24 LUFS che è lo standard per il broadcast televisivo.

I colossi dello streaming applicano automaticamente un loudness decisamente più marcato, salvo poche eccezioni, non si discostano da -14 LUFS. Ad es. Youtube, Amazon Music, Spotify, Soundcloud viaggiano mediamente su -14 LUFS, Deezer -15, Apple Music -16.

Si può verificare facilmente, come sappiamo fare, come un audio presente su una di queste piattaforme, abbia uno dei loudness indicati.

4.2.1. Loudness Normalization statica (ffmpeg)

Riprendiamo l'esempio di prima.

ffmpeg -hide_banner -i "audio.m4a" -filter:a "ebur128=peak=true" -f null - 
...
 Integrated loudness:
    I:         -18.1 LUFS
    Threshold: -28.4 LUFS

  Loudness range:
    LRA:         4.1 LU
    Threshold: -38.3 LUFS
    LRA low:   -21.2 LUFS
    LRA high:  -17.1 LUFS

  True peak:
    Peak:       -5.4 dBFS

Con ffmpeg e loudnorm in modalità single-pass, posso applicare un guadagno statico 5.4 dBFS, con un true peak di -1 (Il default è -2), per arrivare, da -18.1 LUFS, a -13.0 LUFS senza distorsioni.

ffmpeg -i audio.m4a -filter:a "loudnorm=I=-12.7:TP=-1.0" -c:a aac -b:a 160k -vn audio_norm.m4a

Verifichiamo:

ffmpeg -hide_banner -i "audio.m4a" -filter:a "ebur128=peak=true" -f null - 
...
   Integrated loudness:
    I:         -12.5 LUFS
    Threshold: -22.6 LUFS

  Loudness range:
    LRA:         4.0 LU
    Threshold: -32.6 LUFS
    LRA low:   -15.1 LUFS
    LRA high:  -11.1 LUFS

  True peak:
    Peak:       -0.4 dBFS
...

Come si vede, sono arrivato al limite, forse un po' troppo, del guadagno che potevo ottenere. Probabimente su dispositivi economici, l'analogico di un brano così potrebbe gracchiare un po'.

Se avessi applicato il default di loudnorm, la sonorità sarebbe stata livellata sui -24 LUFS con una soglia true peak pari a -2 dBFS.

4.2.2. Loudness Normalization dinamica

Nei casi in cui:

• si vuole enfatizzare l'audio di un podcast, di un parlato in generale;
• la dinamica del brano è composta da picchi altissimi e una sonorità media molto bassa (un guadagno statico farebbe cambiare poco o nulla)

con ffmpeg e loudnorm possiamo correggere ogni singolo sample del brano per rendere la dinamica più uniforme.

Per ottenere un risultato ottimale, si deve procedere col dual-pass, in cui ffmpeg nel primo passaggio analizza il file e raccoglie i dati, nel secondo passaggio applica le correzioni puntualmente avendo già conoscenza della dinamica e dei picchi presenti nel file.

ffmpeg -i "audio.m4a" -filter:a "loudnorm=I=-14:TP=-1.0:print_format=json" -f null -

Ecco il json risultante dall'analisi. I valori di input sono quelli che forniremo a ffmepg affinché possa impostare il loudness scelto da noi nel miglior modo possibile

{
	"input_i" : "-18.17",
	"input_tp" : "-5.41",
	"input_lra" : "4.20",
	"input_thresh" : "-28.47",
	"output_i" : "-13.36",
	"output_tp" : "-1.00",
	"output_lra" : "4.30",
	"output_thresh" : "-23.50",
	"normalization_type" : "dynamic",
	"target_offset" : "-0.64"
}

Configurazione ffmpeg.

ffmpeg -i "audio.m4a" -filter:a "loudnorm=I=-14:TP=-1.0:measured_I=-18.17:measured_TP=-5.41:measured_LRA=4.20:measured_thresh=-23.50:linear=true" -c:a aac -b:a 160k -vn "audio_norm.m4a"

Il compressore/limiter del filtro loudnorm è abbastanza intelligente da schiacciare i picchi affinche il guadagno di volume non produca clipping e alzerà le parti più “deboli”, livellando il suono e alterando la dinamica.

4.2.3. Loudness Normalization statica (rsgain)

Rsgain permette di applicare un guadagno statico loseless, senza ricodifica, agendo sui metadati del brano con l'applicazione dei tag.

Se da un lato questo metodo ha l'indubbio vantaggio di non alterare fisicamente il file, dall'altro è necessario che il player che eseguirà il brano dovra essere capace di leggere e interpretare i tag. Nel caso precedente, la ricodifica rende il file disponibile per chiunque.

Trattandosi di un guadagno statico, il campo d'applicazione è quello visto per la Peak Normalization, cioè quando si vuole preservare la dinamica del brano, Ma nei casi particolari cui accennavo in precedenza, presenza di picchi altissimi e maggioranza sonorità medie molto basse, anche rsgain non è sufficiente.

Come avevo detto all'inizio, rsgain è una normalizzaziome della sonorità ottenuta agendo sui metadati del brano, applicando dei tag, che così non viene alternato in alcun modo.

Rsgain è l'evoluzione del vecchio mp3gain e come il suo predecessore ha due modalità di lavoro

• sul singolo brano (detta é custom)
• su collezioni di brani (detta easy)

La modalità custom è considerato un approccio legacy fatta per intervenire puntualmente sul brano con configurazioni ad-hoc ideali per lo scripting, quella easy, basata su presets, permette di normalizzare intere collezioni di brani che è lo scopo principale di rsgain.

Analisi del file

rsgain custom -t audio.m4a
[✔] Scanning 'audio.m4a'
[✔] Container: QuickTime / MOV [mov,mp4,m4a,3gp,3g2,mj2]
[✔] Stream #0: AAC (Advanced Audio Coding), 44.100 Hz, 2 ch
 100% [====================================================]

Track: audio.m4a
  Loudness:   -18.12 LUFS
  Peak:     0.536630 (-5.41 dB)
  Gain:         0.12 dB

il flag -t individua il true peak

• Loudness: è la sonorità del brano in LUFS
• Peak: è il true peak, esprime il guadagno che posso ottenere prima di distorcere
• Gain: è il guadagno per arrivare allo standard LUFS di rsgain che è -18

Nel nostro caso, Gain ci dice di diminuire di 0.12 LUFS mentre Peak ci dice che potrei aumentare di 5.41 LUFS

Gain

rsgain custom -s i -l -13 -c p audio.m4a
Track: audio.m4a
  Loudness:   -18.12 LUFS
  Peak:     0.534149 (-5.45 dB)
  Gain:         5.12 dB

• -s i: scrive il tag
• -l -13: imposta il loudness
• -c p: protezione clipping

Portando il loudness a -13 è come se avessi aumentato il volume di 5,12 dB mantenendo un cuscinetto di -0.33 dB (differenza fra peak e gain).

Se provassi a spingere di più, il flag -c p impedisce al suono di distorcere.

rsgain custom -s i -l -10 -c p audio.m4a
Track: audio.m4a
  Loudness:   -18.12 LUFS
  Peak:     0.534149 (-5.45 dB)
  Gain:         5.45 dB  (adjusted to prevent clipping)

“(adjusted to prevent clipping)” è la conferma che la protezione anti-clipping è entrata in azione.

Se non ci fosse stata:

rsgain custom -s i -l -10 audio.m4a
Track: audio.m4a
  Loudness:   -18.12 LUFS
  Peak:     0.534149 (-5.45 dB)
  Gain:         8.12 dB

La differenza fra peak e gain indica un'evidente distorsione.

Esempio di esecuzione del brano sfruttando il replaygain:

mpv --replaygain=track audio.m4a

Senza il flag --replaygain=track, il brano verrebbe letto normalmente.

Cancellazione del tag Basta cancellare il tag per riportare tutto alla normalità

# verifico la presenza del tag prima
ffprobe -hide_banner -i "audio.m4a" 2>&1 | grep -i "replaygain"
REPLAYGAIN_TRACK_GAIN: 8.12 dB
REPLAYGAIN_TRACK_PEAK: 0.534149
replaygain: track gain - 8.120000, track peak - 0.000012, album gain - unknown, album peak - unknown,

# cancello il tag
rsgain custom -s d audio.m4a

# verifico che il tag non si ci sia più
ffprobe -hide_banner -i "audio.m4a" 2>&1 | grep -i "replaygain"
**

Un altro modo più compatto per verificare la presenza del tag:

ffprobe -i "audio.m4a" -show_entries format_tags=REPLAYGAIN_TRACK_GAIN -v quiet -of csv="p=0"

Se c'è il tag, mostra solo il gain.

Easy mode I flag impostati nella modalità custom nella modalitò easy sono affidati ad un file di configurazione.

Su Gnu/Linux i file di default si trovano in /usr/share/rsgain/presets e sono 4

• default.ini
• ebur128.ini
• loudgain.ini
• no_album.ini

C'è una sezione globla e delle sezioni specifiche per tipo di file.

L'override di queste configurazioni o la creazione di nuove, si fa in:

~/.config/rsgain/presets

e per la corrispondenza campi – flag custom vi rimando alla documentazione: https://github.com/complexlogic/rsgain?tab=readme-ov-file#scan-presets

Una volta deciso il preset che fa per noi, basta chiamare rsgain su una directory in questo modo:

rsgain easy -s <nome_preset> <path_album>

rsgain farà la scansione e applicherà massivamente le configurazioni che potranno consistere per es.:

• nell'applicazione di un loudness a tutti i brani per uniformare la sonorità;
• nella cancellazione di tutti i tag;
• nell'analisi dei brani;
• ecc.

Esempio di file di configurazione per una scansione

[Global]
TagMode=s
Album=true
TargetLoudness=-18
ClipMode=p
MaxPeakLevel=-1.0
TruePeak=true
Lowercase=false
ID3v2Version=keep
OpusMode=d
PreserveMtimes=false
DualMono=false

In questo modo rsgain produrrà un'analisi in modalità “album” per tutta la collezione, il gain da applicare all'album e una sintesi sulla media dei valori di picco ottenuti.

rsgain easy -p scan <path_album> 
...
Track: <path_album>/track_1
  Loudness:   -17.80 LUFS
  Peak:     0.743221 (-2.58 dB)
  Gain:        -0.20 dB


Track: <path_album>/track_2
  Loudness:   -17.81 LUFS
  Peak:     0.790007 (-2.05 dB)
  Gain:        -0.19 dB


Track: <path_album>/track_3
  Loudness:   -17.47 LUFS
  Peak:     0.834655 (-1.57 dB)
  Gain:        -0.53 dB

...

Album:
  Loudness:   -16.51 LUFS
  Peak:     0.991804 (-0.07 dB)
  Gain:        -1.49 dB


Scanning Complete
Time Elapsed:      00:00:27
Files Scanned:     18
Clip Adjustments:  0 (0.0% of files)
Average Loudness:  -16.61 LUFS
Average Gain:      -1.39 dB
Average Peak:      0.823503 (-1.69 dB)
Negative Gains:    16 (88.9% of files)
Positive Gains:    2 (11.1% of files)

L'ultima sezione, “Album”, mi dà le informazioni sul guadagno da applicare, in questo caso poco o nulla perché sono brani già normalizzati,.

Con un altro presets, ad es. myGain.ini, posso normalizzare tutto l'album in colpo solo.

rsgain easy -p myGain <path_album>

In altre parole, tutto ciò che la modalità custom affida allo scripting, ora viene automatizzata dalla modalità easy.

Riferimenti:

• https://ffmpeg.org/ffmpeg-filters.html#loudnorm
• https://ffmpeg.org/ffmpeg-filters.html#toc-volumedetect
• https://github.com/complexlogic/rsgain

#ffmpeg #rsgain #loudness #loudnorm

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 Cloudflare 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 delle 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

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.

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.

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 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

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.

• 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.

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 p₁, deve essere impossibile trovare un'altra password p₂ t.c. H(p₁) = H(p₂) (resistenza debole alle collisioni)
3. resistenza alle collisioni: è impossibile trovare due password diverse, p₁ e p₂, t.c. H(p₁) = H(p₂) (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

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)
  • 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 = log₂ ( R^L ) = L * log₂ ( 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 R^L è 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 2^E = R^L, 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 * log₂ ( 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) è 2^E = R^L.

• 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 2^E risposte (percorro tutti i cammini dell'albero) equivalente proprio a R^L.

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:

S_p = R^L = 66²⁰ = 2,46 * 10³⁶

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 (10¹⁸) 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 * 10¹⁸ ) H/s. Per algoritmi come bcrypt o argon2, progettati per essere molto dispendiosi, tale potenza si riduce drasticamente di molti ordini di grandezza. Da 10¹⁸ a 10⁹ – 10⁶. 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 S_p lo spazio di possibilità (il numero di possibili combinazioni), il tempo T espresso in secondi necessario ad eseguire tutte le operazioni sarà:

S_p = 66²⁰ = 2,46 * 10³⁶

T = 2,46 * ³⁶ / 1,5 * 10¹⁸ = 1,64 * 10¹⁸

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 2¹²⁰

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 R^L, 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² < 90%: La sequenza è considerata casuale. Il 50% è il valore “perfetto”.
• chi² < 1% o chi² > 99%: È quasi certamente non casuale.
  • chi² = 99.99%: i dati sono sospettosamente regolari;
  • chi² = 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 2²⁴-1. Se normalizziamo questo numero dividendolo per 2²⁴, 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:

X² + Y² ≤ 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 6⁵ 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 * log₂ R = 6 * log₂ 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

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
• 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/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

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.

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.

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.

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