Certificati digitali e infrastrutture a chiave pubblica

Certificati digitali e infrastrutture a chiave pubblica Laboratorio del corso Sicurezza dei sistemi informatici (03GSD) Politecnico di Torino AA 2016/17 Prof. Antonio Lioy preparata da: Cataldo Basile (cataldo.basile@polito.it) Andrea Atzeni (shocked@polito.it) v. 1.24 (14/11/2016) Scopo dell esercitazione Scopo di questo laboratorio è di familiarizzare con la struttura di un certificato digitale X.509 e con le principali operazioni e formati tipicamente adottati per manipolarli. L esercitazione è basata sull uso della libreria OpenSSL (e dei tool associati) che offre un supporto completo alla gestione di certificati X.509 e alla gestione di una semplice CA, nonchè un supporto per i formati PKCS#7 e PKCS#12. Scopo della prima parte dell esercitazione è di permettere da un lato di sperimentare le procedure di richiesta di certificati a chiave pubblica X.509 destinati ad utenti finali e/o server applicativi e dall altro di acquisire una maggiore familiarità nell analisi dei diversi formati con cui può essere rappresentato un certificato X.509. In particolare, in questo laboratorio userete i comandi OpenSSL per (i) creare una richiesta di certificato X.509; (ii) emettere un certificato digitale X.509 per un utente finale (persona fisica); (iii) revocare un certificato digitale X.509. Inoltre, sperimenterete i comandi OpenSSL per ispezionare il contenuto di certificati digitali espressi nei formati DER e PEM, e per verificare la correttezza di un certificato X.509. La seconda parte del laboratorio si focalizza sui formati usati per manipolare i certificati e le firme digitali, in particolare il formato dei messaggi usati per il trasporto sicuro tra diversi host di chiave privata e certificato associato, cioè il formato PKCS#12; il formato usato per contenere la firma digitale insieme ad altri dati necessari (quali informazioni e certificato del firmatario), cioè il formato PKCS#7. Lo script Ca.pl Per creare e gestire una semplice Certification Authority (CA), si può usare il comando CA.pl, distribuito sempre con OpenSSL. CA.pl è uno script perl che permette di gestire da riga di comando le principali funzionalità di una CA. La sintassi è la seguente: CA.pl [-newca] Con l opzione -newca si può creare un intera CA hierarchy. A seguire, interattivamente tramite linea di comando, bisogna inserire tutti i dettagli della nuova CA. Tutti i file principali vengono creati nella cartella democa. Per maggiori informazioni su CA.pl, leggere il man: man CA.pl 1

openssl req Il comando OpenSSL req serve a creare una richiesta di certificato X.509 in formato PKCS#10. La sintassi di req è la seguente: openssl req [-in file] [-out file] [-newkey arg] [-key file chiave] [-text] [-pubkey] [-noout] [-keyout file] in cui: -in file, legge la richiesta dal file file (serve solo se non viene usata l opzione -newkey); -out file, salva nel file file la richiesta; -newkey arg, permette di creare una nuova chiave privata e la richiesta di certificato. Il parametro arg può essere espresso in due modi: (1) rsa:nbits genera una chiave RSA il cui modulo è lungo nbits bit; (2) dsa:filename genera una chiave DSA usando i parametri passati nel file filename; -key file chiave, crea una richiesta a partire da un chiave privata esistente e memorizzata nel file file chiave; -text, stampa la richiesta in forma testuale; -pubkey, estrae la chiave pubblica e la produce in output; -noout, non stampa la versione codificata della richiesta (utile con -text); -keyout file, salva nel file la chiave privata generata. Per una lista completa delle opzioni, potete invocare il manuale con: man req openssl ca Per emettere o revocare un certificato X.509, si può usare il comando OpenSSL ca, il quale implementa una CA minimale in grado di firmare richieste di certificato (espresse secondo diversi formati) e generare la Certificate Revocation List (CRL). Inoltre ca mantiene un database testuale dei certificati emessi e del loro stato. La sintassi è la seguente: openssl ca [-in filename] [-out filename] [-revoke filename] [-gencrl] in cui: -in filename, indica che il file filename contiene la richiesta da firmare; -out filename, salva il certificato generato nel file filename; -revoke filename, indica che il file filename contiene il certificato da revocare. È importante notare che una CA generata con CA.pl memorizza tutti i certificati emessi nella cartella newcerts con nome <serial number>.pem. Quindi per revocare un certificato è importante solo conoscere il serial number o ricavarlo tramite i dati dell utente memorizzati nei certificati in newcerts. Inoltre l opzione -revoke aggiorna lo stato del file index.txt; -gencrl, indica che deve essere prodotta la CRL (sulla base dei dati gia presenti in index.txt). Ulteriori informazioni su questo comando si ottengono tramite: man ca 2

openssl x509 Per firmare ed estrarre in formato testuale informazioni sui certificati X.509 si può usare il comando OpenSSL x509. In particolare con x509 si possono visualizzare le informazioni relative ad un certificato e convertire certificati in diversi formati. Si possono inoltre modificare i trust settings dei certificati (si comporta cioè come una mini CA ). La sintassi è la seguente: openssl x509 [-inform DER PEM] [-outform DER PEM] [-in file] [-out file] [-noout] [-req] [-text] in cui: -inform DER PEM, specifica il formato di input in cui PEM è la codifica Base64 del certificato DER; -outform DER PEM, specifica il formato di output; -in file, indica di leggere il certificato dal file specificato; -out file, salva il certificato in nel file specificato; -noout, indica di non produrre in output la rappresentazione Base64 del certificato; -req, indica che il file file passato mediante l opzione -in contiene una richiesta e non un certificato (come si aspetterebbe di default); -text, visualizza tutti i dettagli del certificato in formato testuale; s Ulteriori dettagli sono disponibili tramite: man x509. openssl verify Il comando OpenSSL verify permette di verificare un certificato e tutta la sua catena di certificazione. L operazione di verifica consiste in una serie di operazioni separate. Viene prima costruita la catena di certificati fino alla root CA (cioè il primo certificato self signed che trova) usando i nomi (DN) degli issuer. Viene inoltre verificato che l issuer possa emettere certificati (estensione KeyUsage). La seconda operazione verifica che il purpose, lo scopo per cui viene usato il certificato, sia corretto (per maggiori informazioni guardate la sezione CERTIFICATE EXTENSIONS del man del comando x509). La terza operazione consiste nel verificare che la CA sia fidata. Infine, vengono verificate le validity di ogni certificato (notbefore e notafter) e le firme digitali. Il certificato è considerato valido solo se tutte le operazioni vengono completate con successo. Notate che, se una verifica fallisce, l output è spesso criptico, ad esempio: server.pem: /C=AU/O=CryptSoft Pty Ltd/CN=Test CA (1024 bit) error 24 at 1 depth lookup:invalid CA certificate contiene il nome del certificato da verificare ed il subject, il codice di errore ed il numero di certificati (depth) esaminati prima che si verificasse l errore (0 è il certificato stesso, 1 la sua CA,... ). La sintassi è la seguente: openssl verify [-CAfile file] [-verbose] [certificates] in cui: 3

-CAfile file, indica che il file file contiene la lista di tutti i certificati fidati sotto forma di concatenazione (append) di certificati in formato PEM; -verbose, stampa informazioni aggiuntive sulle operazioni di verifica; certificates, rappresenta la lista di uno o più certificati da verificare (tutti in formato PEM). Ulteriori informazioni tramite: man verify. openssl crl Il comando OpenSSL crl permette di manipolare una Certificate Revocation List (CRL). openssl crl [-inform PEM DER] [-outform PEM DER] [-text] [-in filename] [-out filename] [-noout] [-hash] [-issuer] [-lastupdate] [-nextupdate] [-CAfile file] [-CApath dir] -inform (PEM DER), specifica il formato di input (DER o PEM). PEM (il default) è una versione codificata base64, racchiusa tra righe di intestazione ed a piè di pagina. DER è analogo ma usa invece una codifica binaria; -outform (PEM DER), specifica il formato di output, le opzioni mantengono stesso significato di -inform; -in filename, specifica il nome del file di input (se questa opzione non è specificata, si tratta di standard input); -out filename, specifica il nome del file di output per scrivere la CRL risultante (o standard output se questa opzione è assente); -text, stampa la CRL in forma testuale human-readable ; -noout, non crea la CRL; -hash, crea un hash dell issuer name. Utile in caso di ricerca di CRL all interno di una directory; -issuer, stampa l issuer; -lastupdate, stampa il campo lastupdate; -nextupdate, stampa il campo nextupdate; -CAfile file, verifica la firma della CRL usando il certificato presente nel file file; -CApath dir, verifica la firma della CRL usando il certificato presente nella directory dir. Questa directory deve essere una directory in formato standard, cioè per ogni certificato contenuto nella directory deve essere presente un hash (ricavato usando il comando x509 -hash); Ulteriori informazioni tramite: man crl. 4

openssl ocsp Il comando ocsp svolge molte attività comuni inerenti il procollo OCSP (On-line Certificate Status Protocol). Può essere usato per stampare le richieste e le risposte, creare richieste e inviare query ad un server OCSP e può agire di per sé come mini server OCSP. openssl ocsp [-issuer file] [-cert file] [-reqout file] [-index file] [-port num] [-rsigner file] [-CA file] [-out file] -out file, specifica il nome del file di output, di default è lo standard output; -issuer file, specifica il certificato dell autorità di certificazione. Questa opzione può essere usata più volte. Il certificato specificato nel nome del file deve essere in formato PEM. Questa opzione deve venire prima di qualsiasi opzione -cert. -cert file, nome del certificato da controllare. Il certificato dell autorità è tratto dall opzione precedente, o si verifica un errore se un Autorità di certificazione non è specificata; -reqout file, scrive la richiesta in formato DER su file; -index file, dove file è un index file in formato testuale contenente informazioni sui certificati revocati. Se viene specificata l opzione, l utility ocsp è in modalità responder, altrimenti è in modalità client. Se questa opzione è presente allora anche le opzioni di CA e rsigner devono essere presenti; -port num, dove num è la porta su cui ascoltare per ricevere le richeiste ocsp. La porta può anche esser specificata tramite l opzione url; -rsigner file, dove file è il certificato con cui firmare le richieste ocsp; -CA file, dove file è il certificato della CA corrispondente alle informazioni di revoca nel file del comando index; Ulteriori informazioni tramite man ocsp. Altri comandi Nel corso dell esercitazione dovrete scambiarvi dati da un computer all altro col comando scp. Abilitate quindi il server ssh: /etc/init.d/ssh start 1 Infrastrutture a chiave pubblica 1.1 La Certification Authority (CA) Come prima cosa, create una CA di prova chiamata Test CA con lo script Perl CA.pl: /usr/lib/ssl/misc/ca.pl -newca ATTENZIONE: la tentazione di premere Invio ripetutamente o scrivere valori a caso per ognuno dei campi richiesti è molto forte. Tuttavia vi consigliamo di scrivere con cura questi dati, infatti una CA non emette certificati per subject il cui DN non è figlio del suo DN. Annotate quindi qui i seguenti campi: countryname = stateorprovincename = organizationname = organizationalunitname = 5

Figura 1: Struttura della CA di prova. che vengono prodotti in output dopo la creazione della CA. Riuscite a identificare i passi seguiti dalla procedura di creazione della nuova CA? Al termine, la procedura avrà creato nella directory di lavoro una struttura di directory come in Figura 1. La chiave privata della CA è contenuta nel file cakey.pem. Il certificato della CA è contenuto nel file cacert.pem: con che chiave è firmato questo certificato? Due importanti file accessori sono serial (contiene il numero di serie del prossimo certificato da emettere) e index.txt (contiene l elenco dei certificati emessi ed il relativo stato): perché la CA deve tener traccia dei certificati emessi? 1.2 Richiesta ed emissione di certificati digitali Ora formate delle coppie: Alessandro preparerà una richiesta di certificato da inviare a Carlo in qualità di CA. Scrivete il comando OpenSSL per generare una nuova richiesta di certificato per una coppia di chiavi RSA a 2048 bit. Inserite le informazioni richieste rispettando quanto annotato in precedenza. Suggerimento: potete creare la coppia di chiavi RSA come fatto nella precedente esercitazione (genrsa) oppure usare direttamente il comando req per generare una nuova coppia di chiavi. Prima di procedere salvate (o rinominate) la coppia di chiavi in ale rsakey.pem e salvate la richiesta di certificato in ale certreq.pem. Esaminate ora la richiesta di certificato appena prodotta: openssl req -in ale certreq.pem -text -noout Identificate natura e scopo delle diverse informazioni presenti: cosa rappresenta l ultimo campo? A cosa serve? 6

Non resta che inoltrare la richiesta alla CA: Alessandro invia ale certreq.pem a Carlo. Scrivete il comando OpenSSL che Carlo deve eseguire per processare la richiesta di Alessandro, emettere un nuovo certificato, e salvarlo in ale cert.pem (suggerimento: usate il comando ca): Quali sono stati i cambiamenti nella base dati della Test CA di Carlo? Carlo può ora inviare il certificato a Alessandro che può visionare il certificato appena ricevuto usando il comando x509 di OpenSSL: openssl x509 -in ale cert.pem -text Ora, scrivete il comando OpenSSL che Alessandro dovrà eseguire per verificare il certificato ricevuto (suggerimento: comando verify): Di quale dati aggiuntivi ha bisogno Alessandro? 1.3 Revoca di certificati 1.3.1 Controllo dello stato del certificato tramite CRL Scrivete il comando OpenSSL che Carlo può eseguire per revocare il certificato emesso ad Alessandro nel precedente esercizio: Quali sono stati i cambiamenti nella base dati della Test CA di Carlo? Infine scrivete il comando per generare una nuova Certificate Revocation List (CRL) nel file crl.pem: 7

Carlo può ora pubblicare la CRL. Beatrice, una volta ottenuta la nuova CRL pubblicata da Carlo, può esaminarla con il comando: openssl crl -in crl.pem -text Individuate la funzione dei diversi campi contenuti nella CRL. Quando sarà emessa la prossima CRL? Cosa indica il campo Revocation Date? Modificate il comando precedente per permettere a Beatrice di verificare la CRL: 1.3.2 Controllo dello stato del certificato tramite OCSP (opzionale). Immaginate Carlo operi anche come server OCSP per permettere il controllo online dello stato di revoca del certificato. In questo contesto, trovate i comandi OpenSSL che possono essere usati da Beatrice per costruire una richiesta OCSP e mandarla a Carlo (suggerimento: partite dal comando ocsp di OpenSSL) 2 Uso di certificati digitali in scenari applicativi 2.1 Validazione di messaggi firmati Create un gruppo di tre host: Alessandro, Beatrice e Carlo coi seguenti ruoli: Carlo è la Certification Authority; Alessandro richiede un certificato a Carlo per poter firmare i messaggi da inviare a Beatrice; Beatrice riceve i messaggi da Alessandro e ne effettua verifica. I passi da svolgere sono i seguenti: Alessandro genera una richiesta di certificato che invia a Carlo; Carlo emette il certificato per Alessandro e glielo invia; Alessandro crea un messaggio di testo e lo salva nel file msg1. Poi aggiunge in coda l ora di firma (es. scrivendola (append) al fondo del file) ed immediatamente dopo usa la sua chiave privata (la cui parte pubblica è presente nel certificato) per firmarlo. Alessandro salva la firma nel file msg1.firma. Supponiamo che la firma sia stata apposta al tempo t 1, ad esempio alle 12:06 del 21/11/2014; 8

Carlo revoca il certificato di Alessandro al tempo t 2 > t 1 (es. 12:10 del 21/11/2014), successivamente emette la CRL al tempo t 3 (es. 13:02, in tal caso il CRL s Last Update field sarebbe 21 November 2014, 13:02, ed il CRL s Next Update field sarebbe 21 December 2014, 13:02); Alessandro crea un secondo messaggio, lo salva nel file msg2. Poi appende al fondo l ora di firma (es. scrivendola (append) direttamente nel file) ed usa la sua chiave privata (la cui parte pubblica è presente nel certificato) per firmarlo. Alessandro salva il messaggio firmato nel file msg2.firma. Supponiamo che la firma sia stata apposta al tempo t 4 > t 3 (es. 13:10 del 21/11/2014, scriverlo direttamente nel file); Alessandro crea un terzo messaggio, lo salva nel file msg3 ed usa la sua chiave privata (la cui parte pubblica è presente nel certificato) per firmarlo. Alessandro salva il messaggio firmato nel file msg3.firma. Il terzo file non contiene alcuna indicazione sul tempo di firma; Alessandro invia a Beatrice i file msg1, msg2, msg3 and msg1.firma, msg2.firma, msg3.firma ed il suo certificato; Beatrice riceve i file di Alessandro e deve decidere quali sono firme sono valide, supponendo che Carlo sia una CA fidata per Beatrice (includendo il certificato di Carlo nel trusted ca.pem). Supponiamo che Beatrice usi la seguente procedura semplificata, per esempio su msg1: 1. verifica che la firma sia stata apposta con la chiave privata corrispondente a quella pubblica presente nel certificato che Alessandro le ha inviato; 2. verifica che la firma sia stata apposta prima che il certificato di Alessandro fosse revocato. Quali operazioni l inesperta Beatrice ha dimenticato nel verificare la firma di msg1? (minimo due operazioni!!) Modificate la procedura in modo che sia corretta e completa: Scrivete la sequenza di comandi OpenSSL necessari ad implementare tale scenario. Suggerimento: è necessario usare diversi comandi perché dgst non accetta certificati ma è necessario passare la chiave pubblica vera e propria. 9

Quale è lo stato del certificato (revocato o non revocato) che Beatrice dovrà assegnare in tre momenti diversi, prima di t 2 (es. 12:09), tra t 2 e t 3 (es. 12:30) e dopo t 3 (es. 13:30)? Da quando il certificato di Alessandro sarà considerato invalido? Motivate le risposte: Quali messaggi tra msg1, msg2, msg3 saranno considerati validi da Beatrice? Completate la Tabella 1 con i seguenti valori: V (se lo considera valido) and I (per invalido) e motivate la risposta. Messaggio Tempo di firma t < t 2 t 2 < t < t 3 t > t 3 Motivazione msg1 21/11/2014 12:06 msg2 21/11/2014 13:10 msg3 21/11/2014??:?? Tabella 1: Validità dei messaggi firmati. Quale tecnologia/protocollo avrebbe potuto usare Beatrice per avere gli stessi risultati da una Trusted Third Party? Se Alessandro inviasse il file trusted ca.pem a Beatrice insieme agli altri messaggi, Beatrice dovrebbe fidarsi del suo contenuto? Motivate la risposta: E se Alessandro inviasse a Beatrice anche la CRL (emessa da Carlo) insieme agli altri messaggi, Beatrice potrebbe fidarsi? Motivate la risposta: 2.2 Formati sicuri (Opzionale) Per favorire l interoperabilità di applicazioni basate su certificati digitali sono utilizzati diversi formati standard: 10

1. PKCS#7 - formato per buste sicure: in particolare permette di creare buste cifrate, firmate o cifrate e firmate che possono contenere dati (cifrati e/o formati), chiavi simmetriche (cifrate), firme digitali, catene di certificati, CRL. Questo formato è usato per importare catene di certificati di CA all interno di IE o Mozilla. Ulteriori dettagli su questo formato sono disponibili nei seguenti documenti: RFC-2315 che presenta il PKCS#7 v.1.5; RFC-5652 che presenta il Cryptographic Message Syntax (CMS), estensione del PKCS#7 v.1.5 mantenuta dall IETF. 2. PKCS#7 degenerated mode - formato derivato dal tipo PKCS#7 SignedData contenente unicamente catene di certificati e eventualmente CRL. Questo formato è usato per importare catene di certificati di CA all interno di IE o Mozilla. 3. PKCS#12 - formato derivato dal tipo PKCS#7 EncryptedData contenente la chiave privata, il corrispondente certificato e il certificato della CA emittente cifrati a partire da una password. È usato per importare una coppia di chiavi e relativo certificato in Mozilla o IE. Ulteriori informazioni sono disponibili presso PKCS#12 RSA Security. I precedenti formati sono solitamente codificati in due modi: 1. DER - rappresentazione binaria dei formati precedenti; Windows usa le estensioni.cer o.der per file contenenti direttamente un singolo certificato, l estensione.p7b per un file PKCS#7, l estensione.p12 per file PKCS#12. S/MIME usa le estensioni.p7m e.p7s per buste PKCS#7, rispettivamente cifrate e firmate. 2. PEM - codifica base64 della rappresentazione binaria in DER. Rappresentazione standard usata dai comandi OpenSSL e supportata da tutte le applicazioni più diffuse. L estensione.pem è quella più comunemente usata. Per esempio, un certificato digitale codificato PEM è contenuto tra i delimitatori: ------BEGIN CERTIFICATE----- ------END CERTIFICATE----- Windows usa l estensione.cer per identificare questo tipo di file quando contiene un singolo certificato. OpenSSL offre una serie di comandi per la manipolazione dei precedenti formati e conversione tra essi. 2.3 Conversione tra formati Potete usare i seguenti comandi OpenSSL per convertire un certificato da DER a PEM e vice versa: convertire un certificato da formato DER a PEM: openssl x509 -inform DER -in file.der -outform PEM -out file.pem convertire un certificato da formato PEM a DER: openssl x509 -in file.pem -outform DER -out file.der convertire un file che contiene un lista di certificati in formato PEM (inclusi delimitatori) in una struttura PKCS#7: Esercizi: openssl crl2pkcs7 -nocrl -certfile file.pem -outform PEM -out file.pkcs7 1. convertite il certificato creato nell esercizio 1.2 da formato PEM a DER. Poi riconvertitelo in PEM! 2. scrivete il comando OpenSSL per visualizzare i campi di un certificato in formato DER 11

Buste PKCS#12 Scoprite il comando OpenSSL per creare nel file ale cert.p12 una busta PKCS#12 contenente il certificato creato nell esercizio 1.2, la corrispondente chiave privata, e il certificato della CA che ha emesso il certificato: Buste PKCS#7 Come detto in precedenza il formato PKCS#7 supporta diversi tipi di imbustamento. La sintassi generale di una busta PKCS#7 è definita in notazione ASN.1 e come radice specifica un singolo elemento chiamato ContentInfo strutturato come segue: ContentInfo ::= SEQUENCE { contenttype ContentType, content [0] EXPLICIT ANY DEFINED BY contenttype OPTIONAL } contenttype ::= OBJECT IDENTIFIER I campi di ContentInfo hanno il seguente significato: contenttype è il tipo di dati, espresso attraverso un OBJECT IDENTIFIER cioè un sequenza di numeri interi assegnata in modo univoco da un autorità. Lo standard PKCS#7 definisce sei tipi base: data è il tipo di dato più semplice ed indica una mera sequenza di byte la cui interpretazione è lasciata alla specifica applicazione; signeddata è il tipo di dato da impiegare quando si ha la necessità di utilizzare firme digitali: vi è la definizione di un insieme di strutture accessorie necessarie per conservare tutte le informazioni utili del processo di firma; envelopeddata è il tipo di dato da impiegare quando le informazioni da elaborare devono essere cifrate con schema a chiave pubblica RSA; signedandenvelopeddata è il tipo di dato da utilizzare quando le informazioni da elaborare devono essere protette con cifratura a chiave pubblica RSA e contemporaneamente accompagnate da firma digitale; digestdata è il tipo di dato che si può utilizzare qualora le informazioni da trasportare debbano essere accompagnate da un hash calcolato sulle informazioni stesse; encrypteddata è il tipo di dato che si può utilizzare se le informazioni devono essere cifrate con uno schema crittografico simmetrico. Questo tipo non provvede alcun mezzo per gestire le chiavi in gioco che devono quindi essere manipolate per altre vie. content è il contenuto definito da contenttype. Ora procedete come segue: create un messaggio di testo ad esempio Questo è un messaggio per l imbustamento pkcs7 e salvatelo nel file msg. eseguite quindi il seguente comando OpenSSL: openssl smime -sign -in msg -out p7s.pem -outform PEM -signer ale cert.pem -inkey ale rsakey.pem -certfile democa/cacert.pem dove ale pkey.pem è la vostra chiave privata, ale cert.pem è il certificato creato nell esercizio 1.2 e cacert.pem è il certificato della CA create nell esercizio 1.1. 12

ora visualizzate la struttura ASN.1 della busta PKCS#7 con il seguente comando: openssl asn1parse -in p7s.pem -i less Cercate di identificare i campi importanti guardando nell ultima colonna. Quale dei sei tipi definiti sopra è stato usato per l imbustamento? Riuscite a identificare quali certificati sono allegati alla busta p7s.pem? Cosa è contenuto nella struttura pkcs7 data? Quali algoritmi crittografici sono stati usati? In cosa differisce il seguente comando da quello precedente? openssl smime -sign -nodetach -in msg -out p7snd.pem -outform PEM -signer ale cert.pem -inkey ale pkey.pem -certfile democa/cacert.pem Verificate con il comando asn1parse. Scrivete il comando OpenSSL per verificare la firma sulla busta p7snd.pem: Cosa fa il seguente comando OpenSSL? openssl smime -encrypt -aes-128-cbc -in msg -out p7e.pem -outform PEM ale cert.pem Analizzate il file p7e.pem con il comando asn1parse. Quali algoritmi crittografici sono stati utilizzati? Scrivete il comando OpenSSL per decifrare la busta p7e.pem: 13