di  -  giovedì 20 gennaio 2011

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!!!

22 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    [D]
     scrive: 

    Povere banche XD Messa secondo i termini dell’articolo, sembra quasi che preferirebbero tornare ai tempi del far west con la cassaforte dietro il bancone ed il bandito con il viso nascosto dal fazzolettone XD

    Comunque, finito il lato comico, sono proprio curioso di vedere se ho avuto il sospetto giusto riguardo i rischi di sicurezza “temporale” degli OTP… Einstein ed il tempo formano sempre miscele a rischio: potrebbe il tempo dilatarsi in maniera diversa, in misure diverse, a seconda del posto nel quale ci troviamo ?

  • # 2
    Tambu
     scrive: 

    sono cent’anni che “tra cent’anni…” e ancora le astronavi non si vedono :D comunque aspetto con trepidazione la seconda parte di questo ottimo articolo :)

  • # 3
    Alessandro
     scrive: 

    Interessante! In effetti, nonostante gli effetti della relativita’ alla nostra scala siano molto ridotti (ma non sempre trascurabili!), a furia di muovermi ad alta velocita’ per il sistema solare o di soggiornare nello spazio potrei perdere la sincronizzazione con l’orologio del server della banca…

    Ma non credo ci si debba preoccupare: la chiavetta, per allora, avra’ accellerometro e sensore di gravita’ per calcolare un fattore di conversione per mantenersi allineato con il server della banca :-)

  • # 4
    pietrov
     scrive: 

    Se il problema fosse solo la perdita di sincronizzazione, il problema sarebbe facilmente risolvibile: basterebbe un “cellulare evoluto” con su il programmino che ti genera i codici, e basterebbe sincronizzarne l’orologio con il server…

    Temo che i problemi siano altri!
    Ma non ci riesco ad arrivare…
    Comunque è da ben prima dei tempi delle guerre mondiali che è in atto la lotta tra chi inventa algoritmi crittografici e chi cerca di romperli: tra cent’anni farà sorridere ripensare agli strumenti barbari ai quali nel 2010 ci si affidava per le transazioni economiche!

  • # 5
    albert
     scrive: 

    “Torniamo ora sulla nostra DeLorean ed impostiamo l’orologio sul 1° gennaio dell’anno 2091. Tra novant’anni il mondo sarà molto diverso”….

    ne mancano solo 80….

  • # 6
    Dario S.
     scrive: 

    @[D]
    Il tempo “scorre” diversamente anche a seconda della gravità a cui sei sottoposto. Maggiore è la gravità, più lento è il tempo… quindi ci potrebbe essere una differenza se i server stanno al piano terra e tu vivi al 5 piano ;)

    Inoltre sei influenzato anche da grosse masse vicino a te (un esempio potrebbe essere una grossa catena montuosa).

    Comunque credo che il problema della relatività sia MOOOOOOOLTO relativo (almeno in quest’ottica, chissà che l’autore non stia pensando tutt’altro ^^), nel senso che probabilmente l’errore più grosso è dato dagli orologi interni delle chiavette che perdono di sincronia con quello dei server.
    Non per niente queste chiavette si dovrebbero cambiare ogni 5 anni!

  • # 7
    v1
     scrive: 

    tra 80 anni andremo tutti in giro in bicicletta… la macchinetta a gas per le grandi occasioni, il mulo per chi non se la può permettere. altro che viaggi nel sistema solare

  • # 8
    albert
     scrive: 

    In merito a questa:
    K = f(t + c1 + c2 + … + cn)

    L’avrei espressa così:
    K = f(t,c1,c2,…cn)

    cioè K funzione di n+1 variabili

    Ma temo che la funzione f di generazione della chiave K sia più semplice:

    K = f(t,c1)

    dove t è il valore assoluto del tempo e c1 rappresenta il codice assegnato alla chiavetta (codice a barre).
    La successiva associazione tra cliente \Rossi\ e chiavetta con codice c1 permetterà al software del server di riconoscere l’utente.

    Quindi la chiave K è funzione di 2 variabili ed i dati personali dell’utente non entrano nella funzione di generazione della chiave. Solo in seguito all’apertura dell’account quella determinata chiavetta (c1) è funzionale al conto del sig. Rossi.

    Se invece che al sig Rossi fosse stata assegnata al sig Bianchi, sarebbe cambiata l’associazione presente nel database della banca, ma non la chiavetta (c1) o l’algoritmimo impresso nel chip in fase di fabbricazione (la funzione f).

    Poi magari ogni chiavetta ha un algoritmo diverso per cui

    K = f(t,c1), Z = g(t,c2) per cui oltre a cambiare una variabile (il codice identificativo della chiavetta, c1…c2…etc.) cambia pure la funzione (f,g…etc.)

  • # 9
    Fabio Bonomo (Autore del post)
     scrive: 

    @v1: Forse hai ragione, ma credo che l’estremo bisogno di risorse energetiche di cui avremo bisogno in futuro ci spingerà a cercarle al di fuori dalla terra, altrimenti non avremo tante chance di reggere gli attuali e futuri ritmi di crescita!

    @albert: Chiaramente la tua esposizione è matematicamente più corretta e vicina ad una realtà (benché appunto ogni algoritmo è diverso dagli altri), ma ai fini di un articolo accessibile a tutti ho preferito esprimere il concetto di base più che il formalismo matematico. Ti ringrazio in ogni caso per il dettaglio, che spero possa essere apprezzato da chi ha qualche nozione di matematica un po’ più avanzata :-).

  • # 10
    albert
     scrive: 

    Ben inteso che la mia non era una critica.
    Assolutamente daccordo sulla necessità di semplificare :))

    Complimenti per l’articolo, ha chiarito molte cose che ignoravo.
    Seguirò senz’altro la seconda parte.

  • # 11
    Fabio Bonomo (Autore del post)
     scrive: 

    @albert: Tranquillo ho inteso bene! I commenti che integrano con qualche tecnicismo in più sono sempre ben accetti!

  • # 12
    Ciano
     scrive: 

    Io aggiungerei anche, che non ha senso generare lato server un pool di 60000 chiavi valide, ha più senso generare una chiave con un time stamp meno preciso, per esempio un minuto.

    L’OTP che ho io usa 6 cifre decimali e con un pool di 60000 chiavi valide un hacker può benissimo tentare con un codice selezionato probabilisticamente.

  • # 13
    Ciano
     scrive: 

    PS: finalmente i commenti funzionano di nuovo.

  • # 14
    Emanuele Rampichini
     scrive: 

    Complimenti, articolo molto interessante. E rinnovo pubblicamente il benvenuto in AD. ;-)

  • # 15
    Nat
     scrive: 

    Davvero un bell’articolo, l’argomento e’ molto interessante, anche perche’ riguarda un po’ tutti, sono curioso di leggere il prossimo articolo.

  • # 16
    Willy
     scrive: 

    guardate che Eistein non c’entra niente con tutto ciò , ma bensi
    Bernhard Riemann.E’ lui che ha scoperto , praticamente tutto sulla crittografia e gli algoritimi matematici che vengono usati appunto per crittografare le transazioni bancarie……

  • # 17
    Agi90
     scrive: 

    Credo che l’articolo si riferisca al fatto che se si riuscirà a costruire un computer quantistico sarà possibile rompere molti sistemi crittografici in tempo polinomiale e quindi molto facilmente.

  • # 18
    Fabio Bonomo (Autore del post)
     scrive: 

    @Willy: Sono d’accordo sul fatto che Riemann abbia lavorato moltissimo soprattutto in materia di numeri primi, che come giustamente fai notare sono alla base di molti algoritmi crittografici. Ma in questo articolo non si assegna la paternità ad Einstein di questa materia, ma bensì si parla di OTP e di alcune conseguenze della relatività einsteiniana su di essi.

    @Agi90: Ciò che dici è assolutamente vero, un ipotetico computer quantistico metterà a dura prova molti sistemi di sicurezza moderni… ma ti consiglio di seguire con attenzione la seconda parte dell’articolo, perché sei fuori strada, le ragioni sono altre! :D :D :D

  • # 19
    Alex
     scrive: 

    Articolo ben fatto e divertente, però diciamo che utilizza un po’ il titolo per attrarre il lettore e porre un problema non esistente. Come ha detto un altro lettore poco sopra, gli algoritmi hanno una granularità per esempio di 15 secondi, ciò che rende l’indeterminazione temporale dovuta a tali fattori (e la deriva temporale di tali orologi) un “o” piccolo molto molto trascurabile :D Inoltre non credo che tali calcoli vengano eseguiti batch per ogni chiavetta, ma bensì on demand:
    il server della banca riceve una richiesta di auth, genera n chiavi in base alla finestra (parametro della banca) di validità scelta:
    n = (Finestra validita) / (tempo di refresh Tr)
    agli istanti T0..Tn con Ti = NOW – n*Tr
    con Tn seed esegue f(Ti||AltriSeed)

  • # 20
    Fabio Bonomo (Autore del post)
     scrive: 

    @Alex: Come si intuisce dal paragrafo di apertura, è vero il problema non esiste oggi ma potrebbe esistere in futuro, quindi ti rimando alla seconda parte dell’articolo per scoprire tutti i dettagli :).

    Inoltre, riguardo la seconda parte del tuo commento, forse dalla mia frase non traspare il concetto di ondemand che tu sottolinei giustamente: “A questo proposito, il server ogni minuto (e per ogni singolo HST rilasciato!) genera un insieme di chiavi papabili”, è da intendere usando il termine “rilasciato” non nella sua accezione comune (cioè tutti gli HST di ogni cliente della banca!), ma nel significato di tutte le chiavi generate dagli HST (e quindi rilasciate) in quel particolare minuto e connessi al servizio.
    Pertanto apprezzo molto la tua precisazione che renderà sicuramente più chiaro il concetto al lettore che abbia frainteso la mia frase originaria.

  • # 21
    lucusta
     scrive: 

    bha… sincronizzeranno su una pulsar o sul buco nero supermassivo al centro della via lattea e stiamo a posto.

  • # 22
    albert
     scrive: 

    Anche io come Alex avevo inteso nell’articolo che per ogni HST (dispositivo) rilasciato (account attivo) venissero generate chiavi papabili ogni minuto. L’equivoco era dovuto anche al successivo accenno al campo di tipo BLOB del database e alla mole di dati. E’ invece molto più logico (ed economico in termini computazionali) che la chiave lato server venga prodotta solo quando l’utente richiede l’accesso. Non avrebbe senso generare milioni di chiavi da stoccare per un uso presunto delle stesse da parte di tutti gli HST rilasciati. Bisogna dire però che leggendo l’articolo si aveva la percezione che fosse questa la procedura.

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.