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

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

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

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

Indice

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

Premessa

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

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

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

Una chiave gpg, in definitiva, è costituita da:

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

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

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

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

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

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

Gestione della chiave

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

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

Creazione della chiave primaria

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

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

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

Ecco la chiave appena creata, nella prima riga distinguiamo:

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

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

Una sintassi più completa sarebbe:

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

Per avere una lista degli algo:

gpg --with-colons --list-config

Aggiungere una sottochiave

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

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

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

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

Meccanismi di indirizzamento per una chiave

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

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

• 0xE01BDCB6A3C6778B è il key ID della master key
• 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B è il fingerprint della master key
• gandalf è uno degli uid

Aggiungere un uid

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

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

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

Firmare una chiave

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

Convalida tutti gli uid della chiave identificata da <fpr>

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

Convalida un uid specifico della chiave identificata da <fpr>

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

Modificare la password

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

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

Modificare la scadenza

Modifico le scadenze delle chiavi come segue:

• la master key da illimitata a 10 anni
• la sottochiave di firma da 5 anni a 4 anni
• la sottochiave di cifratura da 1 anno a 2 anni

# gpg --quick-set-expire <fpr> <expire>
gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 10y
gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 4y 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB
gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 2y 4DD33D36C54E2247486C9DC7AAEF649D51D832E8

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

Cancellazione di elementi dal keyring

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

Cancellare una sottochiave

Cancella la sottochiave di firma

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

Cancellare un uid

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

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

Cancellare una firma

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

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

Operazioni di revoca

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

Revocare un uid

Revoco l'uid (gandalf il grigio),

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

Revocare una sottochiave

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

Revocare una nostra certificazione

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

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

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

Posso anche revocare la mia firma su un uid specifico

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

Revocare l'intero certificato

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

gpg --import 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB.rev

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

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

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

Operazioni sul keyserver

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

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

vi dirmngr.conf

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

e ricaricando la configurazione:

gpgconf --reload dirmngr

Cerca

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

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

Per gli utilizzatori di keys.openpgp.org:

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

Invia

Invia una lista di chiavi al keyserver

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

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

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

che restituisce un link diretto alla pagina di verifica.

Ricevi

Scarica dal keyserver le chiavi

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

Scarica dal keyserver la chiave indicata dall'uri

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

Aggiorna

Per rinnovare tutte le chiavi pubbliche del keyring.

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

Come proteggere il nostro keyring

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

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

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

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

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

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

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

Realizzare un keyring per l'uso quotidiano

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

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

Eliminazione della chiave privata dalla master key

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

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

Ad es. sulla master key di gandalf:

gpg --delete-secret-keys 0x055D271BD85313D0!

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

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

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

1. spostiamo il keyring di lavoro sul dispositivo sicuro

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

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

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

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

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

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

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

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

Mostrerò la seconda via che è più articolata.

Lavorare con un keyring effimero

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

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

0. Init

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

1. Monto la partizione effimera

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

2. Esporto chiavi pubbliche e trust dal keyring di lavoro

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

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

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

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

...
[operazioni gpg]
...

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

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

6. Rendo il keyring effimero di nuovo stripped

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

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

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

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

Cos'è un keyerver

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

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

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

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

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

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

Modelli recenti

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

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

I principali modelli di keyserver sono:

• Hagrid
• Mailvelope
• HockeyPuck

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

Hagrid

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

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

Mailvelope

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

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

Hockeypuck

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

• keyserver.ubuntu.com

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

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

• pgp.surf.nl

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

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

Altri keyserver

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

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

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

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

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

Introduzione a cryptsetup + LUKS

Supponiamo di voler creare una piccola cassaforte digitale come faremmo con Veracrypt. Ma senza Veracrypt.

Ciò sarà possibile grazie a dm-crypt. dm-crypt è un modulo del kernel che usa il framework device mapper per fornire funzionalità trasparenti di crittografia per dispositivi a blocchi usando le crypto api del kernel. L’uso di device mapper consente, tra l’altro, di “poggiare” dm-crypt sopra ogni possibile mapping dei dispositivi e quindi può cifrare partizioni, volumi raid o volumi logici. 1. Introduzione a cryptsetup + LUKS 2. Inizializzazione 2. Apertura 2. Chiusura 1. Come creare il file vault 1. Header detachable e keyfile 1. Partizionare un “volume” cifrato

[EDIT 02/03/2026]: Riscrittura del par. 3 – “Header detachable e keyfile”, alla luce degli approfondimenti fatti con “Device Mapper: Luks + LVM” e la “Trilogia delle password – Vol. 1,2 e 3“

Poi, essendo a tutti gli effetti anche un dispositivo a blocchi (virtuale), può essere utilizzabile a sua volta come volume nel file system, come swap o come disco fisico per lvm.

La configurazione della cifratura avviene di solito (non è l’unico modo ma è lo standard de facto) con l’utility cryptsetup + LUKS

Come avviene di base la cifratura di un dispositivo?

Le operazioni principali di cryptsetup (con estensioni LUKS) sono:

• luksFormat: stabilisce le modalità di cifratura (consigliato il default)
• luksOpen: (deprecato. Si usa open --type luks2) attiva la cifratura sul device associandolo (grazie a device mapper) ad un dispositivo a blocchi virtuale
• luksClose (deprecato. Si usa close --type luks2): disattiva la cifratura

Inizializzazione

• attacco il dispositivo fisico, viene creata la entry per /dev/<id_dispositivo_a_blocchi_fisico>
• cifratura del dispositivo a blocchi /dev/<id_dispositivo_a_blocchi_fisico> con LUKS (cryptsetup luksFormat)
• al di sopra del dispositivo a blocchi fisico, viene creato un dispositivo a blocchi virtuale, che troverò sotto /dev/mapper/<nome_fittizio>, che eroga le funzionalità di cifratura (cryptsetup open) al dispositivo a blocchi fisico sottostante.
• Infine, partiziono e/o formatto nella maniera canonica il dispositivo a blocchi virtuale (cifrato) /dev/mapper/<nome_fittizio>.

Apertura

• attacco il dispositivo, viene creata la entry per /dev/<id_dispositivo_a_blocchi_fisico>
• attivo il dispositivo a blocchi virtuale che eroga le funzionalità di cifratura (cryptsetup open) e che creerà l’occorrenza sotto /dev/mapper/<nome_fittizio>
• faccio il mount del dispositivo a blocchi virtuale /dev/mapper/ su un punto di montaggio che è una cartella che creerò per l’occasione

Chiusura

• faccio l’unmount del punto di montaggio
• chiudo il dispositivo a blocchi virtuale (cryptsetup close) /dev/mapper/<nome_fittizio>
• stacco il dispositivo fisico

Fermo restando che questi restano i passaggi generali per qualunque dispositivo fisico, per creare un file container cifrato come farebbe Veracrypt, basta che cryptsetup formatti un file invece che un dispositivo a blocchi e automaticamente assocerà il file al primo loop device disponibile. È veramente semplice ^[1] .

Come creare il file vault

Divido le operazioni in 3 fasi:

• Init: fase di inizializzazione del “dispositivo” (il file). Andrà fatta solo la prima volta.
• Open e Close: sono le operazioni che farò ogniqualvolta dovrò usare il container.

Gli oggetti su cui andrà a lavorare sono:

• disco_cifrato.img: il file container cifrato.
• disco_cifrato: il nome con cui disco_cifrato.img (o meglio, la sua rappresentazione come loop device visibile con losetup) viene mappato da device mapper.
• disco_in_chiaro: il punto di montaggio.

## Init
# creazione di una cartella che sarà il nostro punto di mount
mkdir disco_in_chiaro
 
# creazione di un file vuoto di 2 GiB
sudo fallocate -l 2g disco_cifrato.img
 
# preparazione cifratura LUKS 
sudo cryptsetup luksFormat \
     --type luks2 \
     --hash=sha512 \
     --key-size=512 \
     disco_cifrato.img
 
# creazione dispositivo a blocchi virtuale che eroga le funzionalità di cifratura
sudo cryptsetup open \
     --type luks2 \
     disco_cifrato.img disco_cifrato
 
# formattazione
sudo mkfs.ext4 /dev/mapper/disco_cifrato

## Open
# creazione dispositivo a blocchi virtuale
sudo cryptsetup open \
     --type luks2 
     disco_cifrato.img disco_cifrato
 
# monta il dispositivo nel punto di montaggio
sudo mount -t ext4 -o defaults /dev/mapper/disco_cifrato disco_in_chiaro

## Close
# smonta il dispositivo
sudo umount disco_in_chiaro
 
# chiudo il dispositivo a blocchi virtuale staccandolo dai loop device
sudo cryptsetup close disco_cifrato

Header detachable e keyfile

Alziamo il livello di paranoia aggiungendo una complessità ulteriore. Creeremo il file vault nel seguente modo:

1. il vault sarà inizializzato con rumore casuale
2. header detachable
3. offset custom
4. keyfile invece che password
5. default di argon2id (controlla il tuo default con cryptsetup benchmark)

L’apertura del volume cifrato sarà così vincolata alla disponibiltà sia del keyfile che dell’header, senza il quale il volume cifrato sarebbe comunque inservibile.

La presenza di rumore casuale su tutto il vault nella fase di inizializzazione impedirà qualunque tentativo di risalire alla tipologia di informazioni memorizzate, l'assenza di zeri impedirà di capire quanti sono i dati (cifrati) memorizzati.

L'offset custom aggiunge un ulteriore tassello perchè nasconde il punto in cui inizia il payload.

Un keyfile di dati binari casuali è infinitamente più robusto di una password e può esser conservato separatamente insieme all'header. La cifratura simmetrica del keyfile aggiunge ulteriore protezione, fatta magari usando una passphrase ottenuta col metodo Diceware.

Infine la cifratura di default di luks2, argon2id, che è notoriamente sia CPU bound che GPU bound.

Creo il keyfile protetto da una cifratura simmetrica di gpg ^[2] :

## Creazione di un keyfile di 4KiB basata sulla pseudocasualità di /dev/urandom
# creazione del keyfile
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o disco_cifrato.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -

Inizializzo il vault con dati casuali e poi lo formatto creando l'header detachable del volume cifrato fornendo il keyfile invece della passphrase classica:

# inizializzazione vault con dati casuali
# Apro il vault in modalità 'plain' senza header
sudo cryptsetup open \
    --type plain \
    --key-file /dev/urandom \
    --cipher aes-xts-plain64 \
    --key-size 512 \ 
    disco_cifrato.img container

# scrivo degli zeri a cui, attraverso il motore di cifratura,
# corrisponderanno dati casuali sul vault.
dd if=/dev/zero of=/dev/mapper/container status=progress
cryptsetup close container

# Formattazione vault
gpg -d disco_cifrato.key.gpg | \
    sudo cryptsetup luksFormat \
        --type luks2 \
        --key-file - \
        --header header.img \
        --offset 32768 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        disco_cifrato.img

Ed è così che l’apertura del volume cifrato è ora vincolata al possesso dell’header e del keyfile:

# attivazione dispositivo a blocchi virtuale passando header e keyfile protetto da gpg
gpg -d disco_cifrato.key.gpg | \
    sudo cryptsetup open \
        --type luks2 \
	--header header.img \
	--key-file - \
	disco_cifrato.img disco_cifrato

Provando ad aprire container cifrato senza fornire l’header (non tanto il keyfile che è una passphrase evoluta) succede questo:

sudo cryptsetup open \
    --type luks2 \
    disco_cifrato.img disco_cifrato
Il dispositivo disco_cifrato.img non è un dispositivo LUKS valido.

Infine, un'annotazione doverosa.

Visto che il livello di paranoia abbiamo detto essere elevato, sarebbe consigliabile prestare una certa attenzione alla scelta dei nomi.

Quelli usati finora avevano uno scopo “didattico”, che chiarisse il loro scopo con un nome parlante.

i nomi dei file relativi a header e keyfile sarebbe bene non fossero qualcosa del tpo “header.img” o “discocifrato_key.gpg” che rivelano troppo esplicitamente la presenza di un disco cifrato o addirittura dello stesso LUKS. Meglio usare nomi più decontestualizzati, che so... “sys-module-virtio.bin” per l'header e “boot-vmlinuz-06.blob” per il keyfile e via dicendo.

Partizionare un “volume” cifrato

Per concludere, visto che prima ho accennato al fatto che dm-crypt, grazie al sottosistema device mapper, fa in modo che i dispositivi a blocchi (virtuali) mascherino i dispositivo a blocchi sottostanti (un file montato su un loop device, nel nostro caso), i dispositivi a blocchi mappati possono anche essere partizionati invece che sempicemente formattati. O potrebbe essere volumi fisici di un gruppo di volumi LVM, and so on…

Difficilmente avremo bisogno di partizionare un file container cifrato, è solo l’occasione per speculare un po’ su quello che potrebbe succedere su un device fisico.

## Init
mkdir disco_in_chiaro
sudo fallocate -l 2g disco_cifrato.img
sudo cryptsetup luksFormat --hash=sha512 --key-size=512 disco_cifrato.img
sudo cryptsetup open --type luks2 disco_cifrato.img disco_cifrato
 
# Creo 1 partizione primaria da 600 MiB, una estesa da 1400 MiB
# contenente 2 partizioni logiche da 600 MiB e 829 MiB (mancano i
# 16 MiB dell'intestazione luks e i 3 MiB delle intestazioni delle
# partizioni primarie ed estese per un totale di 2GiB tondi tondi)
sudo fdisk /dev/mapper/disco_cifrato
n,,,,+600M,n,e,,,,n,,+600M,n,,,w
 
# il partizionamento potrebbe richiedere l'esecuzione di partprobe
# affinché il kernel carichi la tabella delle partizioni aggiornata
sudo partprobe /dev/mapper/disco_cifrato

# stato delle partizioni
sudo fdisk -l /dev/mapper/disco_cifrato
Disk /dev/mapper/disco_cifrato: 1,98 GiB, 2130706432 bytes, 520192 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x6d65a06f

Device                     Boot  Start    End Sectors  Size Id Type
/dev/mapper/disco_cifrato1         256 153855  153600  600M 83 Linux
/dev/mapper/disco_cifrato2      153856 520191  366336  1,4G  5 Extended
/dev/mapper/disco_cifrato5      154112 307711  153600  600M 83 Linux
/dev/mapper/disco_cifrato6      307968 520191  212224  829M 83 Linux

#procedo con la formattazione
sudo mkfs.ext4 /dev/mapper/disco_cifrato1 #formatto la partizione
sudo mkfs.ext4 /dev/mapper/disco_cifrato5 #formatto la partizione
sudo mkfs.ext4 /dev/mapper/disco_cifrato6 #formatto la partizione

Rispetto all’init di prima, invece che formattare subito il device “fisico”, l’ho partizionato. Esattamente come avrei fatto con un dispositivo realmente fisico.

## Open
sudo cryptsetup open --type luks2 disco_cifrato.img disco_cifrato
 
# di nuovo, potrebbe essere necessario a meno di non riavviare
sudo partprobe /dev/mapper/disco_cifrato
 
# mount delle partizioni
sudo mount -t ext4 -o defaults /dev/mapper/disco_cifrato1 disco_in_chiaro_1
sudo mount -t ext4 -o defaults /dev/mapper/disco_cifrato5 disco_in_chiaro_2
sudo mount -t ext4 -o defaults /dev/mapper/disco_cifrato6 disco_in_chiaro_3

## Close
sudo umount disco_in_chiaro_1
sudo umount disco_in_chiaro_2
sudo umount disco_in_chiaro_3
sudo cryptsetup close disco_cifrato1
sudo cryptsetup close disco_cifrato2
sudo cryptsetup close disco_cifrato5
sudo cryptsetup close disco_cifrato6
sudo cryptsetup close disco_cifrato

Note:

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

In una giornata in cui avevo un po’ di tempo da investire, ho ripreso la versione 2 dello script “Generazione OTP via bash”, e ho deciso di renderlo un po’ più flessibile introducendo una logica crud. Anzi, il termine corretto dovrebbe essere “dave” (Delete, Add, View, Edit). Che altro aggiungere?

• Il file è ancora un insieme di coppie chiave-valore (nome account e chiave privata).
• Il separatore è il simbolo “:”. Ma può essere configurato cambiando il valore della variabile “DELIMITER”.
• Lo script è discretamente commentato così, in futuro, riuscirò a ricordare perché ho fatto quello che ho fatto (tipo “Memento”).
• Le opzioni di gpg per la cifratura/decifratura del file sono configurabili nello script modificando il valore delle variabili “GPG_ENC_OPTIONS” e “GPG_DEC_OPTIONS”.
• L’uso di getopts, mi rendo conto, è solo un esercizio di stile. Non è molto utile per come l’ho usato, visto che ogni optarg corrisponde ad un’operazione autoconclusiva.
• Ero partito per rimpiazzare ogni costrutto if con combinazioni di lista and / lista or ma le condizioni risultavano talmente complesse da rendere il codice francamente molto più incomprensibile di adesso. In alternativa avrei potuto delegare l’esecuzione delle condizioni ad un insieme di funzioni con una stratificazione tale da ricadere nel punto precedente: offuscamento permanente del codice che va a vanificare l’intenzione iniziale di semplificare il codice e renderlo più leggibile.

#!/usr/local/bin/bash


init() {
    # CODICI D'ERRORE
    DECRYPT_ERR=64
    INVALID_OPTION_ERR=65
    INVALID_ACCOUNT_ERR=66
    ACCOUNT_NOT_FOUND_ERR=67
    ACCOUNT_NAME_EMPTY_ERR=68
    ACCOUNT_EXISTS_ERR=69
    INVALID_KEY_ERR=70

    # Colorscheme
    LIGHT_GREEN='\033[1;32m'
    LIGHT_RED='\033[1;31m'
    NC='\033[0m'

    # Path del file cifrato contentente i codici 2FA
    KEYS_2FA_FILE="<path/file_enc.gpg>"

    # Separatore delle coppie chiave-valore
    DELIMITER=":"

    # path gpg e opzioni di cifratura/decifratura
    GPG_TTY=$(tty)
    export GPG_TTY

    #GPG_COMMAND="/usr/local/bin/gpg"
    GPG_ENC_OPTIONS="--yes -c --s2k-cipher-algo aes256 --s2k-digest-algo sha512 --s2k-mode 3 --s2k-count 260000 - "
    GPG_DEC_OPTIONS='-d'

    # Caratteri consentiti nel nome account
    PATTERN='^[a-zA-Z0-9._-]+$';

    # Su MacOS è disponibile "pbcopy", su *nix "xsel"
    case "$(sysctl hw.targettype 2>/dev/null)" in
        "")
            CLIPBOARD="xsel -bi"
            GPG_COMMAND="/usr/bin/gpg";;
         *)
            CLIPBOARD="pbcopy"
            GPG_COMMAND="/usr/local/bin/gpg";;
    esac

    # Decifra e carica in ram il contenuto del file cifrato.
    echo "Decifratura del file degli account in corso..."
    KEYS_2FA_FILE_DEC=$(${GPG_COMMAND} ${GPG_DEC_OPTIONS} "${KEYS_2FA_FILE}" 2>/dev/null)

    # Se la password non è corretta, restituisce un errore.
    [[ -z "${KEYS_2FA_FILE_DEC}" ]] && { err_msg "${DECRYPT_ERR}" 1; }
    info_msg "Fatto."
}


get_account() {
    ACCOUNT_STDIO="$1"

    # Check nome account vuoto
    [[ -z "${ACCOUNT_STDIO}" ]] && return "${ACCOUNT_NAME_EMPTY_ERR}"

    # Check caratteri invalidi nel nome account
    [[ ! "${ACCOUNT_STDIO}" =~ $PATTERN ]] && return "${INVALID_ACCOUNT_ERR}"

    # Estrae l'elemento contenente l'id dato in input
    OTP_LINE=$(echo "${KEYS_2FA_FILE_DEC}" | grep "${ACCOUNT_STDIO}:")

    # Se l'account non esiste, restituisce un errore
    [[ -z "${OTP_LINE}" ]] && return "${ACCOUNT_NOT_FOUND_ERR}"

    ACCOUNT=$(echo $OTP_LINE | cut -d"${DELIMITER}" -f 1)
    KEY=$(echo $OTP_LINE | cut -d"${DELIMITER}" -f 2)
}


crypt_account_file() {
    ACCOUNT_FILE="$1"
    echo -e "\nCifratura del file degli account in corso..."
    ${GPG_COMMAND} -o "$KEYS_2FA_FILE" ${GPG_ENC_OPTIONS} <<< $(echo -e "${ACCOUNT_FILE}")
}


no_param() {
    clear
    help
    exit 0
}


# Visualizza messaggi di errore su stdio
err_msg() {
    if [[ $# -ne 2 ]]; then
        echo -r"${LIGHT_RED}[DEBUG] [err_msg] Numero di parametri non corretto.${NC}."; exit 1
    else
        case $1 in
            "${DECRYPT_ERR}"            ) echo -e "${LIGHT_RED}[ERRORE] Impossibile decriptare il file.${NC}";;
            "${INVALID_OPTION_ERR}"     ) echo -e "${LIGHT_RED}[ERRORE] Opzione \"$OPTARG\" non valida.${NC}";;
            "${INVALID_ACCOUNT_ERR}"    ) echo -e "${LIGHT_RED}[ERRORE] Rilevati caratteri non consentiti.\nI caratteri ammessi sono: [a-z][A-Z][0-9].-_${NC}";;
            "${ACCOUNT_NOT_FOUND_ERR}"  ) echo -e "${LIGHT_RED}[ERRORE] Account non trovato${NC}";;
            "${ACCOUNT_NAME_EMPTY_ERR}" ) echo -e "${LIGHT_RED}[ERRORE] Nome account vuoto.${NC}";;
            "${ACCOUNT_EXISTS_ERR}"     ) echo -e "${LIGHT_RED}[ERRORE] Nome account già esistente${NC}";;
            "${INVALID_KEY_ERR}"        ) echo -e "${LIGHT_RED}[ERRORE] Chiave privata nulla o non corretta.\nLa chiave privata deve essere base32.\n${NC}";;
            *                           ) echo -e "${LIGHT_RED}[ERRORE] Errore generico.${NC}";;
        esac

        [[ $2 -eq 1 ]] && exit $2;
    fi
}


# Visualizza messaggi info su stdio
info_msg() {
    echo -e "${LIGHT_GREEN}$1${NC}"
}


continue_msg() {
    case $1 in
        "insert"    ) ACTION="creato";;
        "edit"      ) ACTION="modificato";;
        "delete"    ) ACTION="cancellato";;
    esac

    echo -n "L'account \"${ACCOUNT}\" sta per essere ${ACTION}. Vuoi continuare? [y|N]: "; read ANSWER;
}


continue_yn() {
        ANSWER="0"
        while [[ "${ANSWER}" != "y" ]]; do
            [[ -z "${ANSWER}" || "${ANSWER}" == "N" ]] && { echo "Operazione annullata"; exit; }
            [[ "${ANSWER}" != "y" || "${ANSWER}" != "N" ]] && continue_msg "$1"
        done
}


totp() {
    # Se la'ccount non esiste o è invalido, esco con errore
    get_account "$1"; RET_CODE=$?
    case "${RET_CODE}" in
        "${ACCOUNT_NOT_FOUND_ERR}"  ) err_msg "${ACCOUNT_NOT_FOUND_ERR}" 1;;
        "${INVALID_ACCOUNT_ERR}"    ) err_msg "${INVALID_ACCOUNT_ERR}" 1;;
    esac

    echo -e "\nCopia OTP nella clipboard..."
    # Calcola l'otp e lo trasferisce nella clipboard con xsel
    oathtool --totp -b "${KEY}" | $CLIPBOARD
    info_msg "Fatto."
    exit
}


insert() {
    # Se l'account non esiste o è invalido, esco con errore
    get_account "$1"; RET_CODE=$?
    case "${RET_CODE}" in
        0                           ) err_msg "${ACCOUNT_EXISTS_ERR}" 1;;
        "${INVALID_ACCOUNT_ERR}"    ) err_msg "${INVALID_ACCOUNT_ERR}" 1;;
    esac

    ACCOUNT="$1"

    # Inserisci la chiave
    echo -en "Nuovo account: ${ACCOUNT}\nInserisci la nuova chiave privata: "; read KEY
    while [[ -z "${KEY}" || ! $(echo ${KEY} | oathtool -b - 2>/dev/null) ]]; do
        err_msg "${INVALID_KEY_ERR}" 0
        echo -n "Inserisci la chiave privata: "; read KEY
    done

    info_msg "\nNuovo account:        ${ACCOUNT}\nNuova chiave privata: ${KEY}"
    continue_yn "insert"

    # Appendo il nuovo record nel file degli account
    KEYS_2FA_FILE_DEC+="\n${ACCOUNT}${DELIMITER}${KEY}"
    info_msg "L'account \"${ACCOUNT}\" è stato creato con successo."

    # Cifratura del file degli account
    crypt_account_file "${KEYS_2FA_FILE_DEC}"
    info_msg "Fatto."
    exit
}


edit() {
    # Se la'ccount non esiste o è invalido, esco con errore
    get_account "$1"; RET_CODE=$?
    case "${RET_CODE}" in
        "${ACCOUNT_NOT_FOUND_ERR}"  ) err_msg "${ACCOUNT_NOT_FOUND_ERR}" 1;;
        "${INVALID_ACCOUNT_ERR}"    ) err_msg "${INVALID_ACCOUNT_ERR}" 1;;
    esac

    # Faccio una copia dell'account per un eventuale ripristino durante
    # la fase di input
    ACCOUNT_TEMP="${ACCOUNT}"
    ACCOUNT_MOD="${ACCOUNT}"

    # Inserisco il nuovo nome account.
    # 1. Se è vuoto: è la conferma dell'account inserito all'inizio e proseguo
    # 2. Se il nome è invalido: sollevo un'eccezione e reitero
    # 3. Se il nome è valido:
    #    a. Se è un nome nuovo: acquisisco il nuovo nome, recupero nome e chiave dell'account di partenza e proseguo
    #    b. Sè è lo stesso nome di partenza: è la conferma dell'account iniziale e proseguo
    #    c. Se è un altro nome esistente o invalido: come il punto 2.
    while true; do
        echo
        echo -en "Account: ${ACCOUNT}\nInserisci nuovo nome account: "; read ACCOUNT_MOD;
        get_account "${ACCOUNT_MOD}"; RET_CODE=$?
        case "${RET_CODE}" in
            # Punto 1.
            "${ACCOUNT_NAME_EMPTY_ERR}" ) ACCOUNT_MOD="${ACCOUNT}"; break;;
            # Punto 2
            "${INVALID_ACCOUNT_ERR}"    ) err_msg "${INVALID_ACCOUNT_ERR}" 0;;
            # Punto 3a.
            "${ACCOUNT_NOT_FOUND_ERR}"  ) get_account "${ACCOUNT_TEMP}"; break;;
            # Punti 3b e 3c, rispettivamente
            0                           ) [[ "${ACCOUNT_MOD}" == "${ACCOUNT_TEMP}" ]] && break \
                                                                                 || { get_account "${ACCOUNT_TEMP}"; err_msg "${ACCOUNT_EXISTS_ERR}" 0; };;
        esac
    done

    [[ "${ACCOUNT}" != "${ACCOUNT_MOD}" && ! -z "${ACCOUNT_MOD}" ]] && msg="\nL'account \"${ACCOUNT}\" è stato modificato in \"${ACCOUNT_MOD}\"." \
                                                                    || msg="\nNessuna modifica rilevata.\n"
    info_msg "${msg}"

    # Modifica la chiave privata
    KEY_MOD="${KEY}"
    echo

    while true; do
        echo -en "Chiave privata: ${KEY}\nInserisci la nuova chiave privata: "; read KEY_MOD
        if [[ -z $KEY_MOD ]]; then
            KEY_MOD="${KEY}"; break
        elif [[ ! $(echo "${KEY_MOD}" | oathtool -b - 2>/dev/null) ]]; then
            err_msg "${INVALID_KEY_ERR}" 0; KEY_MOD="${KEY}"
        else
            break
        fi
    done

    # Se c'è stata almeno una modifica (account/key), sovrascrivo il record. Altrimenti esco senza fare nulla.
    if [[ "${ACCOUNT}" != "${ACCOUNT_MOD}" || "${KEY}" != "${KEY_MOD}" ]]; then
        # Conferma modifica

        info_msg "\nAccount:              ${ACCOUNT}\nChiave privata:       ${KEY}\nNuovo account:        ${ACCOUNT_MOD}\nNuova chiave privata: ${KEY_MOD}\n"
        continue_yn "edit"

        # Modifica del file degli account
        KEYS_2FA_FILE_DEC_TEMP=$(sed "s/${ACCOUNT}${DELIMITER}${KEY}/${ACCOUNT_MOD}${DELIMITER}${KEY_MOD}/" <<< "${KEYS_2FA_FILE_DEC}")
        info_msg "L'account \"${ACCOUNT}\" è stato modificato con successo."

        # Cifratura del file degli account
        crypt_account_file "${KEYS_2FA_FILE_DEC_TEMP}"
    else
        info_msg "Nessuna modifica rilevata."
    fi
    info_msg "Fatto."
}


delete() {
    if get_account "$1"; then
        # Conferma eliminazione
        info_msg "\nAccount:              ${ACCOUNT}\nChiave privata:       ${KEY}\n"
        continue_yn "delete"

        # Cancellazione account
        KEYS_2FA_FILE_DEC_TEMP=$(sed "/$ACCOUNT/d" <<< "${KEYS_2FA_FILE_DEC}")
        info_msg "L'account \"$ACCOUNT\" è stato eliminato."

        # Cifratura del nuovo file degli account
        crypt_account_file "${KEYS_2FA_FILE_DEC_TEMP}"
        info_msg "Fatto."
    else
        err_msg "${ACCOUNT_NOT_FOUND_ERR}" 1
    fi
}


list() {
    echo
    while read LINE; do
        cut -d"${DELIMITER}" -f 1 <<< "${LINE}"
    done <<< "${KEYS_2FA_FILE_DEC}"
}


help() {
cat<<EOF
Usa come: ./totp.sh [options] ARG
dove:
    [options]
        -l restituisce la lista degli account.
        -t <nome_account> restituisce l'otp per quell'account.
        -i <nome_account> inserisce un nuovo account.
        -d <nome_account> cancella <nome_account>.
        -e <nome_account> modifica <nome_account>.
        -h stampa questa pagina di help.

ESEMPI:
    RESTITUISCE LA LISTA DEGLI ACCOUNT
    totp.sh -l

    INSERISCE UN ACCOUNT
    totp.sh -i dropbox

    CANCELLA UN ACCOUNT
    totp.sh -d megaupload

    MODIFICA UN ACCOUNT
    totp.sh -e paypal

    GENERA OTP
    totp.sh -t firefoxsync
EOF
}


main() {
    init
    while getopts "lt:i:e:d:" opt; do
        case $opt in
            l ) list ;;
            t ) totp $OPTARG ;;
            i ) insert $OPTARG ;;
            e ) edit $OPTARG ;;
            d ) delete $OPTARG ;;
            * ) clear;err_msg "${INVALID_OPTION_ERR}" 1;;
        esac
    done
    shift $(($OPTIND - 1))
}

[[ $# -eq 0 || $# -eq 1 && "$1" == "-h" ]] && no_param || main $*

#bash #totp #cryptography #gpg #scripting