La PSD2
All’interno della direttiva n. 2366 del 2015 dell’Unione Europea, nota anche come PSD2 e indirizzata agli intermediari di servizi di pagamento, è contenuto un articolo che dispone l’obbligo di dotazione di sistemi di autenticazione forte per l’accesso online ai servizi bancari da parte dei clienti. Le specifiche tecniche di riferimento sono contenute nel documento EBA-Op-2019-06 dell’E.B.A. (Autorità Bancaria Europea) e si parla in particolar modo di combinare almeno tre dei seguenti requisiti: inerenza, possesso e conoscenza. L’inerenza è riferita a caratteristiche fisiche dell’utente, tra le quali si ammettono ad esempio impronte digitali, fisionomia, timbro vocale e retina. Il possesso è relativo a oggetti materiali o immateriali che solo l’utente possiede, come ad esempio un software configurato in maniera unica, una smartcard, il proprio smartphone o la propria scheda SIM (sulla quale ricevere SMS di tipo OTP). La conoscenza, infine, si riferisce ad esempio ad una password, un PIN oppure ad informazioni mnemoniche riguardanti la sfera personale dell’utente.
Per quelle banche che riescono ad essere lungimiranti, la PSD2 è un’occasione per migliorare ulteriormente i propri sistemi e i propri servizi, tutto a vantaggio dell’agilità dei processi interni e della competitività di mercato. Purtroppo però per la parte relativa all’autenticazione forte la direttiva lascia un ampio margine di flessibilità. Per cui la questione, discrezionalmente, può essere affrontata con il minimo sforzo oppure con notevole impegno, ottenendo in entrambi i casi piena conformità alla normativa. Tutte le opzioni previste dalla direttiva possono essere combinate tra loro in moltissimi modi, anche tirando a sorte (da qui il minimo sforzo). Invece le combinazioni che garantiscano un livello di sicurezza elevatissimo e contemporaneamente un livello di privacy notevole sono ben poche e da implementare con estrema attenzione (da qui il notevole impegno). Provo ad argomentare meglio nel paragrafo successivo.
Problemi di privacy dell’utente e vulnerabilità di password ed sms
Al momento moltissime banche si sono adeguate alla PSD2 utilizzando varie modalità; quasi tutte hanno in comune PIN e/o password e/o domande segrete e le combinano con vari altri metodi, tra i quali ad esempio:
- OTP su sms
- Token software (su smartphone/tablet)
- Token hardware (ad esempio chiavetta con display) fornito dalla banca
- Dati biometrici (in particolare impronte digitali acquisite tramite smartphone/tablet)
Purtroppo i casi di accesso abusivo con relativo furto di denaro continuano ad esserci, anche per istituti di credito che si sono uniformati alla direttiva (basta cercare sul web le notizie tramite la parola chiave “sim swap” ad esempio). A tale proposito, le banche potrebbero affermare che uno dei problemi principali, ossia la clonazione delle schede SIM, non sia una loro responsabilità e che gli operatori telefonici ancora tardino a rafforzare le misure per arginare il fenomeno, ad esempio con l’adozione delle “eSIM” eccetera. In effetti potrebbe essere vero che una parte di responsabilità della clonazione delle SIM sia dei gestori telefonici ma non ho elementi a sufficienza per entrare nel merito di questa diatriba. Piuttosto voglio evidenziare quali sono le debolezze palesi dei quattro esempi di autenticazione forte sopra elencati.
Innanzitutto la conoscenza, ossia la misura comune a quasi tutti i sistemi di autenticazione delle banche, cioè come già detto password / PIN / domande segrete - chiamiamole per semplicità “parole d’ordine” -, ha come punto debole l’utente stesso. Se vengono scelte parole d’ordine deboli o se queste vengono fornite deliberatamente a qualcuno o se vengono inserite abboccando a email di phishing, ecco che i rimedi sono ben pochi. Per fortuna ci si può salvare in extremis cambiandole una volta accortisi dei propri errori o della propria ingenuità, a patto che gli altri fattori abbinati (inerenza e/o possesso) siano ben applicati.
L’OTP su sms, come già detto, ad oggi, è vulnerabile tanto quanto è possibile clonare SIM (ossia non è per niente facile ma ogni tanto succede, stando alle notizie di cronaca). Ma anche qualora la clonazione fosse resa complicata, ad esempio con le eSIM o ancor meglio con sistemi di verifica dei documenti di identità presentati (confronto con la fotografia del documento originario, accesso al sistema informativo SCIPAFI etc.), ci potrebbe essere sempre un punto vendita colluso con la criminalità che clona SIM.
Il token software tipicamente si attiva tramite una procedura di registrazione che alla fine crea una chiave correlata all’identificativo univoco di un dispositivo (ad esempio smartphone o tablet). Questo fa sì che solamente chi è in possesso di quel dispositivo possa effettuare l’autenticazione. Le possibili debolezze di questo sistema stanno a monte, specialmente in due anelli della catena. La prima debolezza risiede nella fase di registrazione, che prevede tipicamente l’uso di combinazioni di OTP su sms e parole d’ordine di vario tipo, quindi espone a problemi di clonazione di SIM e di phishing o altri metodi di sottrazione di credenziali basate sulla conoscenza. La seconda debolezza è la protezione del dispositivo. Se l’utente non attiva sul proprio dispositivo nel quale ha installato il token software una protezione robusta (come PIN con crittografia della memoria) e questo dispositivo viene rubato, si possono avere conseguenze spiacevoli. Se perdipiù nel dispositivo stesso sono state annotate anche le credenziali di accesso (ad esempio in una APP per scrivere appunti) il disastro è assicurato.
Il token hardware è probabilmente il mezzo globalmente meno debole tra tutti (a livello sia di sicurezza che di privacy). Chiaramente ha dei costi notevoli di approvvigionamento per le banche, soprattutto se ci si rivolge a produttori di fascia alta. Quest’ultima opzione è imprescindibile se si vogliono innalzare al massimo i livelli di sicurezza. Intatti l’unica possibile debolezza, forse remota, sta nel metodo di generazione delle chiavi crittografiche di cui è a conoscenza solo il produttore dei token hardware, il quale deve essere in grado di custodirlo con estrema cautela.
I dati biometrici, a livello di sicurezza, hanno vari livelli di robustezza, tutti comunque molto elevati. Le impronte digitali e il timbro vocale sono piuttosto complicati da replicare, la retina ancora di più. E’ anche molto complicato sottrarre tali informazioni ad un soggetto senza che questi se ne accorga. Ma se per caso il dato biometrico venisse rubato, allora si rimarrebbe “violati” per sempre (un’apposita app potrebbe tornare utile a ricordare cosa rimane: “hai ancora a disposizione otto polpastrelli, una retina, la tua voce e il profilo sinistro”). Chi darebbe quindi in mano a terzi un proprio dato biometrico? E’ chiaro che il destinatario - una banca in questo caso - non lo memorizzerebbe in chiaro nei propri archivi, bensì trattato con opportune operazioni di hashing che impedirebbero di ricostruire il dato originale. Ma c’è da chiedersi: se per caso per una sola volta, a causa di errore materiale, lo memorizzasse in chiaro? E se per caso il dato venisse sottratto da un’intrusione informatica? In quest’ultima ipotesi, anche un dato non in chiaro potrebbe essere sensibile, in quanto è stata dimostrata da alcuni ricercatori la possibilità, per determinate casistiche, di ricostruire il dato originario (vedasi vari articoli sul web). Quindi, ricapitolando, il vero problema dei dati biometrici non è tanto la sicurezza (in linea teorica, infatti, qualsiasi tipo di credenziale può essere trafugata) ma è la privacy, perché ci si espone alla sottrazione di dati sensibili e immutabili, patrimonio insostituibile di un singolo individuo.
Per quanto riguarda i casi di sottrazione di credenziali di accesso, in questo paragrafo ho descritto sia quelli che accadono molto di frequente, sia quelli di estrema rarità, sia anche casi, se pur plausibili, forse mai accaduti finora. Questi ultimi non sono da sottovalutare, specialmente in questo contesto poiché, quando si tratta di sottrarre denaro, i delinquenti cibernetici sono sempre pronti a superare sé stessi.
Due soluzioni ad elevata sicurezza e tutela della privacy dei clienti
Tra le soluzioni per l’autenticazione forte, conformi alla PSD2 ed in grado di garantire sicurezza e privacy ai massimi livelli attualmente a disposizione, sono in grado di proporne a grandi linee solo due. Specifico in premessa che entrambe le soluzioni vanno accoppiate ad accesso basato su conoscenza, implementato nelle forme che si ritengano più opportune, e che la privacy del cliente viene tutelata dal fatto che non si prevede l’acquisizione di dati biometrici né di altre informazioni sensibili.
La prima soluzione, già indirettamente enunciata, prevede l’adozione di token hardware protetti da PIN. In caso di furto o smarrimento, la protezione di un PIN può prevenire abusi (un cliente potrebbe aver attaccato un foglietto al token con annotate le credenziali di accesso ma si spera che non abbia annotato anche lo stesso PIN del token - e a quel punto, come prescritto dalla PSD2, la banca non avrebbe colpa). I token hardware devono essere di alta qualità, sia come componentistica, per garantire durata e resistenza, sia come software, per garantire robustezza crittografica. Quest’ultima ha sempre una durata limitata nel tempo quindi è opportuno periodicamente richiamare i dispositivi e sostituirli con dei nuovi. Tutti questi requisiti hanno costi sensibili ma garantiscono notevolissimi livelli di protezione (e massima tutela per le banche in caso di rivalsa da parte dei clienti).
La seconda soluzione è forse più interessante della prima perché garantisce lo stesso livello di sicurezza ma non necessita costosi approvvigionamenti di apparecchiature; di contro però richiede un po’ di tempo da dedicare all’abilitazione dei clienti e sporadiche visite in banca da parte loro. Si tratta di un un token software in cui è modificata la fase di registrazione. L’utente non sarà più autonomo nel registrare il token all’interno di un proprio dispositivo ma dovrà recarsi in banca almeno la prima volta o se cambia dispositivo. Tutto sta nel rimpiazzare il tipico invio di sms, onde prevenire le clonazioni di SIM, con un’operazione da effettuare di persona presso la propria filiale di riferimento, previo riconoscimento del cliente da parte dell’impiegato di banca. Nella maggior parte dei dispositivi (tipicamente si tratta di smartphone e tablet) è possibile ottenere un codice identificativo univoco del dispositivo stesso, mentre in altri no. Nel primo caso il cliente può fare la registrazione del proprio dispositivo solamente una volta (oltre ad ogni altra volta in cui dovesse cambiare dispositivo). Nel secondo caso, l’identificativo verrebbe creato all’atto dell’installazione della APP della banca, per cui il cliente dovrà fare la registrazione, oltre che nelle circostanze previste dal primo caso, anche ogni qualvolta disinstalli e reinstalli l’APP ed anche ogni qualvolta faccia un reset del dispositivo. Certamente può risultare scomodo ma d’altro canto alti livelli di sicurezza costano tanto e se la banca non paga il costo del token hardware, saranno i clienti a farne le spese in termini di tempo impiegato (e in parte la banca ugualmente dovrà investire un po’ del tempo della propria forza lavoro nell’assistere questi clienti). Metodi per applicare questo tipo di token ve ne sarebbero tanti, in teoria; ne posso proporre uno che ridurrebbe al minimo i disagi. Una volta installata l’APP della banca, questa automaticamente lancia un messaggio al server comunicando l’hash di un identificativo (a seconda, come già detto, sarà o l’id univoco del dispositivo o l’id associato all’installazione dell’app). Il server risponderà con un numero progressivo corrispondente all’id del record del database in cui ha memorizzato il predetto hash, e questo dato viene registrato offline nell’APP affinché il cliente lo possa comunicare all’impiegato di banca. Il fatto che il cliente comunichi un numero intero relativamente piccolo anziché l’hash dell’identificativo del dispositivo è pensato, banalmente, per evitare di dover dettare una stringa complicata con centinaia di caratteri. A quel punto il token viene attivato, associando l’hash all’utenza del cliente, sempre nel database della banca.
Conclusioni
Quasi sempre l’anello più debole della catena della sicurezza è l’utente finale ed è complicato prevenire comportamenti scorretti da parte sua tanto quanto è complicato diffondere la cultura informatica e le buone norme sulla sicurezza. Pertanto salvaguardare i clienti, perfino da sé stessi, ritengo sia un normale dovere delle banche. Può essere visto come un complemento imprescindibile della tutela di depositi, risparmi, investimenti e altri beni materiali e immateriali di cui si occupano normalmente gli istituti di credito. Nel momento in cui un cliente dovesse subire una violazione informatica del proprio conto online, la banca potrà documentare di avere fatto tutto il possibile per evitarlo, a partire dalla comunicazione chiara delle modalità e delle precauzioni minime di utilizzo (non fornire mai credenziali a terzi, non portare mai con sé le credenziali scritte su supporti cartacei, proteggere i dispositivi con PIN, installare anti-malware etc.) fino a dimostrare inconfutabilmente che, in virtù delle elevatissime dotazioni di sicurezza adottate, la causa sia stata esclusivamente la negligenza del cliente. Quindi la catena di gestione della sicurezza deve constare almeno di due anelli:
- raccomandazioni iniziali alla clientela all’atto del rilascio delle credenziali di accesso ai sistemi informatici online, nonché ad ogni successivo aggiornamento che ne modifichi le modalità operative (ciò implica anche specifica e puntuale formazione dei dipendenti, che devono ottenere elevata sensibilizzazione sull’argomento)
- adozione di misure di sicurezza di elevato profilo
E’ indubbio che il punto 2 richiede dei costi potenzialmente notevoli. Per ridurli in parte, ritengo sia ammissibile che la banca inserisca un anello intermedio alla precedente catena: la scelta individuale, effettuata cioè da ogni singolo cliente supportato dall’impiegato di banca, di un livello di sicurezza tra “alto” (meno costoso per la banca) e “massimo” (più costoso). Il livello “alto”, ad esempio, potrebbe includere l’utilizzo di dati biometrici - che potrebbe incontrare il gradimento di quei clienti che prediligono la comodità rispetto alla privacy. Potrebbe anche includere il token software “tradizionale” via sms - che potrebbe essere sufficiente per quei clienti esperti che prevengono in prima persona, con le dovute precauzioni, fenomeni di phishing, clonazioni di SIM, infezioni di malware, omissioni di protezione dei dispositivi con PIN eccetera. Il livello “massimo”, invece, potrebbe includere quelle due soluzioni che ho descritto nel precedente paragrafo, che sono più costose e adatte agli utenti che hanno poca dimestichezza con l’informatica o che hanno profili di rischio maggiore (come aziende medio-grandi, enti pubblici, associazioni importanti etc.) che richiedono, appunto, il massimo della protezione.
In uno scenario imminente che porterà il mondo produttivo a concentrare sempre più forza lavoro nel contrasto agli attacchi informatici, le banche giocano un ruolo attivo e determinante. I piani su cui porre la loro attenzione sono tanti e non basta certamente solo creare dei sistemi di autenticazione più robusti possibile. Ma proprio l’autenticazione, però, è il fronte sul quale c’è la maggiore esposizione quindi ritengo occorra averne massima cura e, in tal senso, mi auguro di avere offerto con questo articolo alcuni spunti su cui riflettere, sia alle banche che ai loro clienti.
Infine qualunque parere su ciò che ho scritto, specialmente se ponderato e costruttivo, è ben gradito tramite il mio indirizzo email che si trova in fondo alla pagina.