KeyMeld: Cheie comună pentru iPhone și Android și arhitectura Zero Vault pentru proiect

Aplicațiile cross-platform au o problemă pe care utilizatorul de obicei nu o observă. Pe ecran vede un singur cont și se așteaptă ca funcționalitatea să fie identică pe orice dispozitiv. Însă, în interior, iPhone și Android folosesc mecanisme diferite de protecție și gestionează cheile locale în mod diferit.

Pe iPhone, aplicația poate proteja cheia locală a dispozitivului folosind Apple Keychain. Pe Android, se utilizează Android Keystore. Aceste tehnologii sunt menite să păstreze cheile sensibile în mediul protejat al dispozitivului, dar nu sunt interschimbabile.

Pentru utilizator, acest lucru nu are importanță. El doar vrea să deschidă aplicația pe iPhone, apoi să o instaleze pe Android și să continue să lucreze cu aceleași date protejate.

Pentru dezvoltator, apare întrebarea arhitecturală: cum să organizezi accesul comun pe cele două platforme, fără a transfera cheile locale ale dispozitivelor și fără a păstra copii ale acestor chei în baza de date a propriului backend?

Analizând KeyMeld, am observat că serviciul oferă pentru această situație o cheie universală separată, fără a interveni în mecanismele de protecție internă ale iOS și Android.

Cheie universală pentru diferite platforme

Cheia locală a dispozitivului aparține unui anumit telefon și este protejată de mecanismele sistemului de operare corespunzător. Ea rămâne în mediul sigur al dispozitivului și nu este destinată transferului liber între dispozitive.

Cheia universală KeyMeld este o entitate diferită. Ea este creată pentru un anumit proiect, cont și spațiu sigur, devenind comună pentru clienții autorizați pe diferite platforme.

Serviciul nu preia cheia de pe iPhone, nu o transferă pe Android și nu încearcă să convertească două chei diferite într-una singură. Protecția platformei rămâne autonomă, iar aplicația primește un nivel comun de acces pentru propriul proiect.

Aceasta definește rolul arhitectural al KeyMeld. Nu face iOS și Android identice și nu înlocuiește mecanismele lor interne. Adaugă un nivel comun de lucru cu cheia universală, ceea ce elimină necesitatea ca proiectul să gestioneze singur emiterea acesteia pe mai multe platforme.

Pentru produse și conturi diferite, se creează circuite de chei independente. Astfel, fiecare proiect păstrează propria zonă de acces, iar mai multe conturi pe același dispozitiv rămân separate.

Zero Vault aparține proiectului

Este important de clarificat: Zero Vault nu este numele propriului KeyMeld. Este un model de arhitectură pe care îl poate construi un produs conectat.

KeyMeld funcționează ca un serviciu SaaS separat. Nu este instalat în backend-ul aplicației și nu este plasat lângă baza de date a proiectului ca un modul software suplimentar. Cheia universală este gestionată într-un circuit SaaS separat, în afara backend-ului propriului produs.

Pentru ca acest model să fie sustenabil, granițele de încredere dintre proiect și KeyMeld trebuie să rămână independente. Înregistrările, drepturile de acces și mecanismele de administrare de pe partea backend-ului și cele externe trebuie să fie separate.

Rezultatul arhitectural al acestui model poate fi definit ca arhitectură Zero Vault: baza serverului nu stochează cheia de la depozitul clientului protejat.

Zero Vault nu înseamnă că backend-ul produsului nu păstrează nimic. Acesta păstrează conturile, configurațiile, datele de business și tot ce este necesar pentru funcționarea aplicației. Însă, cheia universală nu se află în apropierea acestor date.

Compromiterea bazei serverului nu dezvăluie în mod automat cheia universală: ea nu este păstrată împreună cu conturile și alte date server-side. În același timp, această schemă nu garantează că orice eventuală problemă în infrastructură devine inofensivă. Este o soluție specifică: eliminarea cheii universale din depozitul clientului din baza produsului.

Scenariu practic: un cont pe iPhone și Android

Imaginați-vă o aplicație care gestionează date protejate local. Poate fi un identificator, un client corporate sau orice serviciu care trebuie să lucreze cu informații criptate direct pe dispozitiv.

Pe iPhone, aplicația protejează cheia locală folosind mechanismele iOS. Pe Android, se folosește un mecanism propriu de protecție Android. Cheile interne ale dispozitivelor sunt diferite, și această diferență este normală.

Fără un strat comun separat, dezvoltatorul ar trebui să decidă cum organizează accesul la aceleași date protejate pe cele două platforme. Stocarea pe platformă tot ar fi diferită, iar produsul ar trebui să lege aceste două implementări singur.

Se putea crea scheme separate pentru iOS și Android, încercând manual transferul cheilor locale sau păstrarea unor copii ale acestora pe server.

KeyMeld permite să renunți la transferul cheilor locale și la păstrarea acestor copii pe server, adăugând o cheie universală comună.

Clienții pe iPhone și Android au acces la aceeași cheie universală în cadrul aceluiași proiect și cont. În același timp, fiecare telefon continuă să folosească propriile mecanisme de protecție.

Din perspectiva utilizatorului, este un singur cont pe mai multe dispozitive. Nu trebuie să știe ce mecanism funcționează pe iPhone sau pe Android.

Când se schimbă telefonul, nu e nevoie să expedieze cheile locale de pe dispozitivul vechi sau să creeze o versiune separată de depozit protejat pentru noua platformă. Clientul nou se conectează la același proiect și are acces la aceeași cheie universală.

Backend-ul participă la autorizarea solicitării, însă cheia universală este destinată clientului autorizat și nu este stocată în baza de date server a produsului.

KeyMeld nu transferă baza aplicației și nu înlocuiește sistemul de sincronizare a înregistrărilor. Sarcina sa rămasă este să furnizeze clientului cheia necesară pentru a lucra cu datele protejate. Conținutul depozitului și actualizările rămân responsabilitatea produsului.

Trei tipuri diferite de chei și secrete

Pentru a evita confuziile, este suficient să diferențiem trei concepte.

• Cheia locală a dispozitivului aparține unui anumit telefon și este gestionată de mecanismele iOS sau Android.

• Cheia universală este utilizată de clienții autorizați ai unui proiect și cont. Este ceea ce leagă diferite platforme la nivelul produsului.

• Secretul de serviciu este folosit de backend pentru o interacțiune sigură cu KeyMeld. Nu este transmis aplicației mobile sau browserului.

Secretele de serviciu și cheile universale au scopuri diferite. În arhitectura Zero Vault, cheia universală nu este păstrată în baza de date a produsului lângă alte date de backend.

Pentru utilizarea KeyMeld, nu sunt necesare nume, parole, conținutul depozitului TOTP sau semnificația comercială a înregistrărilor. Serviciul numai necesită asocierea proiectului, contului și dreptul clientului de a primi cheia universală.

Accesul la cheie rămâne controlat

Obținerea cheii universale nu este un drept automat pentru orice client.

Dacă dispozitivul nu mai este de încredere, statutul contului s-a schimbat sau o comandă a revocat accesul, KeyMeld poate opri emiterea cheii universale pentru acel client.

Este important de nu se face concluzii prea ambițioase. Nu înseamnă automat ștergerea cheii locale existente. Este vorba despre controlul asupra solicitărilor ulterioare și conectării noilor clienți.

Pentru utilizator, înseamnă că conectarea noilor dispozitive și gestionarea accesului ulterior la cheie fac parte din același sistem.

Pentru dezvoltator, înseamnă că nu trebuie să construiască singur această logică separat pentru iOS și Android. În același timp, modelul final Zero Vault depinde de faptul dacă proiectul păstrează cheia universală proprie și dacă menține separarea între propria infrastructură și circuitul SaaS extern KeyMeld.

Ce nu face KeyMeld

KeyMeld nu este un manager de parole și nu păstrează înregistrările TOTP ale utilizatorilor. Nu devine o bază de date cloud a aplicației și nu înlocuiește sincronizarea conținutului acesteia.

Nu este o substituție pentru Apple Keychain sau Android Keystore. Serviciul păstrează mecanismele locale ale platformei și adaugă un nivel comun pentru produs.

De asemenea, nu este obligatoriu ca serviciul de identificare a utilizatorilor. Pentru identificare și autorizare pot fi responsabile alte servicii, precum MeldID, în timp ce KeyMeld are o sarcină diferită — să furnizeze clientului autorizat cheia universală, fără a o stoca în backend-ul produsului.

În cele din urmă, KeyMeld nu automatizează crearea Zero Vault. Oferă proiectului un circuit extern pentru cheia universală. Pentru a păstra această arhitectură, dezvoltatorul nu trebuie să pună cheia universală în propria bază de date server, iar zonele de încredere trebuie să rămână separate.

Cui poate fi de folos

Această abordare este interesantă pentru aplicațiile care rulează pe mai multe platforme și folosesc date protejate local.

Pot fi identificatoare, aplicații enterprise, produse SaaS, servicii multi-dispozitiv și orice alte proiecte unde un cont trebuie să funcționeze la fel pe iPhone și Android.

Valoarea pentru dezvoltator constă nu doar în reducerea logicii platformei, ci și în posibilitatea de a împărți responsabilitatea. Backend-ul produsului păstrează propriile date, iar KeyMeld, ca serviciu SaaS extern, furnizează cheia universală și gestionează emiterile ulterioare.

După ce am analizat proiectul, aș descrie KeyMeld nu ca un Zero Vault complet, ci ca un instrument care permite unui dezvoltator să construiască un astfel de model pentru propriul produs.

iOS și Android încă folosesc propriile mecanisme de protecție, clienții obțin o cheie universală comună, iar backend-ul, dacă nu păstrează cheia sau nu leagă propria infrastructură de SaaS-ul extern, nu devine un seif cu cheia depozitată pe client.

Din perspectiva utilizatorului, înseamnă acces unificat pe mai multe platforme. Pentru dezvoltator, posibilitatea de a externaliza cheia universală din backend-ul propriu. Iar pentru proiect, o arhitectură Zero Vault, în care serverul aplicației nu stochează cheia depozitului de date protejate ale clientului.

Mai multe despre proiect: KeyMeld