Tecnologie abilitanti

Di seguito vengono riportate le principale tecnologie che possono entrare in gioco in un processo di autenticazione, ordinate in relazione al grado di complessità e in modo da sottolinearne i vantaggi e gli eventuali aspetti lasciati scoperti.

FIRMA DIGITALE

Una definizione di firma digitale è fornita dall’articolo 1 del Decreto Del Presidente Della Repubblica del 28 dicembre 2000, n. 445:

“Una firma digitale è il risultato della procedura informatica (validazione) basata su un sistema di chiavi asimmetriche a coppia, una pubblica e una privata, che consente al sottoscrittore tramite la chiave privata e al destinatario tramite la chiave pubblica, rispettivamente, di rendere manifesta e di verificare la provenienza e l'integrità di un documento informatico o di un insieme di documenti

La firma digitale di un documento informatico permette dunque al destinatario di verificare l’identità del mittente, fa si che il mittente non possa ripudiare in un secondo tempo il contenuto del messaggio e non permette al destinatario di falsificare i messaggi del mittente. Nella prima fase del processo di firma digitale, al documento in chiaro viene applicata una funzione di Hash che produce in uscita una stinga binaria di lunghezza costante e ridotta, detta impronta digitale. Questa costituisce una versione sintetica del documento informatico, tipicamente di 128 o 160 bit. Successivamente viene generata una coppia di chiavi: una segreta per l’apposizione della firma, ed una pubblica destinata alla verifica. La generazione della firma consiste nella cifratura con la chiave privata dell’impronta digitale generata in precedenza. Il message digest così codificato viene aggiunto in coda al documento. L’autenticità della firma viene verificata dal destinatario decifrando il digest tramite la chiave pubblica del mittente. A questo punto viene calcolato il message digest del corpo del testo ricevuto e viene confrontato con quello originario, precedentemente decodificato: se i due message digest coincidono si ha la garanzia di integrità (ovvero il corpo del documento non è stato modificato durante la trasmissione).

CERTIFICATO DIGITALE

La firma digitale tuttavia non garantisce la vera identità del titolare della chiave privata. I certificati digitali sono dei file, con una validità temporale limitata, usati per garantire l’identità di un soggetto, sia esso un server o una persona; servono per stabilire con esattezza l’identità delle parti in una comunicazione. Questo è possibile in quanto contengono una copia della chiave pubblica di tale entità “controfirmata” digitalmente da una terza parte garante che in genere è un ente indipendente pubblico o privato chiamato Certification Authority (CA). Una CA rilascia i certificati a chi ne fa richiesta dopo averne attestato l’identità. I certificati digitali sono emessi tipicamente seguendo lo standard X.509, che prevede varie informazioni:

 la chiave pubblica;

 un nome, che può riferirsi ad una persona, computer o organizzazione;

 un periodo di validità;

 la URL del revocation center;

 la firma digitale del certificato, prodotta con la chiave privata della CA o, nel caso di autocertificazioni, con la chiave privata del soggetto a cui si riferisce il certificato.

Una volta che il certificato è scaduto, l’ente garante ne emette uno nuovo e inserisce quello scaduto nella CRL (Certificate Revocation List). Ricapitolando, un utente A per firmare e decifrare i messaggi scambiati con un utente B ha bisogno:

 della propria chiave privata per firmare i messaggi in uscita e decifrare quelli in ingresso;

 del certificato dell’utente B per controllare la firma dei messaggi in ingresso o cifrare quelli in uscita;

SMART CARD

Con il termine Smart Card, o carte a microprocessore, si intende una classe di dispositivi delle dimensioni di una carta di credito che presentano varie funzionalità e si differenziano dalle più familiari carte magnetiche a banda utilizzate come standard ad esempio per i bancomat. Permettono di conservare in modo sicuro le cosiddette informazioni “riservate”, come la propria identità digitale e la chiave privata rilasciata dalla CA. Una Smart Card è essenzialmente un computer in miniatura, annegato in materiale plastico in forma di una carta di credito, con una memoria e una capacità di elaborazione limitata. Il chip di silicio, solitamente di forma quadrata e di colore oro, costituisce il centro del sistema. In esso sono registrate i servizi fruibili dall’utente ed il software necessario per l’interscambio e l’aggiornamento dei dati tra card e terminale. La struttura portante si compone dei seguenti elementi:

 CPU, generalmente a 8 bit;

 ROM, contenente il sistema operativo;

 RAM, per la memorizzazione temporanea dei dati;

 EEPROM, contenente i dati relativi ad esempio a password e chiavi;

 ISO, porta di interscambio fisico delle informazioni.

La circuiteria trae alimentazione da un lettore di Smart Card nel momento in cui la scheda vi viene inserita. La comunicazione dei dati tra una Smart Card e un'applicazione in esecuzione su un computer avviene tramite un’interfaccia seriale half-duplex gestita dal lettore di Smart Card e dai driver del dispositivo associato. Il chip permette di eseguire internamente alcune operazioni e di memorizzare tutte le informazioni all’interno della memoria non cancellabile, conferendo quindi un alto grado di sicurezza. La sicurezza della Smart Card dipende anche da una password denominata PIN, che deve essere a conoscenza solo del legittimo proprietario. Questa rappresenta una misura protettiva in caso di smarrimento o falsificazione. La lunghezza del PIN varia tra 4 e 8 cifre, rappresentando un compromesso tra protezione da attacchi brute-force e facilità di memorizzazione per l’utente.

PIC

OTP TOKEN

Una delle tecnologie di Strong Authentication che ha conosciuto un’ampia diffusione negli ultimi anni è rappresentata sicuramente dalla One Time Password (OTP), ovvero un codice univoco, dinamico e valido per una sola transazione o sessione di login. Una volta verificate le credenziali, il server scarta la password utilizzata rendendone impossibile il riutilizzo sia da parte dell’utente legittimo sia da parte di un hacker. La caratteristica più importante che viene associata alle OTP è che, a differenza delle password statiche, sono intrinsecamente resistenti all’attacco replay, dato che le informazioni che vengono trasmesse sulla rete non sono sufficienti per effettuare l’accesso in un secondo momento. Infatti, un potenziale intruso che riesce ad intercettare una OTP che è stata già utilizzata per accedere ad un servizio o per eseguire una transazione non potrà abusarne, poiché non sarà più valida. Inoltre, l’introduzione di un limite di validità temporale, aumenta l’efficacia della protezione contro attacchi di tipo esaustivo. L’aspetto negativo di questo tipo di approccio è che, per poter essere implementato, richiede una tecnologia aggiuntiva per consentire all’utente il calcolo delle password. Gli algoritmi di generazione delle OTP tipicamente utilizzano numeri casuali o pseudocasuali. Ciò è necessario perché altrimenti sarebbe facile prevedere le OTP future osservando quelle precedente. I vari approcci per la generazione di OTP sono elencati di seguito:

 Sincronizzazione temporale tra il server di autenticazione ed il client;

 Utilizzo di un algoritmo matematico per generare una nuova password sulla base della precedente;

 Utilizzo di un algoritmo matematico in cui la nuova password si basa su una sfida (ad esempio un numero casuale scelto dal server di autenticazione o dai dettagli della transazione).

Gli algoritmi basati sulla sincronizzazione sono quelli utilizzati dalle banche soprattutto per il fatto che, a differenza dei metodi matematici, non richiedono un dialogo diretto tra il client ed il server erogatore del servizio per la generazione della chiave. Tutte queste modalità si basano su tecniche crittografiche di hashing a chiave segreta: il client ed il server di autenticazione hanno una chiave segreta condivisa, che viene utilizzata per criptare alcuni dati utili a generare l’OTP. Usando tale funzione di Hash, indicata con f, per elaborare un certo dato x, non è possibile risalire al valore di x a partire da f(x); se f(y) fosse uguale a f(y) allora y potrebbe essere uguale a x, altrimenti x e y sarebbero necessariamente differenti. Questa verifica ha senso poiché è molto improbabile che presi due valori x e y a caso, la funzione Hash fornisca due risultati uguali.

Figura 21 - Schema logico di un processo di autenticazione.

Ci sono diversi modi per rendere note all'utente le OTP da usare. Alcuni sistemi utilizzano speciali token di sicurezza elettronici che l'utente porta con se e che generano le OTP mostrandole attraverso un piccolo display. Altri sistemi invece sono costituiti da software che possono girare ad esempio sul telefono cellulare dell'utente. Un’altra alternativa prevede l’uso di sistemi che generano le OTP lato server e le inviano all'utente tramite un canale out-of-band, come quello della messaggistica SMS. Infine, in alcuni sistemi le OTP sono stampate su un documento cartaceo, che l'utente è tenuto a portare con sé e ne usa una ogni volta che deve effettuare un’autenticazione. L’elenco di password costituisce il token, ma deve essere custodito con sicurezza.

Figura 22 - Esempio di generatore di token.

Molte tecnologie OTP sono brevettate, e ciò rende la standardizzazione in questo settore più difficile in quanto ogni azienda cerca di spingere la propria tecnologia. Alcuni standard tuttavia esistono e sono RFC1760 (S/KEY), RFC2289 (OTP), RFC4226 (HOTP) e RFC6238 (TOTP).

SISTEMI DI RICONOSCIMENTO BIOMETRICO

Con sistemi di riconoscimento biometrico si intende una categoria di dispositivi avanzati che permettono il riconoscimento automatico della persona non sulla base di qualcosa che possiede o che ricorda, ma sulla base di alcune sue caratteristiche fisiche. Molte soluzioni commerciali si basano sul riconoscimento di impronte digitali, della fisionomia del viso, della scansione retinica,

del riconoscimento vocale etc. Questi sistemi sono nati per garantire, almeno su base teorica, il massimo livello di sicurezza nell'autenticazione individuale a partire da caratteristiche che contraddistinguono la persona fisica. Un modo per validare il corretto funzionamento di un sistema biometrico consiste nel misurare lo scostamento tra la percentuale delle configurazioni erroneamente uguagliate ad una valida biometria dell’utente, e la percentuale di utenti validi rifiutati in modo errato. Purtroppo generalmente questo range è ancora molto ampio e pertanto approcci di questo tipo non garantiscono una sicurezza assoluta. Allo stato attuale i sistemi che vengono implementati sono spesso associati ad ulteriori sistemi di controllo (smart card e/o username e password), e sono comunque da scartare in caso di autenticazione remota. Inoltre implicano un costo notevole per la loro implementazione e manutenzione, richiedono un periodo di prova e collaudo, registrazione della biometria degli utenti, nonché periodi di istruzione e formazione del personale. Un esempio di un semplice sistema commerciale che sfrutta il riconoscimento delle impronte digitali è costituito dalla pen-drive RUF2-FS, che integra questo criterio di identificazione per garantire la sicurezza dei dati presenti all'interno della penna di memoria. Il costo minimo di questo oggetto si aggira intorno agli 80€ [Fonte: TechTop.it].

Figura 23 - Pen-Drive RUF2-FS per il riconoscimento di impronte digitali.

3.2 AUTORIZZAZIONE

Una volta verificata l’identità di un soggetto, è necessario determinare a quali parti delle applicazioni questo può accedere e che tipo di azioni può intraprendere all’interno della stessa. Si parla in questo caso di Autorizzazione e consente ad un utente di accedere solo ai dati che lo riguardano e non a quelli degli altri utenti. Tipicamente l’autorizzazione viene implementata fornendo alla sessione dell’utente un token di accesso che lo identifica univocamente. L’applicazione quindi determina se concedere o negare l’accesso a certe sezioni, confrontando tale token con una lista di controllo degli accessi. Se vi è un riscontro tra l’identificatore e la configurazione dei permessi l’accesso viene garantito, altrimenti viene negato. Al logout o timeout della sessione, il token viene cancellato o invalidato. Spesso l’identificatore usato per distinguere le sessioni, è comunemente chiamato Session ID.

3.3 TRASPORTO SICURO SSL

Nelle sezioni precedenti sono stati descritti brevemente i principi alla base della crittografia e le possibili strategie esistenti per la verifica delle identità dei soggetti coinvolti in una determinata operazione. Oltre al processo di autenticazione, un’altra necessità fondamentale è la riservatezza dei dati che vengono trasmessi attraverso la rete; con questo ci si riferisce agli accorgimenti che impediscono a terzi la lettura dei dati durante la loro trasmissione tra il dispositivo in uso ed i server con i quali l’applicazione client interagisce. Il livello di protezione da implementare è dettato ovviamente dalla sensibilità dei dati che stiamo trasferendo. Il gold standard per la protezione dei dati in transito sulla rete Internet è il Secure Sockets Layer (SSL). Si tratta di un protocollo di comunicazione aperto e non proprietario, originariamente sviluppato da Netscape Development Corporation ed è stato accettato universalmente come protocollo per l'autenticazione e la comunicazione criptata tra client e server. Permette quindi di comunicare in modo da prevenire le intrusioni, le manomissioni e le falsificazioni dei messaggi, garantendo la riservatezza dei dati in transito sulla rete. La versione 3.0 del protocollo rilasciata nel novembre 1996, è un'evoluzione della precedente versione del 1994, la SSL v2.0. Tale evoluzione introduce un livello di sicurezza superiore rispetto alla precedente grazie ad una maggiore attenzione nella fase di autenticazione tra client e server. Il futuro di SSL è rappresentato dal protocollo TLS v1 (SSL v3.1) sottoposto a standardizzazione nel novembre 1998. Il protocollo SSL definisce due ruoli diversi per le parti comunicanti, alle quali competono compiti diversi: un sistema è sempre costituito da un client, mentre l’altro è un server. Il client è il sistema che avvia le comunicazioni sicure, mentre il server risponde alla richiesta del client. Il protocollo SSL garantisce la sicurezza del collegamento mediante tre funzionalità fondamentali:

 Sicurezza del Collegamento: Per assicurare un collegamento sicuro tra due utenti coinvolti in una comunicazione, i dati vengono protetti utilizzando algoritmi di crittografia a chiave simmetrica (ad esempio DES);

 Autenticazione: L'autenticazione dell'identità nelle connessioni può essere eseguita usando la crittografia a chiave pubblica (per esempio RSA). In questo modo i client sono sicuri di comunicare con il server corretto, prevenendo eventuali interposizioni. Inoltre è prevista la certificazione sia del server che del client;

 Affidabilità: Il livello di trasporto include un controllo sull'integrità del messaggio basato su un apposito MAC (Message Authentication Code) che utilizza funzioni hash sicure (per esempio SHA o MD5). In tal modo si verifica che i dati spediti tra client e server non siano stati alterati durante la trasmissione.

Il protocollo SSL usa una combinazione di chiavi pubbliche e chiavi simmetriche. La cifratura a chiave simmetrica è molto più veloce della cifratura a chiave pubblica, anche se quest'ultima provvede ad una tecnica di autenticazione migliore. Gli algoritmi di cifratura che possono essere utilizzati, alcuni dei quali sono stati descritti nei precedenti paragrafi, sono:

 DES: Data Encryption Standard;

 DSA: Digital Signature Algorithm;

 KEA: Key Exchange Algorithm;

 MD5: Message Digest algorithm sviluppato da Rivest;

 RSA: algoritmo a chiave pubblica (Rivest, Shamir, Adleman);

 RSA key exchange: per lo scambio delle chiavi durante la negoziazione SSL basato sull'algoritmo RSA;

 SHA-1: Secure Hash Algorithm;

 3DES: DES applicata 3 volte.

Il trasporto e l’instradamento dei dati sulla rete è governato dal protocollo TCP/IP. SSL si colloca tra lo stato di trasporto (protocollo TCP) e lo strato delle applicazioni (protocollo HTTP), per cui permette, ad esempio, il trasporto di pacchetti contenenti i dati criptati di una transazione HTTP tra un HTTP-Server e un HTTP-Client.

Facendo riferimento alla figura, si nota come il protocollo SSL risulti essere organizzato in sotto- protocolli di livello inferiore adibiti a creare i messaggi: ChangeCipherSpec, Alert, Handshake e Application (HTTP ad esempio). Il Record Layer accetta tutti questi messaggi, definisce il formato utilizzato per trasmettere i dati e li passa ad un protocollo di trasporto come il TCP (Transmission Control Protocol). Il protocollo di Handshake è il principale responsabile della creazione di una sessione SSL. In particolare il risultato di tale fase è l'avvio di una nuova sessione che permette la contrattazione da parte del client e del server del livello di sicurezza da usare ed il completamento delle autenticazioni necessarie alla connessione. Quindi SSL procede con la cifratura della sequenza di byte del protocollo applicazione usato (ad esempio nell'HTTP tutte le informazioni sia di richiesta che di risposta sono completamente cifrate, incluso l'URL richiesto dal client), di qualsiasi contenuto di form compilati (quindi anche eventuali numeri di carte di credito ad esempio), di ogni informazione sulle autorizzazioni all'accesso (come username e password) e di tutti i dati inviati in risposta dal server al client.

Secure Sockets Layer

Figura 25 - I nove messaggi scambiati da SSL per stabilire una connessione criptata.

Nel protocollo Handshake l'avvio di una nuova connessione può avvenire o da parte del client o da parte del server. Se è il client ad iniziare, allora questi invierà un messaggio di ClientHello e si porrà in attesa della risposta del server, che avviene con un messaggio di ServerHello. Nel caso in cui sia il server ad iniziare la connessione, questo invierà un messaggio di HelloRequest per richiedere al client di iniziare la fase di Hello. Con lo scambio di questi messaggi il client proporrà una lista, ordinata secondo le sue preferenze, contenente le combinazioni di algoritmi supportati per lo scambio di chiavi e cifratura dei dati, mentre spetterà al server la decisione finale per decretare quale di essi dovrà poi essere utilizzato. A questo punto può iniziare o meno, a seconda del metodo di autenticazione impiegato, uno scambio di certificati tra client e server. Il server, per la sua autenticazione, può mandare un messaggio di ServerCertificate che contiene la sua chiave pubblica che viene utilizzata dal client per autenticare il server e per cifrare il pre-master secret. Il client controlla anche che il nome del server nel certificato corrisponda a quello da lui usato per la connessione. Se il server non ha certificato e quindi non può spedire il pre-master secret in modo sicuro, manda un ServerKeyExchange che integra il campo CipherSuite del ServerHello. Infatti, mentre con il campo CipherSuite il server sceglie l’algoritmo di cifratura più forte supportato da entrambi e la dimensione delle chiavi, con questo messaggio il server crea e spedisce una chiave temporanea al client. Inoltre il server può richiedere di autenticare il client un certificato attraverso il messaggio ClientCertificateRequest. Questa fase, opzionale, viene utilizzata ad esempio dai siti Web delle banche in cui il server deve verificare l’identità del cliente prima di rilasciare delle informazioni sensibili. Al termine di queste operazioni il server, tramite il messaggio

ServerHelloDone, annuncerà al client che ha terminato con i suoi messaggi di negoziazione iniziali. Tale messaggio non contiene altre informazioni, ma è importante per il client in quanto gli comunica che può passare alla fase successiva della creazione della connessione sicura, dove risponderà con un ClientKeyExchange. Questo messaggio deve essere inviato obbligatoriamente dal client al fine di fissare il pre-master secret. A seconda degli algoritmi crittografici scelti per la fase di autenticazione esistono diversi modi per generare la pre-master-secret:

 RSA: il client genera un numero casuale e lo invia al server cifrato con la chiave pubblica del server (presa dal suo certificato digitale);

 Diffie-Hellman: i parametri pubblici DH del server vengono estratti dal suo certificato; se il client ne ha uno anche i suoi DH vengono estratti da questo, altrimenti vengono generati al momento. È sulla base di tali parametri che client e server negoziano la pre-master-secret;

 Diffie-Hellman Ephemeral: indipendentemente dai certificati, sia server che client generano al momento i parametri di Diffie-Hellman per ogni sessione.

Entrambi i partecipanti (client e server) calcolano il master secret localmente e da quello generano la chiave di sessione. Dopodiché, l’invio del messaggio ChangeCipherSpec conferma al server che tutti i messaggi che seguiranno saranno autenticati e verranno cifrati usando le chiavi e gli algoritmi appena negoziati. La fase di handshake terminerà con l'invio, da entrambe le parti, di un messaggio di Finished che sarà il primo dato ad essere cifrato. Se il client è in grado di decifrare con successo il ServerFinishedMessage e di validare gli hash che contiene ha la garanzia che l’handshake