8. Digital Identity

Questo argomento è stato trattato in blockchains

---

Digital Identity: definizione

Con digital identity si indica la collezione delle informazioni, attributi, e credenziali che rappresentano in maniera univoca un individuo, un’azienda o una qualsiasi altra entità online.

Attualmente, si sta cercando di migrare da un paradigma centralizzato a modelli decentralizzati.

Centralized Identity

Nel caso di una centralized identity (identità centralizzata), ci si espone al rischio di un data breach e singolo point of failure.

Inoltre, l’autenticazione basata su una combinazione di username e password presenta molte vulnerabilità, e viene adottata per un fattore di preferenza dell’utente rivolto alla convenienza piuttosto che della sicurezza.

Il numero delle identità, inoltre, tende a crescere al crescere del numero dei servizi, risultando in una usabilità scarsa.

Richiede inoltre che i service providers conservino e preservino al sicuro i dati degli utenti, pena delle sanzioni.

Federated Identity

Una federated identity (identità federata) coinvolge un gruppo di entità fidate che condividono le responsabilità di autenticazione, permettendo agli utenti di accedere a più servizi con una singola identità.

Tra i vantaggi, ritroviamo che un utente può usare la stessa identità per più servizi e non è più necessario creare account diversi per ogni servizio. Si riduce così il numero di entità centralizzate coinvolte.

Tuttavia, sussistono delle limitazioni:

• si affida a relazioni di fiducia tra diverse parti per autenticare e autorizzare gli utenti;
• gli identity provider (IDP) sanno quando e dove un utente effettua un log in, alimentando preoccupazioni di sicurezza;
• utenti e aziende possono diventare dipendenti da un singolo IDP senza una facile strada per migrare.

Tecnologie abilitanti

Le tecnologie abilitanti che permettono l’implementazione dell’identità federata sono: OAuth, OpenID, FIDO 2.

Queste tecnologie consentono di adottare un paradigma che è più sicuro e che offre controllo più granulare sulle informazioni condivise per accedere a un servizio.

In particolare, le identità federate indicano l’abilità di collegare e usare un’identità elettronica che l’utente possiede, per più sistemi. Un’applicazione non deve necessariamente ottenere credenziali proprie per autenticare l’utente, ma può usare un sistema di gestione dell’identità che ha già l’identità elettronica dell’utente per autenticarlo, finché l’applicazione si fida di quel sistema di gestione dell’identità (identity management system).

OAuth

OAuth permette a un servizio di accedere a dati gestiti da altre applicazioni.

Ai servizi devono essere fornite solo le informazioni necessarie per lo svolgimento dei loro compiti.

Si ottiene un disaccoppiamento tra autenticazione e autorizzazione.

Il flow è il seguente:

1. l’applicazione richiede l’autorizzazione all’utente;
2. l’utente autorizza l’app e invia una prova;
3. l’app presenta la prova di autorizzazione al server per ottenere un token;
4. il token è limitato al solo accesso di ciò che l’utente ha autorizzato.

La terminologia di OAuth descrive:

• resource owner: l’utente che possiede la risorsa (nome, cognome, email…);
• client: l’applicazione che vuole accedere ai dati o svolgere azioni per conto del resource owner;
• authorisation server: l’applicazione presso cui il resource owner ha già un account;
• resource server: l’API o il servizio che il client vuole usare;
• redirect URI: l’URL cui l’authorisation server reindirizzerà il resource owner dopo aver concesso i permessi al client;
• response type: il tipo di informazione che il client si aspetta di ricevere (il più tipico è code, in cui un Authiorization Code è ritornato);
• scope: i permessi granulari richiesti dal client;
• consent: l’authrorization server prende lo scope che il client sta richiedendo e chiede al resource owner di permettere o rifiutare la richiesta;
• client ID: identifica il client con l’authorization serverl
• client secret: una password segreta conosciuta solamente da client e authorization server;
• authorization code: un codice temporaneo che il client invia all’authorization sever in cambio di un access token;
• access token: la chiave usata dal client per comunicare con il resource owner.

OpenID Connec (OIDC)

OpenID connect è un layer che si poggia su OAuth, aggiungendo informazioni di login e profilo sulla persona che è loggata. Un authorization server che supporta OIDC è spesso chiamato Identity Provider. Permette lo scenario per cui un login può essere usato per più applicazioni come Single Sign On (SSO).

OIDC usa, per scope, opeind. Nello scambio finale, il client riceve sia un Access Token che un IDToken.

Fast Identity Online (FIDO)

FIDO agisce come un ponte tra un’identità federata e una identità decentralizzata, permettendo agli utenti di accedere a diversi servizi senza usare la loro combinazione username e password.

Cerimonia di registrazione

La cerimonia di registrazione è il processo con cui un utente registra il proprio autenticatore presso un servizio. Il server invia al browser le informazioni necessarie (rpID, UserID e una challenge). Il browser valida che l’origine corrisponda all’rpID e, se tutto è corretto, trasmette la richiesta all’autenticatore. Quest’ultimo chiede la presenza fisica dell’utente (tramite PIN o biometria), genera una coppia di chiavi, crea un credentialID e firma la risposta con una chiave di attestazione incorporata nel dispositivo. La risposta firmata viene poi restituita al server, che verifica l’origine, la challenge, la firma di attestazione e infine memorizza l’UserID, il credentialID e la chiave pubblica.

Cerimonia di autenticazione

La cerimonia di autenticazione è il processo con cui avviene l’accesso dopo la registrazione. Il server invia al browser l’rpID, il credentialID e una nuova challenge. Il browser valida nuovamente l’origine, poi informa l’autenticatore. L’utente dimostra la propria presenza (PIN o biometria), l’autenticatore recupera la chiave privata associata al credentialID e firma la risposta. Il server riceve la risposta firmata e verifica origine, challenge, credentialID e firma tramite la chiave pubblica già memorizzata: se tutto corrisponde, l’utente è autenticato.​​​​​​​​​​​​​​​​

Attestation Metadata

Fido Alliance Metadata Service (MDS):

• il produttore dell’autenticatore può fornire informazioni sull’autenticatore;
• fornisce caratteristiche e funzionalità di un particolare autenticatore;
• permette decisioni risk-based di essere intraprese da un particolare autenticatore.

Gli autenticatore sono identificati da un AAGUID (Authenticator Attestation GUID). Durante la registrazione, l’autenticatore firma la risposta con una chiave privata contenuta nel dispositivo.

Identificazione dell’utente

La registrazione include il binding di una credenziale FIDO su un certo autenticatore a un utente specifico. Sì può fare con:

• trust on first use;
• invitation;
• identity proofing;
• binding a una credenziale esistente. Più autenticatore possono essere registrati per account con la finalità di recupero.

Self-Sovereign Identity

Electronic Identification, Authentication and Trust Services

Si tratta di un sistema lanciato in Europa per:

• riconoscimento cross-border delle identità elettroniche nazionali dei diversi stati membri;
• stabilisce un framework legale per le firme elettroniche, sigilli, timestamp e certificati;
• facilita la messa in sicurezza delle transazioni online e l’autenticazione dei documenti;
• incentrato primariamente tra interazioni Government-to-citizen (G2C) e Business-to-government (B2G);
• modello centralizzato e federato, poiché eIDAS si affida agli stati membri affinché emettano identità elettroniche, quindi gli utenti non controllano totalmente la loro identità digitale.

eIDAS 2.0

Consiste di un aggiornamento al regolamento originale con lo scopo di espandere l’uso dell’identità digitale, migliorare la privacy e introdurre elementi SSI (Self-Severeign Identity), che sono:

• European Digital Identity Wallet (EUDIW) gestito direttamente dagli utenti;
• se in eIDAS la partecipazione a EUDIW era opzionale, adesso ogni stato deve fornire ai proprio cittadini l’accesso a EUDIW;
• più casi d’uso e interoperabilità;
• garanzie di privacy più forti e maggiore compliance con GDPR.

Concetto di SSI

Il concetto di Self-Sovereign Identity pone l’utente al centro. Infatti, agli individui è permesso il controllo totale sulle proprie informazioni, con il potere di decidere quando, se e come decidono di rilasciare o modificare dati.

Le funzionalità offerte includono:

• controllo e proprietà dell’utente;
• decentralizzazione;
• portabilità e interoperabilità;
• disclosure selettiva e minimale.

Market Drivers

• efficienza per le aziende e esperienza del cliente: SSI permette alle aziende di aumentare la sicurezza, ridurre i costi e migliorare l’esperienza utente, eliminando la gestione tradizionale di identità e accessi;
• resistenza alla surveillance economy: guidato da preoccupazioni per la privaci e regolamenti con GDPR, questo mercato sfida il business model data driven di alcune aziende, promuovendo il controllo dell’utente sui suoi dati personali;
• sovereign individual movement: questo segmento cerca la massima decentralizzazione nell’identità digitale, dando potere agli individui di controllare i propri dati senza affidarsi ad autorità centrali.

Verifiable Credential (VC)

Le verifyiable crediantals rappresentano il cuore di SSI.

Con il termine “credenziale”, possiamo individuare un’insieme di informazioni (tamper resistant, cioè a prova di manomissione) che la stessa autorità afferma di essere vere sul soggetto della credenziale e che consente, a sua volta, di convincere altri (che si fidano dell’autorità) di queste verità.

Struttura di una VC

Una VC è una struttura dati in grado di rappresentare claim e proprietà del possessore di un’identità in una maniera crittograficamente verificabile e tamper-proof. Le credenziali saranno salvate in un wallet personale, tipicamente sul device del possessore dell’identità.

I diversi campi sono:

• @context: definisce un vocabolario usato per la costruzione della VC. Contiene uno o più URI che puntano a specifiche uman-readable o machine-readable. Aiutano il verificatore nell’interpretazione della struttura della VC e della semantica;
• type: elenca gli URI che dichiarano il tipo della VC. Il primo tipo deve essere VerifiableCredential. Consente un rapido controllo della compatibilità tra i verifiers;
• credentialSubject: contiene claims sul soggetto, tra cui il subject ID. Permette la privacy attraverso il supporto a identificatori pseudonimi.

Verifiable Presentation

Una Verifiable Presentation (VP) è una tra le possibilità che un possessore ha per combinare diverse VC da inviare a un verifier ed è simile ad una VC, nel senso che contiene metadati sulla presentazione e una prova firmata dal possessore. I contenuti, tuttavia, sono un insieme di VC anziché essere un insieme di claims.

Digital wallets

Un wallet dovrebbe accettare ogni VC standard. Si possono installare sui dispositivi e, diversamente dai wallet fisici, possono essere tenuti aggiornati e sincronizzati tra diversi dispositivi.

È possibile backuppare e spostare i contenuti di un wallet su un altro wallet, anche di produttori differenti.

Si dovrebbe avere la stessa esperienza di base a prescindere dal wallet, anche se questi provengono da produttori differenti.

Decentralized Identifier

DID è un identificatore digitale formalizzato e standardizzato dal World Wide Web Consortium (W3C).

Un DID identifica in maniera univoca un soggetto DID (non solo un individuo) e include:

• un URI;
• uno specifico identificatore per un metodo DID;
• identificativo method-specific per il DID.

Componenti principali

• namespace: identifica il metodo;
• method specification: è un documento che definisce le regole e le operazioni per i DID che usano quel metodo. Specifica come:
  • creare un nuovo DID;
  • risolvere un DID al DID Document associato (che contiene le chiavi pubbliche e altre informazioni);
  • aggiornare un documento DID;
  • disattivare un DID.

DID Document

Ogni DID si risolve con un documento DID, un file machine-readable in formato JSON-LD che contiene varie informazioni sul soggetto del DID.

Un Documento DID include le chiavi pubbliche, i service endpoints, i parametri di autenticazione, timestamp e altri metadati.

Il processo che porta ad ottenere un documento DID associato a un DID si chiama DID resolution e permette alle applicazioni e servizi DID-enabled di scoprire i metadati machine-readable sul soggetto del DID espressi dal DID document.

Comparazione con certificati X.509

I certificati X.509 posseggono uno formato specifico e il cui contenuto è stato concordato nel corso del tempo. Lega un insieme di dati a una chiave pubblica. I VC possono contenere qualsiasi cosa, da un semplice statement a una struttura complessa, finché lo statement è conforme ad alcuni formati (JSON-LD o JSON-JWT). L”unica cosa che rimane è la condizione che un verifier deve essere in grado di interpretare i contenuti di uno statement.

DID-based architecture

Un’entità può provare la proprietà di un DID sfruttando la chiave privata corrispondente alla chiave pubblica inclusa nel DID Document. Per verificare la prova, il verifier accederà al DID Document condiviso mediante un Verifiable Data Registry (VDR).

Esistono diversi tipi di DID:

• anywise DID: possono essere utilizzati con un numero non specificato di parti, tipicamente sconosciuti. Permettono un uso vasto senza limitare il numero di relazioni che possono essere stabilite;
• pairwise DID: sono conosciuti solo dai loro soggetti e da un’altra parte, come un service provider. I DID pairwise risolvono le preoccupazioni sulla privacy garantendo che ogni relazione ha un unico DID, minimizzando il rischio di correlazione tra diverse interazioni;
• N-wise DID: sono progettati per essere conosciuti strettamente da $n$ parti, includendo il soggetto. Includono i pairwise DID nel caso speciale in cui $n=2$.

Attori principali

• il possessore indica il proprietario dell’identità che controlla una o più VC;
• l’emittente indica una organizzazione fidata che è responsabile della creazione e dell’emissione di VCs;
• il verifier riceve una o più VCs, le verifica e permette l’accesso ai servizi in maniera appropriata.

Verifiable Data Registry (VDR)

I Verifiable Data Registry facilitano la creazione, la gestione e la verifica di identificatori, chiavi, credenziali e schemas.

Lo standard del W3C non fornisce esplicitamente specifiche sull’implementazione dei VDR, ma la maggior parte degli approcci proposti sono basati su DLTs come blockchain.

Selective disclosure

La selective disclosure segue il principio:

nessuna informazione deve essere condivisa oltre ciò che è necessario per eseguire una transazione

Proprietà di privacy e sicurezza della selective disclosure

• minimizzazione: si rivela solo il minimo quantitativo di informazioni, incluso i metadati;
• predicate disclosure: si prova che un claim soddisfi una specifica condizione senza rivelare il valore esatto;
• unlinkability: date due presentazioni dallo stesso utente, il verifier non può determinare se sono state originate dalla stessa credenziale;
• untraceability: issuer e verifier in accordo non possono tracciare la credenziale di un utente nel corso di interazioni multiple;
• unobservability: l’issuer non può determinare quando, dove e quale credenziale è stata presentata;
• non-trasferability: le credenziali non possono essere riusate o delegate ad altre parti;
• unforgeability: un possessore non può creare una credenziale fraudolenta che non è stata legittimamente emessa.

Threat Model

1. Un avversario può condurre vari attacchi, come phishing, malware o furto della chiave per compromettere la chiave privata associata a un DID o per ottenere accesso non autorizzato a credenziali con lo scopo di impersonale il legittimo proprietario dell’identità;
2. un utente malevolo può accordarsi con altri o rubare una credenziale valida da un utente legittimo, presentandola a un verifier e agire in vece del proprietario;
3. un attaccante può provare a ottenere accesso a un servizio creando una copia contraffatta di una VC legittima o presentando una credenziale emessa da un’entità che manca dell’autorità di emettere VCs;
4. sebbene sia sempre verificabile, la validità di una VC può cambiare nel tempo a causa della perdita dei privilegi o della scadenza. Di conseguenza, un verifier deve sempre verificare la validità di una credenziale prima di accettarla;
5. una VP può contenere più claims del necessario per accedere a uno specifico servizio. Di conseguenza, un service provider può acquisire più informazioni del richiesto. Service provider malevoli possono sfruttare i dati personali per guadagno personale mediante la profilazione, mentre i service provider onesti possono involontariamente innalzare i rischi legasti alla perdita della privacy;
6. tecniche di selective disclosure possono sempre permettere ai service provider di collegare claims allo stesso individuo nel orso più presentazioni, o accordarsi con altri providers per farlo;
7. un avversario può intercettare una VP e riusarla con un diverso verifier, impersonando il legittimo proprietario ottenendo accesso non autorizzato.

Selective Disclosure for JWT

Selective Disclosure per JWT (SD-JWT) è un meccanismo che permette a un utente di rivelare selettivamente i contenuti di un JWT (JSON web token) a un service provider.

Selective Disclosure via Mono-claim Credentials

Si può dividere una credenziale multi claim in un sottoinsieme di credenziali mono-claim.

Con questo approccio, tuttavia, la dimensione della credenziale cresce linearmente con il numero di claim, aumentando lo storage richiesto all’utente e i requisiti di rete. SD-JWT rivela il numero esatto di claim inclusi, cosa che può potenzialmente esporre l’identità del possessore ad attacchi di inferenza.

Compact e Selective Disclosure for VCs

Si cerca di superare il limite di SD-JWT con il metodo Compact and Selective Disclosure for VCs (CSD-JWT). Tutti i claim sono accumulati in un unico valore e, per ogni claim, si genera una prova di inclusione.

CSD-JWT riduce notevolmente l’overhead di storage e rete, rendendosi la soluzione ideale per ambienti limitati come IoT.

In questo contesto, si considera lo stesso threat model di SD-JWT, che non è resiliente contro unlinkability e accordi malevoli issuer-verifiers (le informazioni sono statiche). Tuttavia:

• storage: CSD-JWT usa un accumulatore basato su ECC, che richiede 256 bit per l’accumulatore e 256 bit per ogni prova. SD-JWT richiede 256 bit per ogni hash e 128 bit per ogni salt, e dunque si ottiene una riduzione nello storage;
• computation: l’overhead dell’accumulatore è spostato sull’issuer. Il possessore deve svolgere le stesse operazioni (es. firma digitale).

Selective Disclosure via Merkle Tree

Ogni foglia rappresenta un claim nella credenziale.

Selective Disclosure via BBS+

Le firme BBS+ permettono a un possessore di VC di derivare prove dalla firma originale.

Selective disclosure predicates

I verifier possono controllare un valore contro una certa condizione limitando il quantitativo di informazioni rivelate (es. età controllata come età maggiore di 18 anni). Le predicate policies sono impostate dal verifier che le usa per verificare o autenticare i suoi utenti. I verifier possono anche creare predicate policies e condizioni, come creazioni di range o la richiesta di partecipazione a un certo insieme.

Gli utenti rispondo a queste policy con valori vero/falso anziché la rivelazione del valore del claim. Viene realizzato con tipi di firme che permettono la realizzazione di claim come predicati.

Compliance GPDR

• diritto di essere informato (right to be informed): la condivisione dei dati è totalmente sotto il controllo dell’utente che decide quando e con chi condividere le proprie credenziali;
• diritto alla rettifica (right to rectification): il proprietario dell’identità può richiedere l’emissione di una credenziale con le informazioni aggiornate;
• diritto all’oblio (right to be forgotten): l’utente può revocare una VC rendendola inusabile. Inoltre, l’uso della selective disclosure minimizza il quantitativo di informazioni condivise.

European Blockchain Services Infrastructure (EBSI)

L’European Blockchain Services Infrastructure consiste di una rete peer-to-peer di noti interconnessi che eseguono un’infrastruttura per servizi basata su blockchain.

Ogni membro dell’European Blockchain Partnership (EBP) (i 27 stati membri, più Norvegia, Liechtenstein e la Commissione Europea) eseguono almeno un nodo. L’infrastruttura è composta da diversi layer, inclusi:

• un layer di base con l’infrastruttura di base, connettività, la blockchain e lo storage necessario;
• un layer service core che permette tutti gli use case e le applicazioni basati su EBSI;
• layer aggiuntivi dedicati a use case e applicazioni specifici.

Su questa blockchain non si possono deployare smart contract custom essendo una rete permissioned e government-backed, ma supporta comunque gli smart contract solo per use cases specifici:

• emissione di VC e verifica;
• diploma certification;
• cross-border business registration.

Revoca delle credenziali

Revoca delle credenziali: definizione

La revoca è il processo con cui si invalida una VC precedentemente emessa, garantendo che non possa più essere usata e che non vi ci possa più fidare.

Il meccanismo impedisce l’uso scorretto di credenziali compromesse o obsolete, garantisce la fiducia e l’integrità nei sistemi di identità decentralizzate e supporta la gestione del ciclo di vita dinamico delle credenziali. Si possono adottare i meccanismo impiegati per i certificati X.509.

W3C fornisce solo una specifica: Revocation List 2020. Consiste nell’includere un indice in ogni credenziale, che fa riferimento alla posizione della credenziale stessa in una bitstring, utilizzata per la verifica della validità della credenziale.

EVOKE: Efficient Revocation of Verifiable Credentials in IoT Networks

Nelle reti IoT, le Verifiable Credentials (VC) possono dover essere revocate nel tempo (per scadenza, perdita di privilegi, ecc.). Il meccanismo standard W3C, la Revocation List 2020, usa una bitstring compressa: ogni credenziale ha un indice in questa lista, e il verifier controlla se quel bit è attivo o meno. Questo approccio però non è adatto all’IoT perché richiede connettività costante al server dell’issuer per scaricare la lista aggiornata, e i dispositivi IoT sono spesso vincolati in termini di memoria, calcolo e connettività.

EVOKE si basa su un accumulatore crittografico basato su ECC (Elliptic Curve Cryptography).

Fase di Emissione

L’issuer accumula tutte le credenziali attive in un unico valore chiamato accumulator value, di dimensione costante (256 bit).

Per ogni credenziale viene generato un witness, ovvero una prova crittografica che quella specifica credenziale è inclusa nell’accumulatore.

Ogni dispositivo IoT memorizza solo 1.5 KB: il valore dell’accumulatore e il proprio witness.

Fase di Verifica

Il verifier riceve la VC insieme al witness e combina il witness con l’accumulator value per verificare crittograficamente se la credenziale è ancora valida, senza dover contattare nessun server esterno.

Revoca

Quando una o più credenziali vengono revocate: ∙ L’issuer aggiorna l’accumulator value rimuovendo le credenziali revocate ∙ Ricalcola i witness per tutte le credenziali ancora valide ∙ Pubblica il nuovo accumulator value e i witness aggiornati sulla blockchain (VDR)

I dispositivi che non hanno ancora ricevuto l’aggiornamento risulteranno con un witness outdated, e quindi non potranno autenticarsi correttamente finché non si aggiornano.

Aggiornamenti Offline

Un aspetto innovativo di EVOKE è la gestione degli aggiornamenti in reti IoT dove i dispositivi possono essere temporaneamente offline. Sono previste due modalità:

• Direct Retrieval: il dispositivo recupera direttamente il nuovo witness dalla blockchain o dal server dell’issuer non appena torna online;
• Indirect Retrieval: il dispositivo ottiene l’aggiornamento tramite un altro dispositivo già aggiornato nella rete mesh, senza dover contattare direttamente la sorgente.