Sono certo che se siete arrivati su questa pagina, è perché vi ha incuriosito il titolo dell’articolo. Vi sarete chiesti cosa mai possa c’entrare Einstein con una banca, ma ancor di più perché mai dovrebbero odiarlo!
Nato ad Ulm nel 1879, Einstein fu autore, nella prima e nella seconda decade del 1900, di due teorie che sconvolsero il mondo scientifico: la teoria della relatività ristretta ed in seguito la teoria della relatività generale.
Lungi dallo sconvolgere le abitudini di vita della gente comune, ci sono aspetti insospettabilmente interconnessi tra le equazioni del genio Tedesco ed una delle moderne, e più utilizzate, tecniche di sicurezza adottate dalle banche di tutto il mondo. Vi condurrò dapprima in un viaggio reale all’interno delle tecnologie che ci permettono di eseguire transazioni online sicure(?), e successivamente andremo insieme nel futuro, in una surreale visione del mondo einsteiniano. Ma andiamo con ordine, ed impostiamo la nostra DeLorean DMC-12 sull’anno 2010…
Anno 2010
L’online banking è ormai da qualche anno una pratica comune un po’ per tutti noi: è comodo, facile e la sua sicurezza sta tutta in una piccola chiavetta (che è comoda anche come portachiavi!).
Questo oggetto, il cui nome tecnico è “Hardware Security Token” (d’ora in poi HST), si basa su una classe di algoritmi che sfruttano gli “One Time Passwords” (OTP), ossia sequenze di caratteri (pseudo)casuali di cui i servizi bancari si servono per autenticare la persona che dispone una transazione. Gli OTP fanno la loro comparsa nel panorama bancario dapprima sotto sembianze cartacee, nella forma di documento stampatoci dalla banca all’atto di attivazione di un conto online (o su richieste successive di rinnovo).
Su questo foglio erano presenti un certo numero di OTP prestampati ed utilizzabili una sola volta. Oggi però, con il sempre crescente numero di operazioni effettuate online, è facile capire come in breve tempo si possano esaurire tutte le stringhe contenute in questi “fogli”, rendendo necessaria l’adozione di sistemi diversi, nella forma di HST utilizzabili un numero esageratamente grande di volte.
Di facile intuizione è il fatto che un OTP è utilizzabile una sola volta, ed è presente un algoritmo che a richiesta genera una nuova stringa, sgravandoci dal compito di dover memorizzare complicate password e di fatto rendendo l’infrastruttura sicura agli attacchi di tipo “replay”, dove cioè il malintenzionato si mette in “ascolto” della nostra password e, una volta individuata, la utilizza senza grossi problemi per eseguire operazioni sul nostro conto.
Esistono i più disparati metodi per implementare un security token: oltre alla già citata “chiavetta” rilasciataci dalla nostra banca ed al foglio di carta, possiamo avere applicazioni java per cellulari, chip sulla carta di credito, servizi web, moduli integrati nel notebook e così via. Ultimamente si sta cominciando a parlare di utilizzare gli OTP anche per eseguire operazioni al bancomat, e si sta pensando di usare gli SMS come strumento per ricevere la stringa piuttosto che un dispositivo come la chiavetta.
La questione è che accentrare su un solo dispositivo tutte le funzionalità, cosa che sarebbe tranquillamente possibile con l’odierna tecnologia, è considerato poco sicuro: una volta perso o trafugatoci il nostro HST siamo davvero scoperti su più fronti, e chiunque ne abbia possesso sarà in grado di bypassare la sicurezza di più servizi.
Tutti questi metodi, indipendentemente da quello scelto, condividono gli stessi algoritmi che stanno alla base degli OTP, e che sono essenzialmente di due tipi: i “Mathematical” ed i “Time Synchronized”. Per entrambi la regola di fondo è la stessa: generare una chiave per l’utente (client) in modo che il servizio (server) sia in grado di verificarne la correttezza, senza la necessità di scambiare nessuna informazione riguardo l’algoritmo per la generazione della stessa. La ragione è chiara: qualsiasi trasmissione infatti, anche cifrata, che riguarda l’algoritmo di creazione della chiave può essere intercettata e decifrata per generare la chiave stessa.
Sia il client che il server stabiliscono quindi una regola comune in modo tale che, da entrambi le parti ed in qualsiasi istante, la chiave generata sia la stessa. La regola viene inserita direttamente nel dispositivo HST che ci viene consegnato, ed una sua replica esatta ma “virtuale” viene conservata dalla banca (o servizio) stessa.
Va inoltre precisato che gli OTP non sono l’unico sistema di sicurezza utilizzato nell’online banking, ma esso è solamente uno dei “fattori” di quello che generalmente si chiama “multi-factor authentication”, ossia una catena di diversi sistemi di protezione (SSL, cifratura asimmetrica, security pin…) che utilizzati contemporaneamente elevano il livello di sicurezza generale. Se infatti “bucassi” uno dei sistemi, ce ne sarebbero almeno un altro paio che mi impedirebbero di bypassare il sistema nel suo complesso.
Gli algoritmi di tipo “matematico” si basano sulla creazione di una chiave a partire da un numero (seed) stabilito al momento della creazione del dispositivo stesso. Tramite funzioni definite “one way”, ossia equazioni per cui è relativamente facile trovare la soluzione dati tutti gli input di iniziali, ma è estremamente difficile risalire agli input dal risultato finale (un ottimo esempio di queste one way function è la fattorizzazione dei numeri primi, sulla quale si basa il famoso algoritmo di cifratura asimmetrica RSA, ed è solo dalla difficoltà di computabilità inversa che dipende la sua robustezza), il seed viene utilizzato come base di partenza per generare la nostra chiave, che a sua volta diverrà il seed della chiave successiva e così via: in pratica la chiave attuale è generata a partire dalla chiave precedente, ed otteniamo così una catena di chiavi in cui ognuna di esse rappresenta un singolo anello. Matematicamente parlando, dato un seed “s”, il primo OTP “K” sarà:
K = f(s)
e di conseguenza i successivi:
K = f(f(s)); K = f(f(f(s))); K = f(f(f(f(s))))….
dove f indica preferibilmente una funzione di tipo one way. Esiste anche un altro metodo, chiamato challenge response authentication, che si basa sullo scambio tra client e server di numeri casuali o pseudo casuali per generare la chiave, in modo tale da stabilire una sequenza di numeri conosciuti solo agli “interessati”, sulla base della quale applicare la nostra funzione f.
Gli algoritmi basati invece sulla sincronizzazione temporale, sono quelli utilizzati dalle nostre banche, soprattutto per il fatto che, a differenza dei metodi matematici che in qualche modo richiedono che client e server si parlino (per comunicare la chiave precedente o i numeri casuali), non richiedono un dialogo diretto tra l’HST ed il server del servizio, per la generazione della chiave.
Tutto ciò li rende facili da produrre ed economici, in quanto non servono porte usb driver e software, e sono di semplice utilizzo anche per persone con poca familiarità con il PC. Grazie ad un orologio molto preciso annegato nell’hardware della chiavetta, siamo in grado di usare il timestamp “t” (ossia un valore numerico con molte cifre che identifica in maniera univoca un certo istante nel tempo) da esso generato, come base per l’algoritmo che genererà la chiave (f(t)).
Capite bene che, essendo il “tempo” un concetto universale su tutta la terra (al netto dei fusi orari, e fingendo che la teoria della relatività non esista, anche se invece ha un impatto proprio su questa questione come vedremo in seguito), abbiamo un numero che è conosciuto sia dal client che dal server senza bisogno di nessuno scambio di informazioni.
Rendiamo ora esplicita un’evidenza: affinchè ogni cliente disponga di un OTP “personale”, l’algoritmo per la generazione della chiave tiene conto anche di informazioni statiche, quali ad esempio il nostro numero di conto (c1) piuttosto che il numero di pratica bancaria (c2) od ancora il codice fiscale (c3). Questi dati, opportunamente combinati con il timestamp, forniscono una base per la generazione della chiave valida solo per la chiavetta associata al mio conto, e che sarà possibile utilizzare una volta sola (si noti che l’operando “+” è usato solo a scopo dimostrativo, in realtà le operazioni sono ben più complesse!):
K = f(t + c1 + c2 + … + cn)
Per ovviare a problemi di sincronizzazione dovuti alla non perfetta precisione degli orologi integrati (questa è la ragione per cui il codice cambia così spesso, mentre nel caso di algoritmi matematici la chiave cambia solo quando la precedente viene generata e quindi richiesta dal client), la chiave che abbiamo generato avrà una validità temporale limitata (di solito un minuto o due), anche perché altrimenti non avremmo neppure il tempo di leggere la chiave che sarebbe già spirata!
A questo proposito, il server ogni minuto (e per ogni singolo HST rilasciato!) genera un insieme di chiavi “papabili” che sono memorizzate su un database (per mezzo di un campo di tipo BLOB, data la mole di dati), in quanto non si è in grado di prevedere l’esatto timestamp prodotto dal client (proprio a causa dei suddetti problemi di sincronizzazione).
Il numero di chiavi valide è dato dal numero di intervalli di tempo considerati nell’unità: se cambiamo la chiave ogni minuto ed il nostro intervallo scelto è di un centesimo di secondo, dobbiamo generare ogni 60 secondi ben 6000 possibili chiavi e tutte potenzialmente valide, e solo se quella fornitaci dal nostro HST è tra queste, allora autorizzeremo la transazione e renderemo l’intero blocco di chiavi non più valide fino al prossimo step.
Adesso che abbiamo un’idea di quale sia il funzionamento degli OTP, è il caso di chiedersi se questi dispositivi siano sicuri oppure no. Le soluzioni di tipo matematico, rimangono comunque vulnerabili agli attacchi di tipo MITM(man in the middle), in quanto, anche se con molta difficoltà, avendo a disposizione un certo numero di chiavi già usate, è possibile ricostruire l’algoritmo originale (soprattutto quando il numero è solo pseudo casuale o peggio statico (come nella questione riguardante l’hack della PS3)).
Per quel che riguarda più in generale anche gli OTP basati sulla sincronizzazione temporale, è ovvio che se l’algoritmo diventa in qualche modo noto la sicurezza si annulla di colpo, ma generalmente questo non accade con facilità (bisognerebbe violare fisicamente i server del servizio bancario, e non è proprio semplice!) quindi possiamo considerare la tecnologia molto valida, specie se utilizzata in un contesto in cui più protocolli di sicurezza sono utilizzati in cascata.
E’ anche vero che spesso il problema è tra lo schienale della sedia ed il monitor. Tutte queste tecnologie sono infatti molto vulnerabili alle tecniche di attacco definite di “social engineering”, ossia quelle in cui in un qualsivoglia modo si ottiene la chiave OTP direttamente dal client (un po’ come recuperare il numero di carta di credito attraverso facendo phishing). Se il malintenzionato ottiene la chiave, può collezionarne un certo numero ed in caso di OTP matematici può eseguire un reverse della funzione che abbiamo visto in precedenza.
Oppure, se abbiamo una chiave generata dal timestamp, può tranquillamente usarla istantaneamente, e prima di noi, per eseguire transazioni che il server non esiterà a considerare come autentiche. E’ in questi scenari che avere anche una password di accesso al servizio di online banking molto robusta, e magari anche un pin che cambi molto frequentemente, aiuta ad evitare attacchi di questo genere, a volte causati dalla superficialità ed a volte dall’ignoranza.
Torniamo ora sulla nostra DeLorean ed impostiamo l’orologio sul 1° gennaio dell’anno 2091. Tra ottant’anni il mondo sarà molto diverso, ci sposteremo a velocità incredibili da un punto all’altro del globo ed i viaggi all’interno del sistema solare saranno sempre più comuni. Tutto sarà online, non solo il nostro conto bancario ma anche la nostra intera vita se non addirittura il nostro DNA completo… riusciranno le banche a tenere il passo della tecnologia? Ciò che abbiamo a disposizione oggi, e che consideriamo sufficientemente sicuro, come gli OTP, lo sarà ancora nel futuro? Lo scopriremo insieme nella prossima puntata, ora tenetevi forte… 86MPH…87MPH…88MHP…Grande Giove!!!
