---

Password, SPID, eccetera ¶

Posted on Thu Jan 23, 2020

Io non mi intendo particolarmente di sistemi di sicurezza, in particolare si sicurezza informatica, e ancora piú in particolare di crittografia; di questi tempi, però, è inevitabile farsi un’idea su come gestire la propria sicurezza personale, in particolare la propria sicurezza informatica, e ancora piú in particolare le proprie credenziali di accesso a servizi vari.

Se un ente, pubblico o privato che sia, ci fornisce le credenziali di accesso: significa che esso le possiede; di conseguenza: le persone che gestiscono l’infrastruttura informatica dell’ente ci possono impersonare quando vogliono; la base dati in cui tali credenziali sono immagazzinate, insieme a quelle di tantissimi altri, diventa un bersaglio appetibile per atti di pirateria.

Questo è il caso dello SPID. In sè l’idea di avere credenziali uniche per accedere a piú servizi è buona; il problema è chi crea e conserva la parte privata di queste credenziali.

Un problema analogo esiste con le credenziali di accesso ai servizi di banca telematica: le banche ci forniscono i codici di accesso e ci lasciano scegliere la password (a volte con limitazioni assurde!) che però loro conservano come gli pare.

Ciò che occorrerebbe è un dispositivo che ci permetta di generare e conservare autonomamente credenziali, separate, per ogni servizio a cui vogliamo accedere; la parte privata delle credenziali la conserviamo noi (e solo noi), la parte pubblica delle credenziali la forniamo al fornitore di servizi al momento della registrazione. Tale dispositivo dovrebbe avere caratteristiche davvero particolari:

• nessuna connessione fisica a computer di qualsiasi tipo: un tale collegamento tra circuiti elettrici aprirebbe la porta a violazioni di livello cosí interno che sarebbe impossibile per il titolare anche solo accorgersi che accadono;
• nessun collegamento a reti informatiche aperte: niente Internet;
• solo due modi di connessione: di ricarica elettrica attraverso un circuito che non coinvolga computer; di scambio informazioni con protocolli radio come Bluetooth;
• firmware rigorosamente open source; non aggiornabile ma scaricabile, in modo da permettere un’analisi di ciò che è installato; se il firmware ha degli errori: la rom su cui è memorizzato deve essere sostituita.

Questo dispositivo non può essere lo smartphone (come invece propone Google): personalmente, non lo considero particolarmente sicuro (basti leggere i fatti di cronaca); il produttore di uno smartphone ne controlla il software in tempo reale e quindi ha il potere totale di acquisire qualsiasi forma di credenziale utilizzata (oltre che tutto il resto).

Come si effettuerebbe un accesso allora?

1. Con lo smartphone ci si connette a un servizio telematico che offre autenticazione con protocollo challenge–response.
2. Il fornitore di servizi usa la parte pubblica delle nostre credenziali per generare una challenge.
3. Lo smartphone riceve la challenge e la rende disponibile via Bluetooth.
4. Noi accendiamo il dispositivo di autenticazione e selezioniamo le credenziali adeguate.
5. Il dispositivo di autenticazione riceve la challenge a genera la response usando la parte privata delle credenziali.
6. Il dispositivo trasmette la response allo smartphone.
7. Lo smartphone trasmette la response al fornitore di servizi.

Le solite aggiunte sono possibili: challenge che possano essere usate solo una volta e con durata nel tempo limitata per le sessioni; sblocco dell’autenticazione con impronte digitali o pin; eccetera.

Complicato! Però piú sicuro!

Il dispositivo di autenticazione descritto è simile a ciò che oggi sono le carte di pagamento che eseguono l’autenticazione con la tecnologia contactless, con in piú la possibilità di: creare piú credenziali; scegliere le credenziali che desideriamo; eseguire l’autenticazione solo a comando.