Internet computer wiki

Panoramica tecnica su Internet Identity

Panoramica tecnica su Internet Identity

Registrazione

Quando si registra una nuova identity anchor, il browser dell’utente genera innanzitutto una nuova coppia di chiavi per la sessione in corso. Una volta che l’utente attiva il proprio dispositivo, genera una nuova coppia di chiavi che fungerà da coppia di chiavi master per questa identity anchor. Il dispositivo protetto firma quindi una delega dalla chiave pubblica master master_pk alla chiave pubblica di sessione session_pk, in modo che il browser possa firmare un messaggio di ingresso di registrazione in session_pk utilizzando una firma delegata sotto il principal SHA224(master_pk) · 0x02.

Si noti che la chiave segreta corrispondente a master_pk non lascia mai il dispositivo, mentre la chiave segreta corrispondente a session_pk viene conservata nella memoria del browser in cui la politica di stessa origine protegge dall’accesso da parte di altri canister oltre al canister II.

Il canister II crea un nuovo anchor II e collega il principal all’identity anchor. Quando l’utente aggiunge un nuovo dispositivo all’anchor, il canister II aggiunge all’anchor i principal derivati dalla chiave pubblica master del nuovo dispositivo.
Tutte le operazioni successive per questo identity anchor devono essere autenticate in uno dei principal associati all’anchor. Il browser dell’utente utilizzerà una coppia di chiavi di sessione esistente se la memoria del browser per l’origine del canister II ne contiene una con una delega valida, o ne crea una nuova ripetendo la procedura precedente.

Si noti che II non utilizza l’archiviazione locale per II – per questo l’utente deve sempre utilizzare il sensore biometrico /toccare la Yubikey.

Una volta che l’utente chiude la scheda, la delega è sparita.

Autenticazione

Il caricamento di una singola pagina può includere più richieste e risposte firmate.
Per evitare che un utente debba attivare il proprio token di sicurezza per ogni singolo messaggio, il browser dell’utente genererà una coppia di chiavi di sessione per ogni canister di riferimento e farà certificare la chiave pubblica per la sessione dal canister II.

Nello specifico, quando l’utente visita un canister di riferimento e fa clic per accedere con Internet Identity, il browser dell’utente genera una nuova coppia di chiavi di sessione e la memorizza nella memoria del browser per il canister di riferimento; ci riferiamo alla chiave pubblica come rel_session_pk.

Il browser viene quindi reindirizzato al canister II, e passa rel_session_pk codificandolo come parte dell’URL.

Il browser firma un messaggio di ingresso per accedere al canister II utilizzando la procedura di autenticazione sopra, ovvero riutilizzando una chiave di sessione valida per il canister II, se esistente, o creandone una nuova in caso contrario.

Quando l’utente fa clic per accettare l’autenticazione al canister di riferimento, il browser crea un secondo messaggio di ingresso al canister II (anch’esso firmato con la chiave pubblica della sessione) che contiene l’identità del canister di base e la chiave pubblica della sessione di riferimento rel_session_pk

Il canister II calcola un principal auto-autenticante univoco per l’anchor di questo utente e questo canister di riferimento come

SHA224(|id_provider| · id_provider · seed) · 02

dove la seed viene calcolata in base a una salt segreta detenuta dal canister II, dall’identity anchor dell’utente e dal canister di riferimento come

SHA256(|salt| · salt · |anchor| · anchor · |rel_canister_id| · rel_canister_id)

dove anchor è l’identity anchor dell’utente, rel_canister_id è il principal del canister di riferimento e seed è una seed segreta detenuta dal canister II.

La salt è stata scelta casualmente quando il canister II è stato inizializzato e viene conservato nello stato del canister II.

Ciò offre una certa privacy contro i canister che tentano di tenere traccia degli utenti collegando principal che appartengono alla stessa identity anchor. In ogni caso la privacy non viene garantita di fronte ad un’ente che conosce la seed segreta, ad esempio, un provider di nodi che partecipa alla subnet del canister II. Si noti che ciò influisce solo sulla privacy, non sulla sicurezza: la conoscenza della seed non consente all’ente di impersonare alcun utente.

Nella sua risposta, il canister II include il nonce e una variabile certificata (nota anche come firma del canister) che collega l’ID del canister di riferimento a rel_session_pk e un tempo di scadenza. Il browser dell’utente viene quindi reindirizzato al canister di riferimento, dove firma i messaggi di ingresso sotto rel_session_pk.

Esperienza dell'utente

Internet Identity non utilizza password e nomi utente per accedere.

Internet Identity sfrutta l’API Web Authentication (WebAuthn) per fornire un’autenticazione crittografica sicura. Ciò significa che un utente si autentica con “qualcosa che ha” (ad esempio un telefono, yubikey, ecc…) piuttosto che “qualcosa che conosce” (ad esempio una password). Dal punto di vista dell’utente, verrebbero utilizzati i seguenti metodi per autenticarsi:

Computer
– Hardware wallet Yubikey o Ledger (con computer con porte USB)
– Impronta digitale o riconoscimento facciale (con computer con funzioni di riconoscimento elettronico delle impronte digitali come https://en.wikipedia.org/wiki/Touch_ID o https:// en.wikipedia.org/wiki/Features_new_to_Windows_10#Windows_Hello)

Smartphones
– Face ID (per smartphone con sistemi di riconoscimento facciale)
– Impronta digitale (per smartphone con funzioni di riconoscimento elettronico delle impronte digitali come https://en.wikipedia.org/wiki/Touch_ID)

Concetti Chiave

Anchor
Un’anchor è un numero associato all’identità di un utente. Questo numero è generato automaticamente dal sistema e ce n’è solo uno per identità.
Esempio: 193431

Dispositivi
Gli utenti possono aggiungere molti dispositivi allo stesso identity anchor. Un esempio comune è che gli utenti possono aggiungere il proprio smartphone e computer desktop a un identity anchor. Si consiglia di aggiungere più dispositivi nel caso in cui gli utenti perdano l’accesso ad uno di essi. I nomi dei dispositivi sono scelti dall’utente e ce ne possono essere molti per identità.
Esempio:
“Macbook Pro Alice”
“iPhone Alice”

Meccanismi di recupero

Oltre ad aggiungere più dispositivi e utilizzare chiavi di sicurezza, un utente può configurare il recupero dell’account al prompt facendo clic su Aggiungi un meccanismo di ripristino a un Identity anchor.

Seed Phrase

Un utente può selezionare questa opzione per generare una frase di recupero crittograficamente sicura che può utilizzare per recuperare un identity anchor. È importante che l’utente si assicuri che questa frase sia memorizzata in un luogo sicuro e sia nota solo all’utente, poiché chiunque conosca la seed phrase sarà in grado di assumere il pieno controllo di questo Identity Anchor. Si noti che la prima stringa nella frase di inizializzazione di un utente è l’identity anchor. Questo numero per iniziare il processo di recupero.

L’utente deve fare clic sul pulsante copia e quindi continua o la seed phrase non verrà registrata.

Chiave di sicurezza

Una chiave di sicurezza dedicata può essere utilizzata per recuperare un Identity Anchor nel caso in cui un utente perda l’accesso ai propri dispositivi autorizzati. Questa chiave deve essere diversa da quelle utilizzate attivamente dall’utente per eseguire l’autenticazione all’Internet Identity utilizzando l’identity anchor specificato. Questa chiave deve essere conservata in un luogo sicuro e assicurarsi che sia disponibile solo per l’utente. Come sopra, chiunque sia in possesso di questa chiave di sicurezza sarà in grado di assumere il pieno controllo dell’Identity Anchor dell’utente. Un utente dovrà conoscere l’identity anchor per iniziare il ripristino.

Sicurezza

Internet Identity è un canister in esecuzione sulla rete NNS, quindi gli sviluppatori possono verificare che stia eseguendo il codice che afferma di eseguire. Per verificare il codice, vedi https://medium.com/dfinity/internet-identity-the-end-of-usernames-and-passwords-ff45e4861bf7.

Supporto

Per visualizzare il supporto corrente di WebAuthn, vedi https://caniuse.com/?search=webauthn.

Vedi anche