OpenSSL, introduzione all’uso: come creare primitive crittografiche da linea di comando

Il software open source OpenSSL, assieme ad alcune sue fork^[1], costituisce strumento ben noto a molti specialisti per realizzare varie primitive crittografiche, sfruttando soprattutto le API (Application Programming Interface) che mette a disposizione.

Non molti sono al corrente dell’ambiente che consente l’esecuzione delle primitive da linea di comando. L’obiettivo di questo articolo è introdurre all’utilizzo di tale ambiente, ricco e complesso, la cui padronanza va oltre i nostri scopi: qui ci limiteremo ad introdurlo, fornire riferimenti per il suo approfondimento e prendere in esame alcuni semplici primitive crittografiche, come la cifratura simmetrica, la firma digitale e la sua verifica, le funzioni hash e qualche altro dettaglio. Forniremo esempi d’uso, riferendoci a OpenSSL versione 3.1.4.

In questo articolo assumeremo che il lettore sia familiare con i principali concetti della crittografia di base. In mancanza di tale requisito, sarà necessaria la comprensione di vari concetti propedeutici.^[2]

Tramite il terminale o il prompt dei comandi, dopo essersi assicurati di aver installato OpenSSL e averlo inserito nel PATH, con openssl version si può ottenere la versione in uso. In quanto segue, per maggiore chiarezza, si userà testo corsivo per i comandi inseriti e testo grassetto per l’output del computer.

In questo caso

% openssl version

OpenSSL 3.1.4 24 Oct 2023 (Library: OpenSSL 3.1.4 24 Oct 2023)

Nella shell Linux/macOS usata per invocare OpenSSL il comando man openssl fornisce ampia descrizione del modo d’uso del comando, mostrandone complessità e ricchezza.

Cifratura simmetrica

Il primo caso d’uso preso in considerazione è la cifratura simmetrica di un file. A tale scopo sarà opportuno creare un file da cifrare. Decidiamo da iniziare da un’immagine del Colosseo, come mostrato in Figura 1. Il file è denominato col.jpg.

Volendo cifrare il file, la prima questione che ci si pone è: con quale algoritmo di cifratura simmetrica? Interessante notare che possiamo farci dire quali algoritmi sono supportati con il semplice comando openssl.

% openssl

help:

Standard commands

asn1parse ca ciphers cmp

cms crl crl2pkcs7 dgst

dhparam dsa dsaparam ec

ecparam enc engine errstr

fipsinstall gendsa genpkey genrsa

help info kdf list

mac nseq ocsp passwd

pkcs12 pkcs7 pkcs8 pkey

pkeyparam pkeyutl prime rand

rehash req rsa rsautl

s_client s_server s_time sess_id

smime speed spkac srp

storeutl ts verify version

x509

Message Digest commands (see the `dgst’ command for more details)

blake2b512 blake2s256 md4 md5

mdc2 rmd160 sha1 sha224

sha256 sha3-224 sha3-256 sha3-384

sha3-512 sha384 sha512 sha512-224

sha512-256 shake128 shake256 sm3

Cipher commands (see the `enc’ command for more details)

aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb

aes-256-cbc aes-256-ecb aria-128-cbc aria-128-cfb

aria-128-cfb1 aria-128-cfb8 aria-128-ctr aria-128-ecb

aria-128-ofb aria-192-cbc aria-192-cfb aria-192-cfb1

aria-192-cfb8 aria-192-ctr aria-192-ecb aria-192-ofb

aria-256-cbc aria-256-cfb aria-256-cfb1 aria-256-cfb8

aria-256-ctr aria-256-ecb aria-256-ofb base64

bf bf-cbc bf-cfb bf-ecb

bf-ofb camellia-128-cbc camellia-128-ecb camellia-192-cbc

camellia-192-ecb camellia-256-cbc camellia-256-ecb cast

cast-cbc cast5-cbc cast5-cfb cast5-ecb

cast5-ofb des des-cbc des-cfb

des-ecb des-ede des-ede-cbc des-ede-cfb

des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb

des-ede3-ofb des-ofb des3 desx

idea idea-cbc idea-cfb idea-ecb

idea-ofb rc2 rc2-40-cbc rc2-64-cbc

rc2-cbc rc2-cfb rc2-ecb rc2-ofb

rc4 rc4-40 seed seed-cbc

seed-cfb seed-ecb seed-ofb sm4-cbc

sm4-cfb sm4-ctr sm4-ecb sm4-ofb

Figura 1. Immagine priva di diritti disponibile qui.

La parte in questo momento più interessante è quella introdotta da Cipher commands. Abbiamo una serie di stringhe generalmente composte da tre parti, secondo lo schema xxx-yyy-zzz, ove il carattere – è usato per separare le tre parti. La prima parte è un nome o acronimo che identifica l’algoritmo impiegato, la seconda descrive la lunghezza (in bits) della chiave e la terza è il modo operativo selezionato.

Ad esempio, AES-128-cbc denota l’algoritmo AES con chiave a 128 bits e modo operativo CBC. Talvolta non sono presenti tutte le stringhe e vengono omesse quelle che sono di default o obbligatorie. Scegliamo di usare per esempio proprio il citato aes-128-cbc (standard dell’americano NIST).

Per cifrare dunque il file col.jpg e costruire la sua cifratura col.enc possiamo usare (esistono più modi in OpenSSL di ottenere lo stesso risultato):

% openssl enc -aes-128-cbc -in col.jpg -out col.enc

enter AES-128-CBC encryption password:

Verifying – enter AES-128-CBC encryption password:

*** WARNING : deprecated key derivation used.

Using -iter or -pbkdf2 would be better.

Input e output sono stati copiati e incollati per cui si vede la riproduzione fedele dell’interazione. La libreria prima chiede una password per generare internamente una chiave di cifratura (tramite una key derivation function, o KDF), poi ne chiede la conferma; quindi, ci avvisa che la KDF usata, che è quella di default, è sconsigliata (perché poco sicura) e suggerisce delle alternative. In effetti l’opzione -opbkdf2 permette di usare una KDF migliore e più moderna.

Ripetiamo, dunque, l’operazione di cifratura usando come password la parola “salsiccia” ottenendo

% openssl enc -aes-128-cbc -pbkdf2 -in col.jpg -out col2.enc

enter AES-128-CBC encryption password:

Verifying – enter AES-128-CBC encryption password:

Ora il risultato è nel file col2.enc.

Possiamo ripetere il tutto aggiungendo l’opzione -p che permette di avere maggiore visibilità dei parametri impiegati:

% openssl enc -aes-128-cbc -pbkdf2 -p -in col.jpg -out col2.enc

enter AES-128-CBC encryption password:

Verifying – enter AES-128-CBC encryption password:

salt=9B0EC08D5EA0824F

key=847B384FE34F7843545D589FB5773720

iv =9506A9C99BE117595847266D307E12CE

In particolare, abbiamo ottenuto la visione del sale generato (salt), della chiave costruita (key) e dell’IV creato (iv, necessario per CBC); tutti i valori sono espressi in esadecimale. Possiamo visionare i primi sedici byte del file creato col2.enc nel seguente modo:

% hexdump -C col2.enc | head -1

00000000 53 61 6c 74 65 64 5f 5f 9b 0e c0 8d 5e a0 82 4f |Salted__….^..O|

Dalla visione possiamo verificare che I primi otto byte del risultato codificano la stringa “Salted__” e i secondi otto descrivono il salt (si usano le minuscole invece delle maiuscole, ma non c’è differenza reale). Tali informazioni sono necessarie per generare lo stesso IV in fase di decifratura. Va detto tuttavia che la decisione di porre tali sedici byte all’inizio del file cifrato è una caratteristica di OpenSSL, non di AES. Ciò significa che un’altra libreria che usa AES con chiavi di 128 bit e CBC potrà generare un file differente perché potrebbe inserire tali informazioni ausiliari alla fine del file o in altro file^[3].

Prendiamo ora il file col2.enc e decifriamolo, mettendo il contenuto in col2.jpg. Quello che ci aspettiamo è che col.jpg e col2.jpg siano identici. Si può verificare ciò con il comando cmp. La linea per decifrare è simile a quella per cifrare, con alcune piccole variazioni: si è aggiunta l’opzione -d per la decifratura (il default è cifrare), il file di input diviene col2.enc e quello di output col2.jpg.

openssl enc -aes-128-cbc -pbkdf2 -d -p -in col2.enc -out col2.jpg

Il confronto con cmp conferma la piena coincidenza.

Nella pagina man è possibile vedere come cifrare/decifrare fornendo salt, IV e/o password arbitrari già dalla linea di comando.

Firma digitale RSA

Occupiamoci ora di cifratura asimmetrica, esaminando l’uso di RSA ai fini della firma digitale. Per una firma apposta tramite RSA occorre:

1. Disporre di una coppia di chiavi, eventualmente da generare.
2. Effettuare l’operazione di firma vera e propria.
3. Saper effettuare la verifica.

OpenSSL permette di generare una chiave privata RSA piuttosto facilmente:

% openssl genpkey -algorithm RSA -out key.pem

.+………..+…+++++++++++++++++++++++++++++++++++++++*…..+…+…+…………+..+.+…+………+..+…+……….+…..+.+..+++++++++++++++++++++++++++++++++++++++*…+…..+.+…+..+….+…..+…+…+….+…..+.+…+…..+….+…..+…………+………………+…+….+…+………..+.+…..+.+……..+…………+………….+………+…+………+…+…..+……+.+…………………+…+…..+………+…+…….+..+.+……..+……+……+…+…….+…..+….+………+………+……+…..+.+……+…+………..+…+…….+…+..+…+…………+……+…….+…+..+.+…………..+.+..+……….+……………+……………+..+…….+…+..+.+..+……+.+…+…+…………+…..+…………+…………….+……………+..+…….+…..+…+…….+…++++++

…..+..+…+……+.+…..+.+…+………..+…+……….+..+…+.+..+….+…+…+..+…+…+………+…….+++++++++++++++++++++++++++++++++++++++*…+……………………………..+…………+…+……+.+……..+………+.+++++++++++++++++++++++++++++++++++++++*.+…+…+……+……..++++++

Il commando crea una chiave e la pone in key.pem. Se tentiamo di osservare l’inizio del file otteniamo:

% head -6 key.pem

—–BEGIN PRIVATE KEY—–

MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC15SqPr89vowD+

QY6jQjugtonCi+kfbqU7c9hWxp+vYcqbQ6KkzOJIVYm8p3hhkBhP5ZXHWBiUsLIL

mli5gsvQIyuNGN56bXCbNe/U/TEtWwIVIuMdo+DSfX9NEx8SBSdGaBIQ5hm/aprj

5O4l6z87Abxs/XPTYkxbuWLiQUvddQrZE6Em8BXl46hYP5pCnHJefVV2GZ3j8WPu

x/NfDlbYww0F97SYjQ10u4oy3aEpd/1yAiOS98qkLkZyMNnhWqgK5I7I4tHHvNs6

Nonostante la scritta iniziale “BEGIN PRIVATE KEY” il file contiene tutte le informazioni relative a entrambe le chiavi. Ci accorgiamo che è uuencoded e di immediata lettura (plaintext). Ciò non è opportuno per una chiave privata. Occorre generare la sua rappresentazione in forma cifrata, ad esempio usando AES. Inoltre, la dimensione della chiave è quella di default (2048 bits); se vogliamo una chiave di 4096 bits dobbiamo usare l’opzione -pkeyopt rsa_keygen_bits:4096

% openssl genpkey -algorithm RSA -out key.pem -aes-128-cbc -pkeyopt rsa_keygen_bits:4096

………..+++++++++++++++++++++++++++++++++++++++++++++*…….+…+..+…….+…..+…+.+++++++++++++++++++++++++++++++++++++++++++++*……….+.+..+…….+…………+…+………………..+…….+……..+…….+………+………+..+….+..+………+………+………+…+…+…….+………+…………..+…….+…………..+.+…+………..+……+………+…+…….+…+…..+……+…….+…+…..+.+……..+…+…+.+……+++++

..+…….+…..+….+…..+.+…..+…+.+…………..+…+………….+………..+…+…+…….+………..+.+…+……..+………+….+………..+……+++++++++++++++++++++++++++++++++++++++++++++*…+……………+++++++++++++++++++++++++++++++++++++++++++++*….+….+………+……..+…….+…+…..+…+…….+………+……+…+..+……….+…………+..+………………………………+…+.+…+……..+…….+…..+.+…..+.+……+……………+…………+……+………..+.+………………+..+…+.+…………………+..+……………+.+..+….+……………+…..+.+………………+……+………+..+……………+….+…+…+..+.+…..+………+………….+..+…………+………….+..+.+..+…+…………+……+.+…………………+……………..+…+…+.+……..+…….+…+..+….+..+………+…+.+………+..+…+………………+…+…….+…………………..+.+…+..+…+……………………….+………………+..+…………+…+….+…+..+……………+.+…..+……………………+++++

Enter PEM pass phrase:

Verifying – Enter PEM pass phrase:

Controlliamo l’inizio del file generato key.pem:

% head -6 key.pem

—–BEGIN ENCRYPTED PRIVATE KEY—–

MIIJrTBXBgkqhkiG9w0BBQ0wSjApBgkqhkiG9w0BBQwwHAQIS4ShbhbOF/ACAggA

MAwGCCqGSIb3DQIJBQAwHQYJYIZIAWUDBAECBBAcQAlvAOeNHShqsMNKdB40BIIJ

UBlNYSgjdHFaP8jrMQqC6QpT/xE+4fthNIWJ2foO4FD5rm8yy7aKTZtUDm/ZeRzc

dXyaE/wuBvQrPw1jonnPRD0LeW65AlsMX9sSliaQtGXRZfiylJXXnaMPeYDhADxh

n0SXiO/8JeSWsFY7CyYIOYIq0lpQ/HZjqRSyweic9ecGtnDSsbqv6Md/msoo8QYp

Per conoscere i dettagli di una chiave c’è l’opzione -text

% openssl pkey -in key.pem -text

Enter pass phrase for key.pem:

—–BEGIN PRIVATE KEY—–

MIIJQgIBADANBgkqhkiG9w0BAQEFAASCCSwwggkoAgEAAoICAQC7L21b6ebrbeps

[…]

Nep11GGL1XnlZMiZqVI7yjLF8sNRgg==

—–END PRIVATE KEY—–

Private-Key: (4096 bit, 2 primes)

modulus:

00:bb:2f:6d:5b:e9:e6:eb:6d:ea:6c:64:fb:ec:6d:

[…]

92:a6:d9

publicExponent: 65537 (0x10001)

privateExponent:

01:02:a7:c6:b5:fb:c0:dc:12:46:9d:01:ee:1c:06:

[…]

1b:2d

prime1:

00:ff:38:03:e6:f8:5d:49:82:fe:80:66:3d:75:4d:

[…]

c1:ed

prime2:

00:bb:c2:1a:23:a8:e8:85:51:20:11:e7:d8:10:ad:

[…]

8b:1d

exponent1:

00:fc:ff:c3:66:88:98:b9:91:e0:c6:da:13:5c:a0:

[…]

fa:75

exponent2:

05:5a:c2:be:13:9a:15:fb:3b:4b:e7:6d:bd:04:03:

[…]

6d

coefficient:

53:b5:54:22:62:6a:8a:00:8d:f6:d3:04:9b:d2:43:

[…]

82

Come possiamo constatare sono presenti cinque campi: modulus (il valore N = p·q, prodotto dei primi p e q), publicExponent e, fissato per default a 65537, privateExponent d, inverso moltiplicativo di e mod (p – 1)(q – 1) e alcune informazioni che servono per facilitare i calcoli di RSA^[4].

È possibile estrarre la chiave pubblica da quella privata tramite:

% openssl rsa -in key.pem -out pub.pem -pubout

Enter pass phrase for key.pem:

writing RSA key

Verifichiamo le prime due linee di pub.pem:

% head -2 pub.pem

—–BEGIN PUBLIC KEY—–

MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAuy9tW+nm623qbGT77G29

Abbiamo effettivamente estratto la chiave pubblica.

Per firmare digitalmente il file col.jpg usiamo la funzione hash SHA-256 (molto usata). Si pone ora una questione: ci sono tre standard per RSA, descritti da PKCS#1 durante le sue evoluzioni, e possiamo riferirci ad essi come PKCS#1 v1.5, PKCS#1 OAEP e PKCS#1 PSS, che descrivono come il digest del file debba essere preprocessato prima di eseguire l’esponenziazione RSA.

Le tecniche di uso di RSA supportate da OpenSSL si riferiscono ai tre standard menzionati, con i nomi di pkcs1, oaep e pss.^[5] Dalla documentazione di OpenSSL apprendiamo che solo pkcs1 e pss supportano la firma, mentre oaep supporta solo cifratura e decifratura. Costruiamo lo hash (binario) del file.

% openssl dgst -sha256 -binary -out hash col.jpg

% hexdump hash

0000000 459f 5940 f4e9 c648 0706 7c2e 2a7d 1b83

0000010 97b0 480e dd30 098b cde5 696b 09f8 de4f

0000020

Occupiamoci dapprima di PKCS#1 v1.5, il più vecchio e solo raccomandato per i casi di retrocompatibilità. Possiamo firmare con:

% openssl pkeyutl -sign -in hash -inkey key.pem -out sign1.5 -pkeyopt rsa_padding_mode:pkcs1

Enter pass phrase for key.pem:

Il file sign1.5 contiene la firma ed è binario.

% hexdump sign1.5 | head -3

0000000 9c00 55af 8809 2f7c 845e 3000 b9dd ae00

0000010 9269 9403 1e2c 694f e328 e2e9 e66a f79c

0000020 1378 f596 225b e441 49c4 5ebf f530 3ef4

La verifica è quasi uguale, occorre rimpiazzare il sign con verify e operare qualche semplice intervento.

% openssl pkeyutl -verify -sigfile sign1.5 -in hash -inkey key.pem -pkeyopt rsa_padding_mode:pkcs1

Enter pass phrase for key.pem:

Signature Verified Successfully

Nel caso pss il comando di firma richiede anche la specificazione della lunghezza del sale: il valore speciale -1 indica la stessa lunghezza del digest.

% openssl pkeyutl -sign -in hash -inkey key.pem -out signpss -pkeyopt digest:sha256 -pkeyopt rsa_padding_mode:pss -pkeyopt rsa_pss_saltlen:-1

Le prime righe della firma ottenuta:

% hexdump signpss | head -3

0000000 211c 2055 cb0d 0ff7 b7fe 316b 9c2a 4255

0000010 a20a 3c2e 04c3 d888 efe7 c56e b03f 15c2

0000020 2e75 ea0a 3d86 7310 5b92 7c76 baa7 9018

A tal proposito osserviamo che eseguendo la stessa firma sul file signpssbis:

% openssl pkeyutl -sign -in hash -inkey key.pem -out signpssbis -pkeyopt digest:sha256 -pkeyopt rsa_padding_mode:pss -pkeyopt rsa_pss_saltlen:-1

Enter pass phrase for key.pem:

si ottiene un file diverso.

% hexdump signpssbis | head -3

0000000 277c b6ca 4d58 1236 6e7e a16b 0b32 f8bf

0000010 2363 36e1 c7fa 22d7 8cf4 8804 d6dd 004e

0000020 21c2 0479 44e9 bc25 7562 dd7e 6dda d50d

È quanto ci aspettavamo perché la firma pss non è deterministica. Ripetendo invece la firma pkcs1 e creando un file sign1.5bis questo risulterà identico a sign1.5 (firma deterministica).

Nel caso pss la verifica è analoga al caso pkcs1.

% openssl pkeyutl -verify -sigfile signpss -in hash -inkey key.pem -pkeyopt digest:sha256 -pkeyopt rsa_padding_mode:pss -pkeyopt rsa_pss_saltlen:-1

Enter pass phrase for key.pem:

Signature Verified Successfully

Notiamo che in entrambe le verifiche abbiamo dovuto inserire la password per accedere alla chiave privata; questo perché essa contiene le informazioni utili alla verifica (che avremmo trovato nella chiave pubblica).

% openssl pkeyutl -verify -sigfile signpss -in hash -pubin -inkey pub.pem -pkeyopt digest:sha256 -pkeyopt rsa_padding_mode:pss -pkeyopt rsa_pss_saltlen:-1

Signature Verified Successfully

E in effetti non è stata richiesta una password.

Ci si potrebbe domandare che relazione ci sia fra la firma generata da OpenSSL e le tradizionali firme usate da molti individui, PAdES o CAdES. Da un punto di vista tecnico le firme PAdES e CAdES possono basarsi su RSA. Vediamo le più significative distinzioni:

1. le firme PAdES e CAdES sono supportate da certificati X509, che confermano la validità e correttezza delle chiavi e danno valore legale alle firme apposte;
2. nella firma PAdES la firma è inserita nel pdf stesso per cui non è un file a parte; in quella CAdES la firma (oltre ad altre informazioni) viene inserita dentro una busta crittografica denominata di tipo P7M,^[6] una sorta di contenitore che raggruppa tutte le informazioni di interesse per la firma e da cui si possono estrarre le componenti con apposito software.

Vale la pena osservare che sia la sezione dgst che la pkeyutl consentono di apporre firme. La prima è a più alto livello la seconda più a basso livello e richiede lo hashing del file da firmare. Ci sono altre differenze ma sono più tecniche.

Il software OpenSSL contiene molte sezioni, chiamate nella documentazione “comandi.” Nella tabella che segue è possibile esaminare un quadro sintetico, direttamente ottenuto dalla documentazione ufficiale; si evince la gigantesca portata della libreria, utile non solo per eseguire semplici operazioni crittografiche ma anche per lavorare con certificati, mettere l’e-mail in sicurezza, lavorare con numeri random, generare password, scegliere una KDF eccetera.

Tutti i comandi elencati possono essere approfonditi digitando man openssl- seguito dal nome del comando. Ad esempio, man openssl-smime. Talvolta la documentazione non riflette con precisione il reale comportamento ed occorre eseguire sperimentazioni.

Conclusione

Abbiamo esaminato alcune operazioni che possono essere eseguite con OpenSSL, comprendendo la potenza e la versatilità della libreria.

Fra le molte supportate ne abbiamo scelto alcune che sono più vicine alle esigenze di un utente finale, quali la cifratura e la firma digitale.

Ce ne sono altre, come è ormai evidente, che sono estremamente più specialistiche. In un prossimo pezzo, l’uso di OpenSSL per il test di connessioni TSL e per la gestione dei certificati.

NOTE

1. La più famosa è LibreSSL, qui. ↑

2. Ad esempio si può iniziare da qui e seguire l’ipertesto nei suoi link principali, oppure prendere un qualsiasi volume disponibile al pubblico come l’Handbook of applied Cryptography. Un buon inizio è anche ai riferimenti nella nota n. 6. ↑

3. Il problema è discusso in F. d’Amore, F. Rositano. “A library for implementation-independent data decryption”. Proceedings of Seventh International Congress on Information and Communication Technology. To appear in Springer Nature. Electronic ISBN 978-981-19-2397-5. Print ISBN 978-981-19-2396-8. ↑

4. Sono exponent1, esponente di p, exponent2, esponente di q e coefficient q^-1 mod p. Sfruttano il teorema del resto cinese per un più efficiente calcolo delle esponenziazioni RSA. ↑

5. Sono anche supportate le modalità none e x931. Si veda man openssl-pkeyutl per dettagli. ↑

6. Il formato deriva dallo standard PKCS#7, introdotto dall’RFC 2315 e successivamente aggiornato. Si veda qui. ↑