KeyMeld: chiave comune per iPhone e Android e architettura Zero Vault per il progetto

Le applicazioni cross-platform hanno un problema che l'utente di solito non nota. Alla schermata vede un singolo account e si aspetta un funzionamento uniforme su qualsiasi dispositivo. Tuttavia, iPhone e Android utilizzano meccanismi di protezione diversi e gestiscono le chiavi locali in modo differente.

Sull'iPhone, l'app può proteggere la chiave locale del dispositivo mediante Apple Keychain. Su Android, si utilizza Android Keystore. Queste tecnologie sono progettate per mantenere le chiavi sensibili in un ambiente protetto del dispositivo, ma non sono intercambiabili.

Per l'utente, questo non ha importanza. Vuole semplicemente aprire l'app sul iPhone, poi installarla su Android e continuare a lavorare con gli stessi dati protetti.

Per lo sviluppatore, sorge una domanda architetturale: come organizzare un accesso condiviso su due piattaforme, senza trasferire le chiavi locali dei dispositivi e senza accumulare copie nel database del proprio backend?

Nel comprendere KeyMeld, ho visto che il servizio offre una chiave universale separata, senza intervenire nelle protezioni interne di iOS e Android.

Chiave comune per piattaforme diverse

La chiave locale del dispositivo è associata a un telefono specifico e protetta dagli strumenti del sistema operativo corrispondente. Rimane in un ambiente protetto del dispositivo e non è destinata ad essere trasferita liberamente tra dispositivi.

La chiave universale di KeyMeld è un'entità diversa. Viene creata per un progetto specifico, un account e uno spazio protetto, diventando comune per i clienti autorizzati su diverse piattaforme.

Il servizio non prende la chiave dall'iPhone, non la trasferisce su Android e non tenta di trasformare due chiavi differenti in una sola. La protezione tra piattaforme rimane autonoma, mentre l'app ottiene un livello di accesso comune per il suo progetto.

Questo definisce il ruolo architetturale di KeyMeld. Non rende iOS e Android uguali e non sostituisce i loro meccanismi interni. Aggiunge invece un livello comune di gestione con una chiave universale, evitando che il progetto debba gestire autonomamente l'emissione interpiattaforma.

Per diversi prodotti e account si creano percorsi di chiavi indipendenti. Ogni progetto mantiene quindi la propria area di accesso, e più account sullo stesso dispositivo rimangono separati.

Zero Vault appartiene al progetto

È importante chiarire subito: Zero Vault non è il nome stesso di KeyMeld. È un modello architetturale che può essere implementato da un prodotto collegato.

KeyMeld funziona come un servizio SaaS separato. Non si installa all’interno del backend dell’app e non si colloca accanto al database del progetto come un altro modulo software. La chiave universale viene gestita in un'istanza SaaS separata di KeyMeld, fuori dal backend del prodotto stesso.

Per mantenere tale modello, i confini di fiducia tra il progetto e KeyMeld devono rimanere indipendenti. Il backend dell'app e il servizio esterno usano credenziali, diritti di accesso e meccanismi di amministrazione separati.

Questo risultato architetturale si può definire come modello Zero Vault: il suo database server non memorizza la chiave dell'hardware protetto del cliente.

Zero Vault non significa che il backend del prodotto non memorizzi affatto nulla. Rimangono gli account, le configurazioni, i dati di business e tutto ciò necessario per far funzionare l'app. Tuttavia, non si conserva una chiave universale tra questi.

Una compromissione del database server del prodotto non rivela automaticamente la chiave universale: essa infatti non viene memorizzata insieme agli account o ad altri dati server. Tuttavia, tale modello non promette che qualsiasi fallimento nella infrastruttura diventi automaticamente innocuo. Risolve una questione precisa: eliminare la chiave universale dall'hardware client e dal database del prodotto stesso.

Scenario pratico: un account su iPhone e Android

Immaginiamo un'app con dati protetti localmente. Può trattarsi di un autenticatore, cliente aziendale o qualsiasi servizio che richiede di lavorare direttamente con informazioni criptate sul dispositivo.

Sull'iPhone, l'app utilizza iOS per proteggere la chiave locale. Su Android, si utilizza il meccanismo di protezione Android. Le chiavi interne dei dispositivi sono diverse, ed è normale.

Senza un livello comune separato, lo sviluppatore avrebbe dovuto risolvere come organizzare l'accesso agli stessi dati protetti su due piattaforme. L'archiviazione a livello di piattaforma sarebbe rimasta diversa, e il prodotto avrebbe dovuto collegare queste due implementazioni da sé.

Si sarebbe potuto creare schemi separati per iOS e Android, tentare di trasferire manualmente le chiavi locali o di conservarne copie sul server.

KeyMeld permette di abbandonare il trasferimento delle chiavi locali e la loro memorizzazione in copie server, aggiungendo invece una chiave universale comune.

I clienti su iPhone e Android ottengono accesso alla stessa chiave universale all’interno di un progetto e account autorizzati. Ogni dispositivo mantiene comunque i propri strumenti di protezione.

Per l'utente, tutto questo appare come un account unico su più dispositivi. Non è necessario conoscere i meccanismi interni di iPhone o Android.

Chiamando in causa, non è richiesto esportare la chiave locale dal vecchio dispositivo o creare una versione protetta separata per la nuova piattaforma. Il nuovo cliente si collega allo stesso progetto e ottiene accesso alla stessa chiave universale.

Il backend partecipa all’autenticazione della richiesta, ma la chiave universale è destinata al cliente autorizzato e non viene memorizzata nel database del prodotto.

Lo stesso KeyMeld non trasferisce il database dell’app o sostituisce il sistema di sincronizzazione delle registrazioni utente. La sua funzione specifica è fornire al cliente la chiave necessaria per lavorare con i dati protetti. Il contenuto dell’archivio e il suo aggiornamento rimangono a carico del prodotto stesso.

Tre tipi di chiavi e segreti diversi

Per evitare confusione tra le varie parti dell’architettura, è sufficiente distinguere tre concetti.

• Chiave locale del dispositivo appartiene a un telefono specifico ed è gestita da iOS o Android.

• Chiave universale viene usata da clienti autorizzati di un progetto e account. È questa che collega le piattaforme a livello del prodotto stesso.

• Segreto di servizio è necessario al backend per interagire in modo protetto con KeyMeld. Non viene trasmesso all’app mobile o browser.

Secreto di servizio e chiave universale hanno scopi diversi. Nell'architettura Zero Vault, la chiave universale non viene memorizzata nel database del prodotto accanto ai dati del backend.

Per funzionare, KeyMeld non richiede il nome dell’utente, la sua password, contenuti di TOTP o il senso commerciale delle registrazioni. Al servizio interessa collegare il progetto, l'account e il diritto del cliente di ottenere la chiave universale.

Accesso alla chiave sotto controllo

Il ricevimento della chiave universale non è un diritto automatico di ogni cliente.

Se un dispositivo non può più essere considerato affidabile, cambia lo status dell'account o il team revoca l’accesso al progetto, KeyMeld può cessare di fornire la chiave universale a quel cliente.

È importante non estrapolare conclusioni troppo ampie. Non significa che la copia locale esistente venga automaticamente eliminata. Si tratta di controllare ulteriormente l’accesso alla chiave e l’aggiunta di nuovi clienti.

Per l'utente, questo significa che l'aggiunta di nuovi dispositivi e la gestione del loro accesso futuro alla chiave sono sotto controllo di uno stesso sistema.

Per lo sviluppatore, significa che non deve costruire autonomamente questa logica separatamente per iOS e Android. Tuttavia, il modello Zero Vault finale dipende ancora dal fatto che il progetto memorizzi o meno la chiave universale e se mantenga la separazione tra infrastruttura propria e l’istanza SaaS esterna di KeyMeld.

Ciò che KeyMeld non fa

KeyMeld non è un gestore di password e non memorizza le registrazioni TOTP degli utenti. Non diventa un database cloud dell’app e non sostituisce la sincronizzazione dei contenuti.

Non sostituisce Apple Keychain o Android Keystore. Il servizio lascia in loco i meccanismi di protezione delle piattaforme e aggiunge un livello comune per il prodotto.

Non è nemmeno un servizio obbligatorio di identificazione dell’utente. La verifica e l’autenticazione possono essere affidate a un servizio separato, come MeldID, mentre KeyMeld si limita a fornire una chiave universale autorizzata, senza inserirla nel backend dell’app stessa.

Infine, KeyMeld non rende Zero Vault automatico. Fornisce al progetto un’istanza esterna di chiave universale. Per mantenere questa architettura, lo sviluppatore non deve collocare la chiave universale nel proprio database. Anche le zone di fiducia indipendenti devono rimanere separate.

A chi può interessare

Questo approccio è interessante per applicazioni che funzionano su più piattaforme e usano dati protetti localmente.

Possono essere autenticatori, applicazioni aziendali, prodotti SaaS, servizi multi-dispositivo o qualsiasi progetto dove un account debba funzionare ugualmente su iPhone e Android.

Per lo sviluppatore, il valore non sta solo nel ridurre la logica cross-platform. Più importante è dividere le responsabilità: il backend del prodotto gestisce i propri dati, mentre un servizio SaaS esterno come KeyMeld fornisce la chiave universale e controlla la sua distribuzione futura.

Dopo aver studiato il progetto, descriverei KeyMeld non come un Zero Vault completo, ma come uno strumento tramite il quale lo sviluppatore può costruire questo modello per il proprio prodotto.

iOS e Android continuano a usare i propri meccanismi di protezione. I clienti ottengono una chiave universale comune. Il backend del prodotto, se non conserva questa chiave e mantiene la separazione tra l’infrastruttura propria e l’istanza SaaS di KeyMeld, non diventa un caveau con la chiave delle risorse client.

Per l'utente, ciò significa accesso unico su più piattaforme. Per lo sviluppatore, la possibilità di spostare la chiave universale fuori dal proprio backend. E, per il progetto nel suo complesso, un'architettura Zero Vault in cui il server dell'app non memorizza la chiave dell’hardware protetto del cliente.

Maggiore approfondimento sul progetto: KeyMeld