Formati di dati importanti

X.509

X.509 è lo standard per i certificati digitali. In passato esistevano alcuni concorrenti come OpenPGP, ma oggi sono molto meno utilizzati. Un momento però ... X.509 non è in realtà lo standard giusto. X.509 è propriamente uno standard ITU-T, mentre le definizioni che contano davvero fanno parte della RFC 5280, ossia di uno standard IETF e non ITU-T. La RFC definisce, sulla base di X.509, il "PKI Profile for the Internet", ed è l'unico profilo che nella pratica conti davvero.

Un certificato digitale si basa sulla crittografia asimmetrica e in particolare sulle firme digitali. Il caso d'uso più comune per un certificato digitale è oggi l'autenticazione dei server. Tutti li hanno già utilizzati, probabilmente senza sapere che si trattava di un certificato X.509: ogni volta che si accede a un sito web HTTPS, il browser stabilisce una connessione TLS con il server web. Il server web utilizza un certificato X.509 per dimostrare la propria identità. Ad esempio, quando si accede al sito della propria banca per disporre un bonifico, si vuole essere certi di comunicare davvero con la propria banca. Gli attaccanti potrebbero provare a impersonare il sito della banca, leggere la password e il TAN dell'utente e poi trasferire il denaro su un conto che controllano. HTTPS aiuta a impedirlo, perché gli attaccanti non dispongono del certificato X.509 del server web della banca. Quando il browser indica che si sta accedendo a un determinato dominio tramite una connessione HTTPS, il certificato garantisce che la connessione avvenga davvero con un server web di chi possiede quel dominio.

Come fa il certificato a ottenere questo risultato? Il certificato contiene alcuni metadati, la chiave pubblica di una coppia di chiavi crittografiche e una firma di un'autorità di certificazione. Vediamo le tre parti una per una:

Contenuto di un certificato X.509

Metadati

I metadati del certificato X.509 indicano, tra le altre cose, per quale periodo il certificato è valido, per quale scopo deve essere utilizzato e a chi è stato emesso. In particolare, per un certificato TLS di server, contengono il dominio del server web. Il browser confronta il dominio a cui ha tentato di accedere con quello presente nel certificato. Se non coincidono, il browser non prosegue e mostra un avviso. Se il certificato è scaduto, mostra ugualmente un avviso.

Curiosamente, i browser spesso non mostravano alcun avviso quando si accedeva a un sito HTTP senza TLS, benché questo sia ancora meno sicuro. Accedendo a un server web con un certificato X.509 non valido può trattarsi semplicemente di una configurazione errata, e la connessione potrebbe comunque essere al riparo da attaccanti che la spiano, mentre una connessione HTTP non offre alcuna protezione.

Su questo fronte ci sono comunque dei progressi, ad esempio il certificate pinning. Si tratta però di un argomento avanzato, quindi conviene passare agli altri due elementi presenti in un certificato X.509.

Chiave pubblica

Il certificato contiene la parte pubblica di una coppia di chiavi asimmetrica. La crittografia consente al server web, o più in generale al titolare del certificato in altri casi d'uso, di dimostrare di possedere anche la parte privata della coppia di chiavi senza esporla al client che si connette né ad altri. Il client può quindi essere certo che il server web sia davvero il proprietario del certificato e non qualcuno che lo ha semplicemente copiato. Copiare il certificato in sé è in effetti piuttosto semplice, dato che il server web ne invia una copia a chiunque tenti di connettersi. Sottrarre la chiave privata è invece difficile o impossibile, perché non lascia mai il server web. Esistono diversi metodi per rendere ancora più difficile la sottrazione della chiave privata, ad esempio HSM e TPM.

Firma di un'autorità di certificazione

I metadati consentono al client di verificare che il certificato sia adatto allo specifico caso d'uso. La chiave pubblica dimostra che la controparte è davvero il proprietario del certificato. Ma un attaccante potrebbe semplicemente creare una nuova coppia di chiavi e un nuovo certificato che soddisfano anch'essi questi due criteri. Come può allora un client sapere che il certificato è affidabile?

Il certificato contiene una firma crittografica prodotta con un'altra coppia di chiavi, appartenente al certificato di un'autorità di certificazione (CA). Il certificato della CA può essere verificato allo stesso modo ed è a sua volta firmato da un certificato. Il client può seguire questa "catena di fiducia" dal cosiddetto certificato foglia fino al certificato della Root CA, che riconosce dal fatto di essere autofirmato, ossia la firma del certificato proviene dalla sua stessa coppia di chiavi. Di norma si tratta di uno o due passaggi soltanto, quindi sono coinvolti solo uno o due certificati CA.

Le CA devono verificare con attenzione che i metadati siano corretti quando emettono un certificato. Ad esempio, per ottenere un certificato TLS di server per il proprio dominio occorre dimostrare alla CA di esserne davvero il titolare. A seconda del grado di accuratezza di questa verifica si ottiene un certificato di base oppure un certificato Extended Validation (EV).

Ogni browser e ogni sistema operativo include un elenco predefinito di Root CA attendibili. Utenti e amministratori possono aggiungere altre Root CA attendibili. Alcune Root CA sono considerate attendibili solo per scopi specifici, altre godono di una fiducia più generale. Il client verifica se la catena di fiducia termina in una Root CA attendibile. In tal caso, e se tutti i certificati della catena sono ancora validi e i metadati indicano che vengono utilizzati secondo la loro finalità, il certificato foglia del server web è considerato attendibile e la connessione viene stabilita.

Validità dei certificati X.509

Nei certificati X.509 tutto ruota attorno alla fiducia, che va prima costruita. Come spiegato, un criterio di questa fiducia è che il certificato risalga fino a una Root CA attendibile. Un altro è che si trovi all'interno del proprio periodo di validità. Di solito questo significa che non è scaduto, ma, in genere a causa di errori tecnici, un certificato può anche non essere ancora valido. C'è però un ulteriore criterio: la CA che ha emesso il certificato non deve averlo revocato. Poiché si tratta di un argomento a sé, gli abbiamo dedicato un articolo separato.

PKCS#7

PKCS#7 è il coltellino svizzero dei formati di dati crittografici e può contenere praticamente qualsiasi cosa: messaggi cifrati, messaggi firmati, messaggi firmati e cifrati, certificati e chiavi private

Questo è anche il principale svantaggio del formato. Quando un'applicazione o un utente riceve un PKCS#7, non è di per sé chiaro che cosa farne. Ecco alcuni casi d'uso importanti:

• I messaggi S/MIME sono in sostanza email con corpo o allegati in formato PKCS#7.
• Le richieste e le risposte SCEP sono entrambe, di fatto, messaggi firmati PKCS#7.
• Le risposte EST sono messaggi CMS.

Codifica

Le estensioni di file più comuni sono .p7b (codifica DER), .p7s (un messaggio firmato o la firma di un messaggio) e .p7m (un messaggio firmato e/o cifrato). È definita anche la codifica PEM con etichetta "PKCS7", ma viene usata raramente.

Strumenti

In Windows è possibile aprire i messaggi PKCS#7 con un doppio clic e le estensioni Crypto-shell li visualizzano. Di norma, però, se ne possono estrarre solo i certificati e le relative chiavi private, non il contenuto dei messaggi.

Questi file si possono convertire in altri formati con strumenti come OpenSSL.

PKCS#10

Una richiesta di firma del certificato (CSR) come definita in PKCS#10 è un file che contiene la descrizione di un certificato che si desidera ottenere da un'autorità di certificazione (CA). Ha una struttura simile a quella di un certificato X.509, ma manca della firma di una CA. Contiene invece la firma di chi richiede il certificato. Resta comunque un formato diverso, quindi non equivale a un certificato autofirmato.

Può essere in formato binario con codifica DER oppure con codifica PEM utilizzando l'etichetta "CERTIFICATE REQUEST".

PKCS#12

PKCS#12 è noto anche come PFX, soprattutto negli ambienti Windows. Le estensioni di file più comuni sono quindi .pfx e .p12. Contiene certificati X.509 e quasi sempre le corrispondenti chiavi private, anche se tecnicamente questo non è imposto.

I dati di un file PKCS#12 sono di solito cifrati con password. Spesso è cifrata solo la chiave privata, quindi si potrebbero estrarre i certificati senza conoscere le password, se l'applicazione lo consente (la maggior parte non lo permette). PKCS#12 è il modo più comune negli ambienti Windows per conservare un certificato e la relativa chiave privata in un file. Negli ambienti Linux sono invece più diffusi i file PKCS#8 con codifica PEM.

Poiché lo standard offre molte opzioni su come conservare certificati e chiavi private in "safebag" annidati, i file PKCS#12 presentano alcuni problemi di compatibilità, ad esempio:

• Windows è noto per associare le chiavi private di un PKCS#12 a tutti i certificati estratti dal file, non solo a quello a cui sono destinate. Se il PKCS#12 contiene una catena di certificati, Windows potrebbe indicare di possedere la chiave privata del certificato CA.
• Su macOS non è possibile importare file PKCS#12 se gli algoritmi crittografici sono troppo recenti.
• Può essere necessario cifrare i certificati contenuti in un file PKCS#12 affinché le applicazioni riceventi possano estrarli. Alcune però supportano solo algoritmi molto vecchi e deboli, il che di norma non è un problema, dato che si tratta comunque di informazioni pubbliche. OpenSSL 3.x, tuttavia, non supporta questi algoritmi obsoleti e vulnerabili e si rifiuta di aprire il PKCS#12.

ASN.1 e PEM

L'Abstract Syntax Notation One (ASN.1) è un linguaggio utilizzato per descrivere strutture di dati. Esistono alcuni tipi di dati di base predefiniti, come gli interi o le sequenze, e chi redige un protocollo o un formato di file può poi definire tipi di dati personalizzati a partire da quelli di base.

Codifica DER

Lo standard ITU-T X.680 definisce diverse codifiche per i dati specificati in ASN.1. Per i dati legati a X.509 la codifica più importante è DER, perché esiste un solo modo di codificare un tipo: un hash della rappresentazione binaria DER del tipo avrà quindi sempre lo stesso valore, il che è importante ad esempio quando si firmano dati codificati in ASN.1.

Codifica PEM

Per molti, ma non per tutti i tipi di file legati a X.509, si può conservare il file in forma binaria con codifica DER oppure applicare una codifica PEM aggiuntiva sopra la codifica DER. PEM utilizza solo caratteri ASCII e può quindi essere copiato e incollato facilmente negli appunti o, qualche decennio fa quando la cosa era ancora rilevante, inviato per email.

Strumenti

Se si dispone di un file codificato in ASN.1 e non se ne conosce il tipo, oppure non si ha un'applicazione in grado di gestire quel tipo specifico, è comunque possibile decodificare la struttura ASN.1 grezza e vedere che cosa contiene. In Windows lo strumento integrato certutil può farlo con il comando certutil -decode.