Il commento di oggi

Aggiornato il 17/04/2001

Il "commento di oggi" è uno spazio in cui di volta in volta metto dei commenti su aspetti tecnici o avvenimenti interessanti nel campo della sicurezza. Inutile dire che si tratta di opinioni derivate dalla mia esperienza personale. Siete liberi di mandare risposte e critiche, che eventualmente pubblicherò. Per quanto si chiami Commento di oggi, l'aggiornamento è tutt'altro che quotidiano.

Commenti precedenti

Autenticazione tra mito e realtà

Negli ultimi tempi si parla spesso di strumenti per l'autenticazione e di pki come se fossero la soluzione definitiva a tutti problemi di sicurezza. Naturalmente non è così.

Innanzitutto dobbiamo distinguere tre aspetti che spesso vengono accomunati sotto il termine autenticazione. Il primo è l'identificazione, ovvero il processo attraverso il quale un'entità fornisce la propria identità. Il secondo è l'autenticazione vera e propria, ovvero il processo attraverso il quale l'identità fornita viene verificata. La maggior parte della nostra esistenza è basata sulla sola identificazione; solo in poche occasioni ricorriamo all'autenticazione. Ad esempio, all'inizio di una telefonata noi dichiariamo la nostra identità; in alcuni casi, quando l'interlocutore ci conosce, effettua un'autenticazione basata sul riconoscimento della voce. Se l'interlocutore non ci conosce tuttavia, in molti casi è sufficiente che noi dichiariamo la nostra identità, senza che ce ne sia richiesta una prova. In effetti, la prova della nostra identità, generalmente ottenuta attraverso l'esibizione di un documento, è un evento estremamente raro. La maggior parte di noi non ha mai o quasi mai chiesto un documento di identità; al massimo abbiamo fatto l'ipotesi che il documento sia stato precedentemente già richiesto da qualcun altro (il che ci può ricordare il funzionamento delle r-utility). Su Internet, oltre a numerosi servizi anonimi, ci sono molte attività che sono svolte in base alla sola identificazione: la maggior parte della posta elettronica, i servizi offerti tramite sola registrazione, come ad esempio accesso ad Internet gratuiti, ecc. ci sono tuttavia situazioni in cui si vuole una prova dell'identità fornita. Questa prova è ottenuta sempre fornendo alla controparte un'informazione che dimostri la nostra identità. Questa non dev'essere confusa con l'informazione, eventualmente segreta, che noi dobbiamo possedere per poter effettuare questa dimostrazione. Nel caso delle password ripetibili ad esempio, le due informazioni coincidono; nel caso delle one time password, l'informazione segreta è il seme per la generazione delle password, mentre l'informazione che viene fornita è la one time password.

Il terzo aspetto, sul quale l'attenzione si è spostata solo di recente, è la non repudiation. Mentre l'autenticazione riguarda chi deve autenticare e chi deve essere autenticato, la non repudiation riguarda sostanzialmente la possibilità di dimostrare l'autenticazione nei confronti di una terza parte. La cosa si chiarisce bene con un esempio, e cioè una possibile contestazione per un servizio Bancomat. Immaginiamo che un giorno ci arrivi un estratto conto nel quale è riportato un prelievo Bancomat che noi riteniamo di non aver effettuato. La banca può essere assolutamente certa che noi lo abbiamo effettuato, in quanto si fida del meccanismo di autenticazione basato su tessera e pin, e può avere le registrazioni dell'operazione allo sportello. In caso di contestazione però, può trovarsi a dover dimostrare i fatti ad una terza parte, ad esempio ad un giudice. Dato che l'unica prova sono le registrazioni in possesso della Banca, è evidente che la banca può aver manipolato queste prove a proprio favore, e quindi anche se l'autenticazione è affidabile l'utente, almeno da un punto di vista tecnico, è in grado di ripudiare l'operazione effettuata. Le cose vanno diversamente se l'autenticazione dell'utente è avvenuta attraverso un meccanismo a chiave pubblica: se l'operazione è stata in qualche modo firmata dall'utente, la banca non è in grado di manipolare le registrazioni e quindi l'utente non in grado di ripudiare l'operazione effettuata. Il tutto funziona solo se l'utente è l'unico possessore della chiave privata utilizzata. È chiaro che un simile effetto si perde se la chiave privata è stata fornita all'utente da una qualsiasi entità, compresa la banca. Per ottenere la non repudiation è necessario in generale che l'informazione segreta sia in possesso solo dell'entità che dev'essere autenticata.

Anche in caso di sola autenticazione, è necessario comunque che l'informazione sia protetta da possibili abusi; le password ripetibili ad esempio, pur non essendo un meccanismo adatto per ottenere la non repudiation, devono essere in possesso solo di chi si autentica e di chi effettua l'autenticazione. Tradizionalmente i meccanismi di autenticazione sono divisi in tre categorie, in base al modo in cui l'utente fornisce al sistema di autenticazione l'informazione necessaria. Le tre categorie sono:

qualcosa che si sa: ad esempio le password ripetibili, e comunque ogni tipo di informazione che l'utente apprenda e quindi i sia anche in grado di comunicare al sistema di autenticazione o ad altri;

qualcosa che si ha: ad esempio una smart card o una tessera Bancomat;

qualcosa che si è: questo comprende le varie misure biometriche.

Questa distinzione riguarda più il modo in cui l'utente conserva e fornisce l'informazione che l'informazione effettivamente utilizzata per l'autenticazione. A questo punto bisogna dividere il sistema di autenticazione in tre componenti fondamentali: la parte che riceve l'informazione dall'utente, quella che verifica l'informazione fornita ed eventualmente una terza componente che permette alle prime due di comunicare fra loro. Molti dei problemi legati all'autenticazione derivano dal fatto che questa terza componente non sia sotto controllo di chi effettua all'autenticazione. Ad esempio, lo sniffing delle password viene fatto proprio mentre queste transitano fra l'utente e chi effettua all'autenticazione. Molti meccanismi di autenticazione funzionano correttamente anche quando la prima componente, ovvero quella che riceve l'informazione dall'utente, è sotto il controllo dell'utente stesso. Questo perché la componente che effetto all'autenticazione non fa nessuna ipotesi su come l'informazione le viene fornita.

Consideriamo però adesso l'autenticazione basata su misure biometriche. La misura biometrica, ad esempio un'impronta digitale, è sempre la stessa per tutta la vita dell'utente; essa viene letta da un apposito lettore, e viene fornita al sistema di verifica. Quella che viene fornito, quindi, è analogo a una password ripetibile. Perché allora i sistemi biometrici sono considerati più sicuri? Tutta la sicurezza del meccanismo sta nel lettore: ci si aspetta che solo l'utente reale sia in grado di fornire al lettore le giuste informazioni. Una volta acquisita, l'informazione ha, in effetti, tutte le caratteristiche di una password: è ripetibile ed è conservata nel meccanismo di autenticazione per la verifica. La prima conseguenza di questo meccanismo è che una misura biometrica non può essere utilizzata per la non repudiation, dato che il server spesso ne conserva una copia ed è in grado di falsificare le registrazioni. Consideriamo però adesso il caso in cui il sistema di lettura è sotto il controllo dell'utente: in questo caso l'utente sarà in grado di fornire l'informazione che vuole, aggirando il lettore stesso e annullando quella che, di fatto, è l'unica protezione di un sistema di autenticazione biometrico. Di fatto, un sistema di autenticazione biometrico funziona solo se tutte e tre le componenti sono sotto il controllo di chi effettua all'autenticazione. Questo genere di meccanismi funziona bene per controllare gli accessi ad un edificio o ad un locale. L'idea invece di utilizzare questi meccanismi per autenticare utenti in rete semplicemente non ha senso: non siamo infatti in grado di controllare da dove realmente provenga l'informazione che viene fornita per l'autenticazione. Si potrebbe obiettare che la connessione fra il lettore e il sistema di autenticazione può essere protetta ad esempio con ssl, ma a parte il fatto che si utilizzerebbe in più il meccanismo di autenticazione di ssl, questo non impedirebbe la manipolazione dell'informazione presso il sistema client: niente impedisce all'utente di fornire attraverso la connessione ssl dei dati non veritieri.

Questa considerazione espone altri due problemi. Il primo è quello dell'autenticazione iniziale: la maggior parte dei meccanismi di autenticazione in rete prevede una fase iniziale di autenticazione e poi l'ipotesi che tutto il traffico successivo continui a provenire dalla fonte autenticata. Questa ipotesi, particolarmente su Internet, non è assolutamente valida: in un traffico a pacchetti di singoli pacchetti possono essere sostituiti durante la sessione dopo che è avvenuta l'autenticazione. Per evitare questo problema è di fatto necessario autenticare ogni singolo pacchetto oppure utilizzare un meccanismo di autenticazione dell'intera sessione effettuato a livello più alto; è anche a questo scopo che sono stati concepiti ssl e ipsec.

Il secondo problema, assai più difficile da risolvere, riguarda il fatto che quasi sempre quello che viene autenticato non è realmente l'utente bensì il sistema che questi usa per la connessione. Ad esempio, l'utente non è in grado di generale traffico ssl, ma sarà il suo sistema a generarlo per lui; non è neanche in grado di presentare dei dati da firmare a una smart card: il sistema gli presenta dei dati sullo schermo e poi passa i dati (gli stessi?) alla smart card per la firma. Tutto questo si basa quindi sull'ipotesi che il sistema utilizzato dall'utente sia affidabile, il che, come dimostrano strumenti come back orifice o la diffusione di virus e worm come Melissa e "I love You", è tutt'altro che scontato. In effetti, nel momento in cui i sistemi dell'utente non è affidabile, i sistemi di autenticazione biometrica, le smart card, la firma elettronica e tutti gli altri meccanismi di autenticazione perdono uno dei presupposti fondamentali. Si tratta quindi di meccanismi in generale i migliori delle password ripetibili, ma la loro affidabilità, come quella di qualsiasi meccanismo, deve essere attentamente valutata caso per caso. Soprattutto, come qualsiasi meccanismo di sicurezza, non sono assolutamente una "garanzia di sicurezza" come ogni tanto afferma qualcuno.

La domanda successiva è: perché si effettua all'autenticazione? I motivi sono essenzialmente due; il primo è la necessità di associare a un'entità i giusti diritti di accesso alle risorse. Ad esempio, utenti diversi potranno accedere a file diversi; l'autenticazione è il requisito che permette ai meccanismi di controllo degli accessi di associare il profilo adatto ai diversi utenti. L'altro motivo importante per il quale si effettua l'autenticazione è l'accounting, ovvero la possibilità di associare gli eventi agli utenti che li hanno prodotti. Ad esempio, quando viene modificato un file, noi vogliamo sapere quale utente, fra i tanti che ne hanno il diritto, ha effettivamente effettuato la modifica.

È importante notare che se i meccanismi di controllo degli accessi falliscono, il fatto che l'utente sia stato autenticato perde di efficacia. È un dato di fatto che molti dei bug che causano e hanno causato problemi di sicurezza fossero proprio fallimenti nei meccanismi di controllo degli accessi, e questo ci da un'idea di quanto siano insufficienti i meccanismi di autenticazione per la protezione delle risorse. Questo fatto può essere facilmente verificato esaminando gli archivi di bugtraq; si tratta di un esercizio di consiglio sempre dovendo valutare l'efficacia di un nuovo strumento o meccanismo: "quanti dei problemi segnalati in questa lista verrebbero risolti dal nuovo strumento? ". Naturalmente i problemi di sicurezza non possono essere ridotti a quello che compare su bugtraq, ma certo si tratta di problemi che in qualche modo vanno risolti.

Per quanto riguarda l'accounting, ci si può chiedere che significato ha esattamente dal punto di vista della sicurezza delle risorse. Pur non negando l'utilità di questa funzione, e tenendo comunque conto del fatto che fallimenti nei meccanismi di controllo degli accessi possono falsare anche le informazioni di accounting, è necessario valutare i quali contesti e per quali scopi queste informazioni siano realmente utili. Un altro dei miti frequenti dell'autenticazione, infatti, è che siccome utente autenticato è riconosciuto e gli possono essere imputate le sue azioni, l'utente non violerà la politica di sicurezza, e se lo farà potrà essere punito. Un primo caso importante in cui quest'ipotesi spesso non vale è quello dei servizi pubblici su Internet. A prescindere dal fatto che sono pochi i servizi pubblici che ha senso autenticare, e che già ha solo il fatto di richiedere una registrazione è sufficiente per allontanare molti utenti, ci si può chiedere che cosa si può fare nel momento in cui un utente autenticato commette una violazione. Individuare un aggressore ha essenzialmente due scopi: impedirgli ulteriori accessi, quando possibile, ed eventualmente procedere per vie legali. La prima azione ha senso, ma non rimedierà all'eventuale danno subito; la seconda spesso è anche di difficile realizzazione, tenendo conto delle leggi del nostro Stato, di quelle dello Stato in cui si trova l'aggressore, e delle possibilità che abbiamo di dimostrare a un giudice la validità del nostro meccanismo di autenticazione. L'installazione di back orifice sulla propria macchina è probabilmente un'ottima garanzia contro quasi qualsiasi accusa. In ogni caso, sia nei confronti di attacchi dall'esterno che di attacchi dall'interno, il fatto di riconoscere l'aggressore spesso non sarà sufficiente a riparare ai danni. Possiamo immaginarci come caso estremo una banca che permetta ad ogni impiegato di entrare nel caveau, registrandone le identità e azioni: chi volesse rubare difficilmente si preoccuperebbe di essere identificato, una volta trasferito se stesso e il denaro in un posto sicuro.

Per concludere, i meccanismi di autenticazione sono sicuramente una componente importante della sicurezza di un sistema, ma prima di spendere cifre considerevoli i meccanismi costosi e complessi, forse è meglio verificare se non vi sono anelli deboli della catena sui quali è più opportuno intervenire.