Blia.it

Il blog di Blia.it

OpenSSL 3 - terza parte

Ma, come abbiamo visto nell’articolo precedente, anche OpenSSL si riorganizza, lo sviluppo è più corale e per il merge di una patch adesso è richiesta l’approvazione di almeno due dei componenti del core team. Veniamo alle novità di oggi.

A metà 2018 si comincia a parlare, all’interno di OpenSSL, di importanti modifiche all’intera infrastruttura della liberia. Dopo più di un anno di sviluppo, non semplicissimo visto la quantità e complessità del codice, il 23 aprile 2020 è stata pubblicata la prima versione alpha di OpenSSL 3.

La novità più importante è l’introduzione di un concetto nuovo per OpenSSL, chiamato “Provider”. In OpenSSL 3.0 tutti gli algoritmi crittografici saranno implementati in un provider. Ci sarà un provider predefinito “default”, un provider “legacy” per consentire l’accesso agli algoritmi obsoleti o in fase di abbandono e un provider “FIPS” per consentire l’accesso agli algoritmi validati FIPS. FIPS, lo ricordiamo, sta per Federal Information Processing Standards, e FIPS-140 (attualmente 140-2 ma presto sarà sostituito dal 140-3), è lo standard nazionale per la sicurezza dei computer negli Stati Uniti e richiede rigorosi requisiti per le operazioni dei moduli crittografati. A certificare la compatibilità con tale standard è il National Institute of Standards and Technology (NIST). Con il rilascio di OpenSSL 1.1 nell’agosto 2016, il codice FIPS è stato completamente rimosso perché ritenuto inadatto per il supporto a lungo termine e doveva essere sostituito da qualcosa di diverso.

Attualmente la versione stabile di OpenSSL è la 1.1.1, una LTS (Long Term Support) con fine supporto 11/9/2023. In questa versione OpenSSL è diviso in quattro componenti principali.

1. Libcrypto. E’ la libreria principale che fornisce le implementazioni di numerosi algoritmi crittografici. Inoltre fornisce una serie di servizi di supporto che vengono utilizzati da libssl e libcrypto, nonché implementazioni di altri protocolli come CMS e OCSP.
2. Engine. La funzionalità di libcrypto può essere estesa tramite l’API Engine. Generalmente sono moduli caricabili dinamicamente che implementano algoritmi non presenti in OpenSSL (ad esempio l’engine GOST implementa la famiglia di algoritmi GOST), oppure moduli per interfacciare OpenSSL ad hardware crittografico (ad es. smartcard e dispositivi HSM), tramite protocollo PKCS11.
3. Libssl. Questa libreria dipende da Libcrypto e implementa i protocolli TLS e DTLS.
4. Applicazioni. Le applicazioni sono un set di strumenti da riga di comando (openssl seguito dal tool, ad esempio openssl x509 …) che utilizzano le librerie libssl e libcrypto per fornire funzionalità crittografiche e di altro tipo come: Generazione e verifica di chiavi crittografiche Generazione e verifica certificati X509 Strumenti di test SSL / TLS Parsing ASN.1 Ecc.

L’architettura di OpenSSL 3, invece ha queste caratteristiche. Le componenti principali sono i Core Services e i Provider. I Core Services, i servizi di base, costituiscono gli elementi utilizzabili da applicazioni e provider. (ad es. BIO, X509, SECMEM, ASN1, ecc.). I Provider implementano algoritmi crittografici e servizi di supporto. Un provider può effettuare una o più delle seguenti operazioni: Funzioni crittografiche di un algoritmo, ad es. come crittografare / decrittografare / firmare / hash ecc. Serializzazione di un algoritmo, ad es. come convertire una chiave privata in un file PEM. La serializzazione potrebbe essere da o verso formati che non sono attualmente supportati. Caricare chiavi e altri dati da vari supporti, ad esempio file o smartcard.

Un Provider può essere completamente autonomo o utilizzare servizi forniti da altri provider fornitori o dai Core Services. Ad esempio, un’applicazione può utilizzare le primitive crittografiche per un algoritmo implementato da un provider con accelerazione hardware, ma utilizzare i servizi di serializzazione di un provider diverso per esportare le chiavi nel formato PKCS#12. I Provider inclusi in OpenSSL 3, come abbiamo visto sopra, sono “default”, che contiene le implementazioni degli algoritmi di uso comune, “legacy”, che contiene le implementazioni di algoritmi meno recenti (ad es. DES, MDC2, MD2, Blowfish, CAST), e “fips” che contiene l’OpenSSL FIPS Cryptographic Module.

OpenSSL 3.0 è estramemente retrocompatibile e nel 98% dei casi sarà sufficiente ricompilare le applicazioni che ne fanno uso.

Veniamo adesso ad una novità di OpenSSL 3 che ci riguarda da vicino, l’uso di OpenSSL per firmare digitalmente i documenti con valore legale in Europa. Prima della versione 3 di OpenSSL non era possibile farlo, in quanto la normativa italiana ed europea richiede che la firma digitale sia conforme alle specifiche CAdES (CMS Advanced Electronic Signatures). In particolare, quello che mancava ad OpenSSL, era l’aggiunta di alcuni attributi obbligatori, quali, ad esempio ESS signing-certificate-v2 La sezione 5.7.3 dell’RFC (tools.ietf.org/html/rfc5126#section-5.7.3) fornisce i dettagli di questi attributi. Non ci prolungheremo oltre sul formato della firma digitale, anche qui, su Internet c’è molto materiale se si vuole approfondire. A fine 2018 noi, con la collaborazione degli altri sviluppatori di OpenSSL, abbiamo scritto una piccola patch che aggiunge questo attributo. il 27 gennaio del 2019 il codice è entrato a far parte del “master” di Openssl (v. mta.openssl.org/pipermail/openssl-commits/2019-January/021722.html) e già dalla la prima versione alpha il supporto CAdES è entrato a far parte di OpenSSL 3.

Fin quando OpenSSL 3 non sarà ritenuta stabile e quindi entrerà a far parte delle distribuzioni, il suo utilizzo sarà destinato agli sviluppatori o agli utenti esperti (coloro cioè che compilano da sorgenti e conoscono l’ambiente di sviluppo nei particolari). Facciamo un passo indietro, abbiamo detto che con OpenSSL 3 i Provider prenderanno il posto di molte funzionalità di OpenSSL finora presenti nelle librerie base o nei moduli ENGINE. Finchè questo non sarà avvenuto completamente OpenSSL supporterà i moduli ENGINE. Per quanto riguarda la firma digitale abbiamo bisogno di un modulo ENGINE chiamato PKCS11, facciamo una digressione su questo acronimo. I PKCS (Public-Key Cryptography Standards) sono delle specifiche prodotte dalla RSA inc., in collaborazione con sviluppatori sparsi in tutto il mondo, al fine di incrementare l’uso della tecnica di cifratura a chiave asimmetrica, grazie alle vasta documentazione e alle molte implementazioni, sono diventati dei veri e propri standard. Proprio in questi giorni uno sviluppatore dell’Ibm sta iniziando a lavorare ad un provider PKCS11 per OpenSSL 3 (v. github.com/p-steuer/pkcs11provider). Nell’attesa useremo un ENGINE PKCS11 che abbiamo scritto noi e che si trova sulla nostra pagina github all’indirizzo: github.com/opensignature/openssl/tree/signonly-pkcs11-engine.

La procedura per usare l'ENGINE PKCS11 con la nuova versione di OpenSSL è descritta sempre nel nostro sito alla pagina dedicata blia.it/firmadigitale.

Si conclude con questa pagina la breve storia di OpenSSL, dagli arbori alla versione 3 in prossima uscita.
Invitiamo gli utenti del sito a scriverci nel caso riscontrino errori nel testo o parti poco chiare.

Ciao