Lo sforzo per aumentare la sicurezza ed eliminare le frodi attraverso una autenticazione utente più robusta, meno ottusa e con maggior difficoltà di implementazione non ci ha comunque consentito di essere più sicuri, in compenso siamo riusciti ad irritare sempre di più gli utenti. In realtà la soluzione c’è e si chiama “associazione”.

I problemi dell’autenticazione

L’attenzione per la sicurezza degli utenti negli ultimi 20 anni è stata quella di proporre nuove forme di:

Conoscenza: Qualcosa di utente sa (password)
Possesso: Qualcosa di utente ha (token)
Inerenza: Qualcosa che un utente è (biometrica)

Tuttavia, ci sono grossi problemi con questo approccio: in particolare, ogni nuovo servizio riparte ogni volta da “zero” come se questo utente non fosse mai stato online prima. Vale a dire, l’applicazione del modello B2C (Business-to-consumer) tenta di creare ogni volta una nuova identità, eventualmente con un minimo di un OAUTH (token federato) per la fiducia.

Questo processo di creazione di nuove identità per ogni app non solo è costoso per l’azienda ma anche un deterrente dispendioso in termini di tempo per gli utenti e non abbiamo nemmeno iniziato a parlare degli eventuali problemi di autenticazione. L’autenticazione standard infatti è comunque potenzialmente suscettibile a furti o clonazione di credenziali, siano essi password, token o dati biometrici.

L’ultima pecca della storia dell’autenticazione standard – che è il difetto più inaccettabile in un mondo interconnesso come quello odierno – è che si tratta di un processo “statico“.

Spieghiamoci meglio: l’autenticazione è un sì / no binario (di solito basato su informazioni statiche che l’azienda/il provider detiene), il che non lascia spazio per la conferma e lo stato dell’identità (rubato, abusato – chi lo sa?). Infine, non c’è spazio per un sistema di attendibilità dell’identificazione … siamo sicuri al 100% dell’utente, o solo al 75% o al 30%? (Non dovremmo modificare le informazioni / risorse offerte a questo utente se siamo sicuri solo al 50% che è effettivamente chi dice di essere?)
La soluzione è: Autenticazione per associazione o comunitaria

Identità

Una cosa certa riguardo alla modena gestione dell’identità è che l’IDENTITÀ esiste già, è solo una questione di:

• Scegliere di quale IDENTITÀ fidarsi
• Stabilire una nuova relazione di trust o fiducia
• Determinare un LIVELLO di fiducia basato sulle informazioni attuali disponibili
• Alimentare globalmente (di nuovo) il modello di fiducia

Di seguito analizziamo alcuni esempi di applicazione di questa nuova concezione di fiducia:

Keybase.io (Utilizzo dei social media per associare le chiavi di crittografia – https://keybase.io/
SecureKey Concierge (Sfrutta gli ID fidati esistenti per gli account di tipo governativo) https://securekeyconcierge.com/
Civic.com (Blockchain identity weighting system) – https://www.civic.com/
dock.io ( Utilizzo della blockchain sul proprio curriculum vitae) – https://www.dock.io/

Keybase.io

Keybase è una nuova e gratuita app di sicurezza per smartphone e computer. È uno strumento user-friendly molto interessante che consente agli utenti di creare e utilizzare chiavi di crittografia nella comunicazione comune (e-mail, messaggistica, ecc.).

La soluzione NON offre alcuna nuova tecnologia. Supporta chiavi di crittografia PGP e GPG. La novità è la facilità di utilizzo di associare un’identità sociale esistente con un potente meccanismo di sicurezza: chiavi private e pubbliche.

Ti consente di non associare la tua IDENTITÀ al sistema di crittografia, ma anche di vedere l’associazione degli altri sulla rete:

La principale “novità” del sistema keybase.io è l’associazione delle chiavi di sicurezza con un’identità esistente. Inoltre, consente al mittente di prendere una decisione autonoma sul suo livello di fiducia dell’utente, in base alle “associazioni” che questo utente ha con più di un account social.

Sì, è un processo manuale di fiducia, ma keybase.io è un ottimo esercizio per aiutare a iniziare a capire in che modo la fiducia sociale dovrebbe e potrebbe essere stabilita.

SecureKey Concierge

SecureKey Concierge dà una prospettiva interessante al problema dell’identità B2C.
Il primo problema che hanno risolto è stato come fornire identità attendibili (non standard OAUTH / Facebook) a una risorsa sicura.
Le loro prime app di destinazione erano le risorse del governo canadese (federale e provinciale).

Il governo aveva precedentemente fatto in modo che gli utenti creassero i propri account e passassero attraverso un assurdo processo di conferma (Canadian Post e altri metodi complicati).
Inoltre, poiché questi conti governativi venivano spesso utilizzati solo una volta all’anno – durante il periodo fiscale – il numero di reimpostazioni della password e di account bloccati era notevole.

SecureKey Concierge ha proposto un approccio unico: perché i siti governativi non hanno fiducia negli account che hanno già una buona sicurezza e un livello di trust incorporato e sono utilizzati quasi quotidianamente dagli utenti? Vale a dire, il conto bancario online dell’utente.

Quindi SecureKey Concierge ha creato una partnership con 11 istituzioni finanziarie canadesi, tra cui RBC, CBC Scotiabank e altre. Inoltre, hanno creato un sistema che consentiva agli account governativi di accettare un accesso da questi account.

Questa è stata una grande vittoria per tutti i soggetti coinvolti:

Per i governi coinvolti: significa 7.000.000 di utenti già creati e pronti ad una relazione di trust
Per gli utenti: una sola identità online da gestire
E per le banche: aumentata la fidelizzazione e l’utilizzo degli strumenti da parte dei clienti

Il programma non è passato inosservato nel mondo dell’identità. IBM ha stretto una partnership con SecureKey per creare un sistema di fiducia finanziaria B2C sfruttando lo stimato sistema Hyperchager Blockchain di IBM.
L’impegno è di creare un sistema di fiducia decentralizzato (blockchain) che vada ben oltre gli utenti bancari e le entità governative canadesi.

Civic

Un altro esempio è la soluzione blockchain Civic. Civic è un approccio molto innovativo all’identità, la sua archiviazione, la dispersione e la fiducia riposta.

Civic consente all’utente, tramite un’app mobile, di memorizzare le proprie informazioni di identità personale (Personal Identity Information) su un dispositivo mobile. L’azienda può richiedere le informazioni tramite una richiesta al sistema Civic. L’utente riceve una richiesta per dati di tipo personale o di tipo medico (PHI – Protected Health Information) e quindi decide se rialsciare i dati dell’azienda richiedente.

Sistema piuttosto ordinato – Suona un po’ come lo SPID nostrano ma aspettate, c’è di più!

A questo punto l’azienda richiedente sa che può fidarsi delle informazioni di questo utente dato che il suo “trust score” è validato sulla blockchain. Cioè, un operatore sanitario sa che può fidarsi dei dati medici protetti (PHI) dell’utente, perché anche la compagnia di assicurazione di questo utente si fida di questo “link” per i dati, così come il provider di telefonia mobile della persona, così come la regione, lo stato e il paese in cui vivono.
I dati sono attendibili e verificati – non perché l’utente dice “fidati di me” – ma è l’AGGREGATO del trust di altri provider archiviati nella blockchain da parte di Civic.

Dock.io

L’ultimio esempio è dock.io, una piattaforma decentralizzata che nasce per valorizzare il grande volume di dati che abbiamo in singoli punti. Immaginiamo utenti con intere carriere, raccomandazioni, prove di competenza o reti profesionali costruite su LinkedIN o altre piattaforme simili che devono sottostare al volere delle stesse, accettando di volta in volta le regole che vengono imposte unilaterlmente. Poter centralizzare tutte queste informazioni ,normalmente sparse su network proprietari e ritornare in possesso dei propri dati è la missione di Dock.io. Dock.io si basa sulla blockchian (precisamente si basa su ethereum e c’è anche una cryptovaluta connessa) e consente di distribuire i dati in modo distribuito ma in un’unica piattaforma. Ebbene, anche in questo caso il processo di validazione si basa su verifiche su altri provider già trustati (inoltre c’è già il supporto ad una autenticazione a due fattori).

 

Conclusioni

Il mondo cambia e abbiamo visto come già molte applicazioni siano in grado di ragionare con un nuovo modello di trust. Perlomeno nelle applicazioni di tipo B2C. E per gli utenti aziendali ? Beh di questo scriveremo in un altro articolo 😉