Sicurezza in Internet

Si chiama server sicuro un server che usa dei certificati digitali. Cos'è un certificato digitale, come si ottiene e come si usa: qui rispondiamo a questi quesiti in modo breve.

C'è da premettere un fatto tecnico di base, che sta alla base di tutto il discorso: la possibilità di crittografare, ossia scrivere in modo che solo chi ha la chiave possa comprendere. Una chiave non è altro che una sequenza di byte, solitamente viene interpretata come un numero molto grande. A seconda del cifrario che si usa, può essere richiesto che la chiave abbia diverse proprietà numeriche. La crittografia viene in due modi diversi: simmetrico e asimmetrico.

Nella crittografia simmetrica viene stabilita una sola chiave, da usare sia per crittare sia per decifrare il testo.

La crittografia asimmetrica usa due chiavi complementari: la chiave pubblica e la chiave privata. Ciò che viene crittato con l'una potrà essere decifrato solo con l'altra. In questo modo si risolve un problema di base della crittografia simmetrica: come scambiarsi la chiave. La chiave pubblica viene liberamente divulgata e quella privata gelosamente custodita.

Un secondo fatto tecnico riguarda la possibilità di creare un digest di un testo. Un digest, letteralmente un sommario o compendio del testo, è una breve sequenza di byte che dipende in modo pseudo-casuale dal testo. Esistono diversi procedimenti per computare i digest in modo che a testi anche di poco diversi corrispondano digest diversi e che non sia fattibile, dato un digest, modificare un testo in modo da ottenere proprio quel digest. Tra i più usati, SHA1 e MD5, cche oggi è sconsigliabile.

Con questi tre elementi, crittografia simmetrica, asimmetrica e digest, vengono costruiti i certificati digitali, le connessioni sicure, l'e-mail riservata, le firme digitali, eccetera.

Per firmare un testo bisogna leggerlo, ciò che in termini digitali significa calcolarne il digest. Se Alice dispone di una coppia di chiavi asimmetriche, può calcolare il digest di un testo secondo un certo procedimento e poi crittare il digest con la sua chiave privata. Così chiunque può decifrarlo usando la chiave pubblica di Alice. Chiunque può anche ricalcolare il digest dal testo originale. Usando lo stesso procedimento usato da Alice dovrebbe ottenere lo stesso digest. Allora, se il digest ricalcolato è uguale a quello decifrato, la firma è valida. Ovviamente, se il testo fosse stato alterato anche di una virgola, il digest risulterebbe diverso. Anche se il digest fosse stato crittato con una chiave diversa dalla chiave privata di Alice, si riconoscerebbe il falso. Il digest crittato con la chiave privata è la firma digitale di Alice in calce al testo.

Resta un punto debole: un falsario potrebbe generare una coppia di chiavi asimmetriche e distribuire la sua chiave pubblica facendo credere che si tratti della chiave pubblica di Alice. Con la sua chiave privata potrebbe crittare il digest di un testo e gli allocchi crederebbero che l'abbia firmato Alice. Uno dei metodi per evitare questo fraintendimento consiste nel chiedere a un'autorità di certificazione (CA, dall'inglese) di firmare digitalmente un testo in cui c'è scritto il nome di Alice, qualche altro dato rilevante, per esempio l'indirizzo e-mail, e la sua chiave pubblica. Questo testo firmato dalla CA si chiama un certificato digitale emesso (o rilasciato) dalla CA. Alice può far certificare la sua chiave pubblica da una o più CA cosicché sia possibile per chiunque verificare la sua firma basandosi su una chiave pubblica certificata.

Una certification authority (CA) è un qualsiasi ente che emetta certificati digitali. Per verificare un certificato si procede come per la verifica di una firma, ossia basandosi sulla chiave pubblica della CA. Questa può essere ottenuta dal certificato della CA. Il certificato della CA può essere firmato da un'altra CA, dando luogo a una catena. Il primo certificato della catena è sempre firmato dalla CA stessa che si autocertifica con quello che, in inglese, si chiama self signed certificate.

Un metodo alternativo è quello previsto da PGP (pretty good privacy). Questo si basa su catene di autorizzazioni basate sulla conoscenza personale, senza autorità centrali. Essere gratuito è solo uno dei vantaggi di questo metodo. L'altro è di essere in qualche modo più informale.

In Italia esiste una normativa che equipara la firma digitale a quella grafica ordinaria. A tale scopo è stata creata un'infrastruttura adatta. Il Centro nazionale per l'informatica nella pubblica amministrazione mantiene un elenco pubblico dei certificatori (da non confondersi con l'elenco dei gestori di posta elettronica, anche se alcuni enti svolgono entrambe le attività) che all'aprile 2007 conta 19 certificatori attivi. Una panoramica della legislazione si trova sul sito di I.T. Telecom.

Fin'ora la normativa non vieta l'utilizzo della crittografia e quindi lascia aperta la possibilità di usare certificati non qualificati dal punto di vista legale. Tra le CA che operano in questo modo è notevole EuroPKI, operante presso il politecnico di Torino. (PKI sta per public key infrastructures.) Essendo fondata su un progetto pubblico europeo, EuroPKI certifica gratuitamente cittadini ed enti europei.

Anzitutto si genera una coppia di chiavi asimmetriche. Per fare questo è necessario utilizzare il software adatto. I browser e i client di posta elettronica più diffusi possono generare e gestire coppie di chiavi asimmetriche. Esistono anche programmi specifici per eseguire quest'operazione, per esempio OpenSSL, che essendo open source non ha procedure, chiavi, o algoritmi segreti.

Data la coppia di chiavi, si compila una richiesta di certificato con la chiave pubblica e i dati del richiedente. Questi dati sono definiti secondo regole che dettano, per ciascun tipo di dato, sia il formato sia il significato. Per esempio, l'indirizzo e-mail è il dato ASN.1 di codice 1.2.840.113549.1.9.1. La chiave privata non fa parte della richiesta, ma viene utilizzata per firmare la richiesta stessa, in modo che la CA non possa alterare in alcun modo i dati contenuti.

Infine la richiesta viene spedita alla CA per essere controfirmata. In questo modo si ottiene il certificato. Nei browser generazione e spedizione sono unificati in un solo passaggio, in quanto il browser trova in un'apposita scrittura HTML la disposizione di generare la coppia di chiavi e inviare la richiesta di certificato. In genere il certificato non viene rilasciato immediatamente e il browser dovrà essere in grado di ritrovare la chiave privata corrispondente quando riceverà il certificato. Altri software possono escogitare metodi diversi per pervenire allo stesso risultato.

La parte interessante di un certificato è la chiave pubblica che esso contiene. Un testo crittato colla chiave privata di qualcuno può essere decifrato utilizzando questa chiave pubblica. Un altro elemento importante è il fingerprint, l'impronta digitale del certificato. Il fingerprint è un digest del certificato. Poiché tale digest è ragionevolmente corto, risulta pratico utilizzarlo per verificare una chiave. Il certificato di TANA-CA ha il seguente fingerprint:

L'espressione è in esadecimale, dove ogni cifra corrisponde a 4 bit (0=0000, 1=0001, 2=0010, ..., F=1111) e quindi ci vogliono due cifre esadecimali per ogni byte. Chiunque abbia inserito nel proprio browser questo certificato può verificare manualmente queste cifre per convincersi di avere scaricato il certificato corretto. Allo stesso modo un software che gestisce certificati può utilizzare queste cifre per il nome del file su cui ha salvato il certificato corrispondente, in modo da ritrovare agevolmente il certificato corrispondente a una chiave data.

Certificati personali

Quando Alice spedisce a Bob per e-mail un testo crittato e/o firmato, i certificati si usano nel seguente modo:

• Alice usa il certificato di Bob per crittare il testo. In questo modo solo chi possiede la chiave privata di Bob sarà in grado di decifrarlo. Per molteplici destinatari è necessario crittare il testo con la chiave di ciascuno.
• Alice usa il proprio certificato per firmare il testo (crittato o in chiaro). In questo modo chiunque possa ritrovare un certificato di Alice sarà in grado di assicurarsi che il testo è stato spedito da Alice.
• Bob utilizza la propria chiave privata per decifrare il testo.
• Bob utilizza il certificato di Alice per verificare che sia lei l'autrice del messaggio. Se il certificato di Alice contiene il suo indirizzo e-mail, il software è in grado di verificare che questo coincida coll'indirizzo e-mail del mittente del messaggio ricevuto. Se il messaggio è crittato il software non dovrebbe salvarlo in chiaro, in modo da non compromettere la riservatezza del messaggio. La chiave privata di Bob dovrebbe essere protetta da password oppure custodita in una cassaforte.

Per i certificati emessi da CA, solitamente in formato X509v3, i normali client e-mail prevedono l'uso di S/MIME, una tecnica che permette di spedire firma e certificato come allegati MIME.

Se si usa PGP è possibile utilizzare S/MIME oppure la trasmissione di testo armored (lett. corazzato, blindato). Ancora oggi sono pochi i client di posta che supportano PGP. Il testo armored semplifica l'utilizzo di software non integrato nel client di posta (tipicamente GPG).

Bisogna notare che in ogni caso è possibile nascondere il contenuto del messaggio, ma non il mittente, i destinatari e il fatto che un messaggio e-mail con un certo soggetto venga spedito in un certo momento dal primo ai secondi.

Certificati di un server

• Alice richiede una pagina sicura sul server di Bob (il protocollo è https, non http).
• Il server presenta ad Alice uno o più certificati. Se tra questi ce n'è almeno uno che è stato emesso da una CA di cui Alice si fida, il browser accetta il certificato. Altrimenti notifica ad Alice che il certificato è stato emesso da una CA sconosciuta e può chiedere ad Alice se accettare o meno il certificato.
• Il server talvolta richiede ad Alice di identificarsi a sua volta tramite un certificato. Correntemente questa pratica non viene seguita e, se è necessaria un'autenticazione, il server chiede ad Alice un nome e una password.
• Il client si inventa lì per lì una chiave simmetrica, la critta usando il certificato del server e gliela trasmette. Per tutta la sessione, i dati tra client e server vengono crittati utilizzando questa chiave simmetrica. Solo conoscendo la chiave privata del server si può ricostruire la chiave simmetrica e quindi decifrare il contenuto della sessione. La chiave del server viene custodita in un file sul server stesso, adoperando ogni possibile precauzione perché non venga copiata in giro.

L'utilizzo di https (la 's' sta per secure) viene spesso chiamato SSL (secure socket layer). Si noti che i dati trasmessi, se vengono salvati, vengono salvati in chiaro o, se è il caso, re-crittati con un'altra chiave. Il collegamento web sicuro garantisce soltanto la riservatezza durante la trasmissione.

Esistono versioni sicure dei protocolli per caricare (SMTP) e scaricare (POP3, IMAP4) la posta elettronica. Questi permettono di occultare tutti i dati di un messaggio durante la trasmissione via Internet, ma non aggiungono alcuna informazione sull'autenticità del mittente. Il testo, il mittente e il destinatario sono in chiaro sul server di posta.

Esistono anche altri protocolli che utilizzano la crittografia. Per esempio, SET (secure electronic transaction) è un protocollo appositamente studiato per i pagamenti. Si tratta di una transazione a tre, Alice, Bob e un'agenzia di credito. Quest'ultima conferma il pagamento a Bob senza lasciargli conoscere il numero di carta di credito di Alice.

Supponiamo che qualcuno voglia carpire un dato segreto trasmesso da Alice al server di Bob, per esempio una password o un numero di carta di credito. Alice arriva al server di Bob seguendo un link, oppure scrive manualmente l'indirizzo del server di Bob nella finestrella apposita (in alto) del browser. La richiesta viene trasmessa dal computer di Alice, attraverso un eventuale server proxy, attraverso un numero di reti (in media una decina) fino al server di Bob. Di solito, lo stesso percorso viene seguito, all'avanti e all'indietro, una o più volte.

Alice potrebbe accedere a Internet da un computer connesso alla rete di un campus universitario, oppure dall'interno di una rete aziendale, oppure dal modem di casa sua. Nei primi due casi, è probabile che diversi computer connessi alla stesa rete abbiano la possibilità di vedere ogni singolo byte di dati che venga inviato o ricevuto dal computer di Alice. In seguito, quando i dati rimbalzano da un provider a una compagnia telefonica, una moltitudine di impiegati e di addetti ha la possibilità di sbirciare i dati di Alice. Lungo i cablaggi urbani e sui backbone nazionali è possibile che degli intrusi si introducano sulle linee. Nel caso di collegamenti internazionali o intercontinentali, i dati di Alice vengono probabilmente analizzati da Echelon e da una quantità di altri enti o individui.

Ovviamente, se Alice usa il protocollo http, non crittato, non c'è speranza di riservatezza. Se Alice ha ottenuto una connessione sicura col server di Bob, allora la speranza c'è. Ma quanto è sicura una connessione sicura?

L'attacco diretto, mediante criptoanalisi, risulta più o meno praticabile a seconda della lunghezza delle chiavi usate. Una chiave RSA di 640 bit è stata falsata nel 2005, vincendo i 10'000$ in palio. Si noti che 640 bit rappresentano un numero di 193 cifre decimali! Una volta si chiamavano astronomici i numeri molto grandi, ma oggi dovremmo aggiornare il vocabolario perché questi ordini di grandezza non hanno molto senso in astronomia. Le prossime tecnologie promettono tempi più rapidi per ricavare la chiave privata del server di Bob dalla corrispondente chiave pubblica. Ogni bit aggiunto alla lunghezza della chiave raddoppia il tempo teoricamente necessario. Con chiavi di 768 bit o più lunghe, i tempi necessari alla falsificazione assicurano una riservatezza adeguata, per il momento. Discorso analogo vale per la chiave simmetrica generata ad hoc all'inizio della connessione sicura: 52 bit sono scarsi mentre 128 bit vengono considerati buoni.

L'attacco dell'uomo nel mezzo può compromettere la sicurezza anche in presenza di chiavi forti. L'hacker deve riuscire a impersonare il server di Bob in modo da ottenere i dati di Alice direttamente. Un problema da superare è quello del certificato: sul certificato del server di Bob c'è scritto il nome del server, per esempio www.bob.com e c'è scritto il nome Bob? Il server dell'hacker potrebbe avere un certificato perfettamente legale ma intestato a una persona diversa da Bob. È necessario che Alice controlli manualmente il certificato. Alice dovrebbe controllare anche la richiesta scritta nella finestrella (in alto) del browser e assicurarsi che questa sia davvero la finestrella del browser piuttosto che una finestrella finta messa ad arte su una pagina HTML.

L'attacco al name server può permettere a un hacker di convincere il computer di Alice di essere connesso col server di Bob mentre in realtà questo è connesso con un'altra macchina. Questo può permettere di attuare l'attacco dell'uomo nel mezzo in modo mirato. Il name server è infatti la macchina che risolve i nomi come www.bob.com in indirizzi ip con cui stabilire la connessione. I name server richiedono gli indirizzi ad altri name server, a catena. Uno di questi può essere abbindolato con un indirizzo falso dall'hacker che sta impersonando il name server successivo lungo la catena. In questo caso la finestrella del browser è vera e sul certificato c'è davvero scritto www.bob.com. Non è semplice portare un attacco di questo tipo. Il certificato di una CA in cui si ha fiducia è il modo più facile per sincerarsi di non essere vittima di un tale attacco, ma sarebbe necessario aver verificato il certificato della CA al di fuori della rete.

L'attacco al computer di Alice è il modo più semplice e diretto di ottenere i dati segreti. Di solito viene inviato del software eseguibile tramite e-mail, oppure facendolo scaricare da appositi siti web. Questo software installa silenziosamente un virus mentre visualizza un video clip o altro materiale innocuo. Oppure un virus viene installato direttamente sull'hard disk di Alice, se l'hacker può accedere a directory condivise, replica di file e simili. Una volta compromesso il computer di Alice, l'hacker può controllare cosa viene visualizzato sul video, quali tasti vengono pigiati, quali file si trovano su disco (compresi eventuali certificati) e modificarli.

L'attacco al server di Bob può essere effettuato con gli stessi mezzi. Compromettere un server è un buon punto per un hacker, in quanto gli permetterebbe di effettuare nuovi attacchi da lì, senza esporsi.

Certificati falsi possono essere generati grazie a vulnerabilità degli algoritmi. MD5 si presta a questo genere di attacco: è possibile produrre due certificati con chiavi pubbliche diverse e intestati a persone diverse che però collidono, nel senso che le parti dei certificati che la CA deve firmare hanno lo stesso digest MD5. Si veda Colliding X.509 Certificates for Different Identities.

Il certificato che segue è stato prodotto in TANA per certificare i server web locali. Autocertificazione. È possibile effetuare un paio di verifiche,

1. cercare "TANA.IT" sul data base della Registration Authority Italiana per verificare il nome dell'organizzazione che gestisce questo dominio e l'indirizzo dei name server autoritativi;
2. cercare l'indirizzo IP ottenuto al punto 1, o l'indirizzo I.P. di un altro server certificato da TANA, sul data base del RIPE per verificare chi è responsabile.

Chi è in una situazione davvero paranoide, dopo aver installato il certificato, richieda l'invio del testo del certificato via fax, telefono o altro. Certificare un server web serve a permettere la trasmissione riservata dei dati, le verifiche assicurano che il server sia realmente il server che dice di essere.

Per installare in un browser il certificato di TANA-CA è sufficiente fare aprire al browser il file indicato dal link qui sotto e seguire le indicazioni che seguono. Il certificato è disponibile in un paio di formati diversi, se un browser non accetta il primo è probabile che accetti il secondo. Dopo aver installato il certificato, il browser potrà verificare automaticamente la validità della connessione sicura con i server TANA. Questo presenta il vantaggio di non dover ripetere ogni volta la conferma. La chiave privata di TANA-CA è custodita su un computer non accessibile da Internet.

installa il certificato di TANA-CA (formato PEM)

installa il certificato di TANA-CA (formato DER)

Per installare il certificato su MacOS X è necessaria la password di amministratore del computer. Segui questi passi:

1. Scarica il certificato in formato DER e salvalo sul desktop.
2. Cambia l'estensione del nome da der.ca-cert in cer.
3. Apri l'accesso al portachiavi, e importa il certificato in X509Anchors nel portachiavi di sistema. Può essere necessario uscire dal portachiavi e da Safari prima che il nuovo certificato sia funzionale.

Il certificato inviato per fax o per posta normale a chi lo richieda consiste nel fingerprint (menzionato sopra) e nei dati che seguono: