Un’introduzione a Self-Sovereign Identity

In questo articolo, ci dedichiamo alla descrizione delle nozioni fondamentali dietro a Self-Sovereign Identity, un modello di gestione dell’identità digitale in cui gli individui hanno il pieno controllo delle proprie informazioni personali. Parleremo inoltre dei suoi punti di forza rispetto ai precedenti modelli. In futuri articoli sullo stesso tema, ci addentreremo più sugli aspetti tecnici e sulla possibilità di creare un wallet di credenziali personali.

Introduzione alle identità digitali, alle operazioni, ai sistemi che le utilizzano

Una digital identity (identità digitale) può essere descritta come un insieme di attributi che aiutano a descrivere o qualificare un’entità, che si tratti di un essere umano o di un dispositivo elettronico. Alcuni di questi attributi sono chiamati identifier (identificatori) e distinguono il titolare dell’identità all’interno di un contesto specifico. Per esempio, nel mondo fisico, una targa di un’auto o il nostro codice fiscale, possono fungere da identificatori in contesti differenti.

Le identità, fisiche o digitali, nascono per essere soggette a un processo di verifica, diviso in identification e authentication (rispettivamente, identificazione e autenticazione). Il processo di identificazione è l’associazione di un identificatore personale con il titolare dell’identità digitale che lo presenta, ad esempio fornendo un indirizzo email durante un’operazione di iscrizione su un sito Web.

Il processo di autenticazione consiste invece nel verificare l’entità identificata tramite una prova di sicurezza, solitamente mediante una password segreta o una firma digitale. Ad esempio, cliccare su un link ricevuto via email dimostra che l’indirizzo email appartiene al titolare. Queste due operazioni sono fornite dai sistemi di Identity and Access Management (IAM), servizi specializzati di cui si fidano tutte le entità coinvolte (rappresentano quindi un trusted party) [1].

Uno IAM consiste solitamente di tre parti, rappresentate da un end-user (qualsiasi entità che possiede un’identità digitale e desidera svolgere una qualche attività), un identity provider (IdP) e un service provider (SP).

Un IdP genera e gestisce informazioni sull’identità degli utenti-entità da riconoscere (umane, software, hardware, etc), oltre a fornire servizi di autenticazione. Un SP è, con una definizione molto generale, un’organizzazione che offre servizi per i quali gli utenti hanno bisogno di fornire informazioni personali. Per una lunga fase iniziale del Web, erano gli stessi SP che implementavano soluzioni IAM come autorità centralizzate (Figura 1a).

Questo modello presenta alcuni svantaggi per gli utenti, in quanto devono gestire account differenti e mantenere per ciascuno di essi le proprie credenziali di accesso (che spesso coinvolgono password semplici), le impostazioni di sicurezza, e, in generale, tutte le informazioni relative all’account. Questo approccio rende vulnerabili al furto di password attraverso tecniche di phishing, key-logging, e malware in generale.

Per questi motivi, sono stati sviluppati successivamente standard per protocolli di federated identity (identità federata), tra cui Security Assertion Markup Language (SAML) e OpenID/OAuth, consentendo quindi agli utenti di riutilizzare identità già presenti presso vari provider spesso “social”, come Google, LinkedIn, Apple, Amazon, etc. In questo modello, l’utente deve autorizzare/negare l’IdP a condividere specifici attributi personali richiesti dall’SP che l’utente vuole utilizzare.

Questo sistema IAM di terze parti, chiamato IdP “esternalizzato”, migliora il precedente modello centralizzato su alcuni aspetti (Figura 1b): gli utenti devono essere registrati in pochi IdP per poter accedere ai servizi disponibili sul Web. Gli SP devono essere registrati con gli IdP desiderati (o con federazioni di IdP, che collaborano tra loro in modo trasparente per l’utente) per lavorare con utenti identificati e autenticati dagli IdP. Uno dei principali problemi di questo approccio è che negli IdP adesso si concentra una grande quantità di identità digitali, che fanno sì che maggior parte degli attacchi si trasferisca verso gli IdP piuttosto che ai server degli SP, come avveniva invece col modello centralizzato.

Il modello esternalizzato si è sviluppato in modo da porre anche altri svantaggi, come la formazione di oligopoli di IdP tra i quali l’identità dell’utente non è portabile, e la possibilità degli IdP di cancellare arbitrariamente un utente (e la sua identità) dalle proprie piattaforme (in caso l’IdP sia un social network, questo può avvenire anche per una violazione delle sue condizioni di utilizzo).

Figura 1: tre diversi modelli IAM: modello centralizzato, IdP esternalizzato, SSI
Figura 1: tre diversi modelli IAM

Self-Sovereign Identity

Il modello di Self-Sovereign Identity (SSI) elimina la necessità di un fornitore di identità esterno, consentendo all’utente di avere il pieno controllo della propria identità, potendo anche diventare lui stesso un IdP (Figura 1c). Gli utenti possono quindi gestire la propria identità digitale senza affidarsi a piattaforme di terze parti, facendo un passo avanti verso una maggiore privacy e sicurezza e mitigando eventi di data breach/leak [2].

SSI si basa sulla tecnologia blockchain, che fornisce un sistema decentralizzato per l’archiviazione e la verifica delle informazioni relative all’identità, resistente a manomissione. Si noti che la blockchain viene utilizzata “solamente” per memorizzare informazioni che permettono la verifica decentralizzata delle, e non memorizza quindi dati personali che al contrario rimangono all’interno di wallet digitali.

Il concetto centrale di SSI è che gli individui sono sovrani rispetto al proprio “io digitale” e hanno il controllo dei propri dati. In SSI l’identità è sovrana, duratura e portabile per qualsiasi individuo, gruppo o entità che consente l’accesso a tutti i servizi digitali pertinenti utilizzando credenziali verificabili relative all’identità pur mantenendo la privacy. Christopher Allen ha proposto dieci principi fondamentali per SSI [3], che in [4] sono stati raggruppati in tre principali gruppi riguardanti rispettivamente la sicurezza, controllabilità e portabilità dell’identità.

L’ecosistema SSI

Nell’ambito dell’SSI, introduciamo adesso un po’ di terminologia. I claim sono asserzioni fatte da un’entità riguardanti un soggetto. Un insieme di una o più affermazioni fatte da un’entità è una credential (credenziale). Se la credenziale contiene materiale crittografico che ne assicura l’integrità e l’autenticità, viene definita una veriafiable credential (VC). Un’affermazione a prova di manomissione derivata da una credenziale verificabile è chiamata verifiable claim. In SSI, le entità emettono credenziali verificabili verso gli holder (i titolari della credenziale), permettendo poi agli utenti di scegliere quali affermazioni essi vogliono condividere.

Ad esempio, una credenziale può riguardare una certificazione professionale in ambito sicurezza, ed i claim all’interno possono rappresentare la data dell’esame, il punteggio ottenuto, o il periodo di validità della certificazione.

Una verifiable presentation (VP) permette agli utenti di condividere solo le informazioni necessarie (decise dall’holder) provenienti da una o più credenziali, senza dover rivelare tutti i dettagli di una credenziale, permettendone al contempo anche le verifiche di autenticità ed integrità.

Nell’ecosistema SSI sono tre i principali attori: l’issuer crea e rilascia le credenziali ad un holder, l’holder le detiene e presenta al verifier che le richiede, e poi effettua i controlli di verifica. Figura 2 riassume le interazioni tra questi attori.

Self-Sovereign Identity: l’ecosistema SSI
Figura 2: l’ecosistema SSI

In un successivo articolo ci addentreremo nei Decentralized Identifier (DID), degli identificatori creati per essere gestiti in modo decentralizzato, i loro standard principali (W3C) [5] e le principali blockchain utilizzate.

BIBLIOGRAFIA

[1] Frederico Schardong and Ricardo Custódio. Self-sovereign identity: A systematic review, mapping and taxonomy. Sensors, 22(15):5641, 2022. URL https://doi.org/10.3390/s22155641

[2] Perché dovrei preoccuparmi della self-sovereign identity, se sono un’azienda o un cittadino?, di Efrem Zugnaz, 24 Giugno 2020. URL https://www.ictsecuritymagazine.com/articoli/perche-dovrei-preoccuparmi-della-self-sovereign-identity-se-sono-unazienda-o-un-cittadino/

[3] Christopher Allen. The path to self-sovereign identity, 26 Aprile 2016. URL https://www.lifewithalacrity.com/article/the-path-to-self-soverereign-identity/

[4] Andrew Tobin and Drummond Reed. The inevitable rise of self-sovereign identity. The Sovrin Foundation, 29(2016):18, 2016.

[5] Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Recommendation 19 July 2022. URL https://www.w3.org/TR/did-core/

Articolo a cura di Francesco Santini

Profilo Autore

Francesco Santini è Professore Associato presso il Dipartimento di Matematica e Informatica dell’Università degli Studi di Perugia. Si occupa da quasi venti anni di Intelligenza Artificiale e Cybersecurity, con un approccio integrato. È docente di corsi riguardanti la sicurezza per corsi di laurea magistrale in informatica e in master universitari di primo livello su protezione del dato e forensics. È relatore di tesi sulle materie di insegnamento. Organizza il programma di training CyberChallenge.it per studenti di scuole superiori e laurea triennale, ed è membro del Cybersecurity National Lab. presso il nodo di Perugia.

Condividi sui Social Network:

Articoli simili