Autenticazione biometrica remota: come farla, alla luce delle linee guida NIST

La recente pubblicazione di un draft dell’aggiornamento delle linee guida del NIST sull’autenticazione remota è occasione per molte discussioni sui diversi meccanismi disponibili e sulla loro efficacia/sicurezza. Come indicato chiaramente dal NIST, la scelta di un meccanismo di autenticazione si basa su una valutazione del rischio legata al contesto di utilizzo, e quindi anche alle condizioni che possono rendere più o meno rilevanti le diverse minacce che il meccanismo riesce o non riesce a contrastare. Queste condizioni cambiano nel tempo: un meccanismo che si può ritenere adeguato oggi, può non esserlo più domani. Ad esempio, lo stesso NIST pur evidenziando i limiti dell’autenticazione attraverso l’uso di SMS, non ne vieta l’utilizzo, neppure in nuovi progetti, bensì indica che potrebbe essere vietata in versioni future delle linee guida, perché a seconda del contesto e dei controlli aggiuntivi (le stesse linee guida ne indicano per l’uso di SMS), un meccanismo può ancora essere reso sufficientemente sicuro, e le alternative possono essere per contro poco diffuse, poco usabili o troppo costose in relazione alla miglior sicurezza che offrono.

Un gruppo importante di tecnologie di autenticazione è quello legato alla biometria. Quando si parla di autenticazione, si dice che è basata su qualcosa che si sa (ad esempio, password), qualcosa che si ha (ad esempio, una smart card) e/o qualcosa che si è, che fa appunto riferimento alle caratteristiche biometriche. Nell’autenticazione a due fattori, si prevede l’utilizzo di due fattori appartenenti a due di queste categorie: ad esempio, una password e un’impronta digitale. Si vuole infatti garantire che se uno dei due fattori è compromesso, l’altro sia ancora sicuro, dato che le minacce a cui sono vulnerabili i diversi fattori sono in generale diversi, e quindi, ad esempio, i modi con cui può essere sottratta una password non sono efficaci per sottrarre anche una smart card.

Da molti anni siamo abituati a vedere porte che si aprono solo dopo aver letto l’impronta digitale o l’iride di una persona, e di recente si sono diffusi i lettori di impronta digitale utilizzati per sbloccare un pc o uno smartphone. Sembra quindi naturale estendere l’uso di queste tecnologie all’autenticazione ad un servizio remoto, ma è necessario avere chiare le importanti differenze che ci sono fra un utilizzo locale ed uno remoto.

Facciamo prima un attimo mente locale all’autenticazione biometrica in sé. Essenzialmente, un sensore legge una caratteristica del corpo della persona che si vuole autenticare e la codifica in una sequenza di valori che la invia ad un sistema che la confronta con la copia conservata in un database. Se il confronto ha successo, la persona è autenticata. La caratteristica che viene letta, e quindi idealmente la sequenza di valori, in generale non cambia e non può essere cambiata per tutta la vita della persona. Ci possiamo quindi chiedere che cosa ci sia di diverso rispetto all’inviare, al posto di quella sequenza di valori, una password, anch’essa sempre la stessa. Non solo: la caratteristica biometrica non è neppure segreta: lasciamo le nostre impronte digitali ovunque, e comunque tutti i sistemi che ci autenticano con una certa caratteristica ne conservano una copia… Il punto è che ci si aspetta che la caratteristica venga letta dal sensore che, se ben realizzato, la leggerà solo dal corpo del soggetto. Quindi, anche se la sequenza di valori è nota e non varia, il sensore la produrrà solo in presenza del soggetto. L’autenticazione consiste quindi nell’atto del riconoscimento della caratteristica biometrica da parte del sensore (il fatto che la confronti con un database è accessorio) e non nell’invio dei valori ad un server.

Ma c’è allora un’altra ipotesi, meno evidente ma altrettanto importante: ci si aspetta che il sensore, il sistema e il canale di comunicazione fra di essi siano sotto il controllo di chi effettua l’autenticazione, che quindi se ne può fidare. Consideriamo infatti un varco per l’accesso ad un locale, che preveda il controllo dell’impronta digitale. Immaginiamo quindi una persona che arrivi, tiri fuori il proprio lettore, ci appoggi il pollice e dica alla guardia: “Il mio lettore dice che la mia impronta digitale ha questa sequenza di valori, che come può verificare corrisponde a quella autorizzata, quindi mi può fare passare”. Ovviamente lo considereremmo una richiesta assurda… bene, con l’autenticazione biometrica da remoto, in generale facciamo esattamente questo: il sensore è infatti sullo smarphone del soggetto che si deve autenticare. Anzi, in molti casi, l’intero processo di verifica è locale sullo smartphone, che non è sotto il controllo di chi autentica. Ma anche se il database fosse sotto il controllo di chi autentica, comunque stiamo parlando di un’informazione che, come abbiamo detto, non è segreta, e che quindi in generale chiunque potrebbe inviare.

Eppure, se possiamo considerare debole l’autenticazione biometrica da remoto, non possiamo dire che l’utilizzo dell’impronta digitale su di uno smartphone non possa offrire qualche protezione in più in caso di autenticazione remota. Il punto è che in questi casi, quando attraverso l’impronta digitale si sblocca lo smartphone, si accede in generale ad una app legata allo smarphone stesso, che viene riconosciuta dal sistema remoto che sta effettuando l’autenticazione. Senza impronta, non si accede allo smartphone e quindi alla app. In questo caso quindi, l’autenticazione remota si basa su qualcosa che si ha (lo smartphone o la app ad esso legata) e non sulla biometria in sé, perché, come detto prima, l’aspetto cardine è la lettura dell’impronta da parte del sensore, e non l’invio di valori ad un server remoto. L’impronta è solo un modo per dare maggiore garanzia, indirettamente, che quello smartphone sia effettivamente in possesso del proprietario, ma non è parte dell’autenticazione remota. Sarebbe quindi improprio considerare questo sistema un’autenticazione a due fattori (biometria e possesso dello smartphone). Ad esempio, nel caso di uno smartphone aziendale che venisse passato legittimamente ad un collega, che quindi sostituisse la propria impronta a quella originale, questo collega si potrebbe legittimamente autenticare, dato che il sistema remoto non avrebbe visibilità del cambio di impronta ma solo della presenza del corretto smartphone. Oltre allo smartphone quindi, per ottenere una corretta autenticazione a due fattori servirebbe ad esempio una password (qualcosa che si sa). Un po’ come dire che richiedere che lo smartphone sia protetto da un meccanismo di sblocco con PIN, non ci dà in sé l’autenticazione a due fattori, perché l’utilizzo del PIN non è verificabile da remoto. Per tornare alle linee guida del NIST, indicano chiaramente che è previsto l’uso della biometria “to unlock authenticators and prevent repudiation of registration”, e quindi non direttamente per l’autenticazione remota. Ci si potrebbe chiedere allora perché l’utilizzo di una smart card con PIN è considerata autenticazione remota a due fattori, dato che anche il PIN è utilizzato localmente per sbloccare la smart card. Il fatto è che il PIN, a differenza dell’impronta, è un’informazione segreta che necessariamente deve essere fornita alla smart card, quindi l’utilizzo della smart card presuppone necessariamente la conoscenza del PIN. La stessa certezza non si ha in generale, per il servizio remoto, quando viene sbloccato un cellulare mediante impronta digitale.

Tutto questo mostra come il tema dei meccanismi adatti per l’autenticazione dipenda anche da dettagli non ovvi. La scelta di un meccanismo si basa su logiche di gestione del rischio legate alle minacce dello specifico contesto, ma anche su esigenze di usabilità: dove il rischio è accettabile, sono in generale da preferire meccanismi i più economici e di più facile e diffusa adozione. Se così non fosse, sarebbe banale richiedere sempre i meccanismi più robusti, come gli autenticatori hardware. Le stesse linee guida NIST prevedono tre livelli di “assurance”, come molti standard e come in Italia prevede anche SPID, e tutti questi prevedono l’utilizzo obbligatorio di autenticatori “fisici” (hardware) solo al livello più alto. Non è un caso: sono probabilmente i meccanismi più “sicuri” per un’autenticazione remota, ma sono anche i più costosi e soprattutto quelli meno usabili. Il passato, anche italiano, ci mostra chiaramente come richiedere meccanismi solo sulla base di considerazioni di “maggior sicurezza”, senza tenere conto di costi e usabilità, sia una garanzia di fallimento per qualsiasi progetto.