KeyMeld: skupni ključ za iPhone in Android ter arhitektura Zero Vault za projekt

Pri večplatformnih aplikacijah obstaja problem, ki ga uporabnik običajno ne opazi. Na zaslonu vidi en račun in pričakuje enako delovanje na vseh napravah. A znotraj iPhone in Android uporabljajo različne mehanizme zaščite in delujejo s lokalnimi ključi različno.

Na iPhone aplikacija lahko ščiti lokalni ključ naprave z uporabo orodij Apple Keychain. Na Androidu za to uporabljajo Android Keystore. Te tehnologije so namenjene zadrževanju občutljivih ključev v varni okolici naprave, vendar niso zamenljive med seboj.

Za uporabnika to ni pomembno. Enostavno želi odpreti aplikacijo na iPhone, nato jo namestiti na Android in nadaljevati delo z istimi zaščitenimi podatki.

Za razvijalca se v tem pojavi arhitekturno vprašanje: kako organizirati skupni dostop na dveh platformah, ne prenašati lokalnih ključev naprav in ne shranjevati njihovih kopij v bazo lastnega backend-a?

Pri razumevanju KeyMeld sem opazil, da storitev za to ponuja ločen univerzalen ključ, brez poseganja v notranjo zaščito iOS in Android.

Skupni ključ za različne platforme

Lokalni ključ naprave je povezan s specifičnim telefonom in je ščitjen z orodji ustreznega operacijskega sistema. Ostaja v varni okolici določene naprave in ni namenjen prostemu prenosu med napravami.

Univerzalni ključ KeyMeld je drugačen. Ustvarjen je za določen projekt, račun in zaščiteno območje, ter postane skupni za avtorizirane stranke na različnih platformah.

Storitev ne odvzema ključa z iPhone-ja, ga ne prenaša na Android in ne poskuša združiti dveh različnih ključev v enega. Platformska zaščita ostaja samostojna, aplikacija pa dobi skupno raven dostopa za svoj projekt.

To pravzaprav določa arhitekturno vlogo KeyMeld. Ne naredi iOS in Android enakih, niti ne nadomesti njihovih notranjih mehanizmov. Dodaja skupno raven obravnave z univerzalnim ključem, ki projektu omogoča, da sam ne rabi reševati njegovo medplatformsko razdeljevanje.

Za različne izdelke in račune so ustvarjeni neodvisni konturi ključev. Tako vsak projekt ohrani lasten dostopni prostor, več računov na eni napravi ostane ločenih.

Zero Vault je last projekta

Pomembno je takoj poudariti: Zero Vault ni ime samega KeyMeld. To je arhitekturni model, ki ga lahko vzpostavi povezani produkt.

KeyMeld deluje kot lojena SaaS storitev. Ni nameščen neposredno znotraj backend-a aplikacije in ni nameščen ob bazi projekta kot dodatni programski modul. Univerzalni ključ se upravlja v ločenem konturu SaaS storitve KeyMeld, zunaj samega backend-a produkta.

Da bi ta model ostal, morata biti meje zaupanja med projektom in KeyMeld neodvisni. Uporabljajo se ločeni overitveni podatki, pravice dostopa in mehanizmi administracije za backend in zunanji servis.

Takšen arhitekturni model lahko označimo kot Zero Vault: strežniška baza ne vsebuje ključa od klientskega zaščitenega shranjevanja.

Zero Vault ne pomeni, da backend produkta ničesar ne hrani. Na njegovi strani ostajajo računi, nastavitve, poslovni podatki in vse potrebno za delovanje aplikacije. A univerzalnega ključa poleg tega ni.

Razkritje strežniške baze produkta samo po sebi ne razkrije univerzalnega ključa: ta ni shranjen skupaj z računi in drugimi strežniškimi podatki. Hkrati takšen model ne zagotavlja, da bi vsaka morebitna okvara v infrastrukturi bila samodejno neboleča. Rešuje specifičen problem – odstranjevanje univerzalnega ključa iz baze samega produkta in s tem preprečuje njegov dostop znotraj same aplikacije.

Živi scenarij: en račun na iPhone in Android

Predstavljajmo si aplikacijo z lokalnimi zaščitenimi podatki. To je lahko avtentikator, korporativni odjemalec ali kakšen drug servis, ki potrebuje delo s šifriranimi podatki neposredno na napravi.

Na iPhone-u aplikacija ščiti lokalni ključ z orodji iOS. Na Androidu uporablja lasten mehanizem zaščite Android. Notranji ključi naprav so različno, in to je normalno.

Brez loženega skupnega sloja bi moral razvijalec reševati, kako organizirati dostop do istih zaščitenih podatkov v obeh platformah. Platformsko shranjevanje bi vseeno ostalo različno, produkt pa bi moral sam povezovati te dve rešitvi.

Možno bi bilo ustvariti ločene sheme za iOS in Android, ročno prenositi lokalne ključe ali shranjevati njihove kopije na strežniku.

KeyMeld omogoča, da se odstrani prenos lokalnih kljucev in shranjevanje njihovih kopij na strežnik, ter dodaja skupni univerzalni ključ.

Odjemalec na iPhone-u in odjemalec na Androidu dobita dostop do istega univerzalnega ključa v okviru avtoriziranega projekta in računa. Hkrati vsak telefon ohrani lastno zaščito.

Za uporabnika je to videti kot enoten račun na različnih napravah. Ni mu treba vedeti, kateri mehanizem deluje znotraj iPhone in kateri na Androidu.

Ob menjavi telefona ni treba izvažati lokalnega ključa iz stare naprave ali ustvarjati ločeno zaščiteno shranjevanje za novo platformo. Novi odjemalec se poveže na isti projekt in dostopa do istega univerzalnega ključa.

Backend sodeluje pri avtorizaciji zahtevka, vendar je univerzalni ključ namenjen le avtoriziranemu odjemalcu in ni shranjen v strežniški bazi produkta.

Sama storitev KeyMeld ne prenaša baze aplikacije in ne nadomešča sistema sinhronizacije uporabniških zapisov. Njena vloga je specifična: zagotoviti odjemalcu ključ za delo s zaščitenimi podatki. Vsebina shranjevanja in njegovo posodabljanje ostajata odgovornost samega produkta.

Tri različne vrste ključev in skrivnosti

Da bi se izognili zmedi v arhitekturi, je dovolj razlikovati tri pojme.

• Lokalni ključ naprave pripada določeni napravi in je ščitjen z orodji iOS ali Android.

• Univerzalni ključ uporablja avtorizirane odjemalce enega projekta in računa. Po njem platforme povezujejo v samo proizvoden.

• Službena skrivnost je potrebna za backend za zaščiteno komunikacijo z KeyMeld-om. Ni namenjena prenosu na mobilno aplikacijo ali brskalnik.

Službena skrivnost in univerzalni ključ opravljata različne naloge. V arhitekturi Zero Vault univerzalni ključ ni shranjen v bazi produkta poleg strežniških podatkov.

Za delovanje KeyMeld ni potrebno ime osebe, geslo, vsebina TOTP-shranjevalnika ali poslovni pomen zapisov. Pomembno je le povezava projekta, računa in pravice odjemalca do pridobitve univerzalnega ključa.

Pridobivanje ključa je še vedno upravljano

Pridobivanje univerzalnega ključa ni samodejno pravico vsakega odjemalca.

Če naprava ni več zaupanja vredna, se status računa spremeni ali administrator prekliče dostop do projekta, KeyMeld lahko ustavi nadaljnjo izdajo univerzalnega ključa tem odjemalcem.

Tu ni za avtomatsko uničenje že obstoječe lokalne kopije ključa. Govorimo o nadzoru nad nadaljnjim dostopom do ključa in dodatnim vzpostavljanjem povezav za nove odjemalce.

Za uporabnika to pomeni, da je povezava novih naprav in upravljanje nadaljnjega dostopa do ključa v istem sistemu.

Za razvijalca pa pomeni, da takšno logiko ni treba posebej vzpostavljati za iOS in Android. Končna arhitektura Zero Vault je vseeno odvisna od tega, ali projekt hrani univerzalni ključ in ali vzdržuje ločenost med lastno infrastrukturo in zunanjo SaaS-om KeyMeld.

Česa KeyMeld ne počne

KeyMeld ni manager gesel in ne hrani uporabniških TOTP zapisov. Ni tudi oblačna baza podatkov aplikacije in ne nadomešča sinhronizacije vsebine.

Ni nadomestek za Apple Keychain ali Android Keystore. Storitev pusti interne mehanizme platform na mestu in dodaja skupno raven za produkt.

Ni tudi obvezna storitev identifikacije uporabnika. Za identifikacijo in avtentikacijo je lahko odgovoren ločen servis, na primer MeldID, medtem ko KeyMeld reši drugo nalogo – zagotoviti avtoriziranemu odjemalcu enoten univerzalen ključ, ne da bi ga postavil v backend produkta.

Na koncu, KeyMeld ne ustvari samodejno Zero Vault. Nudi projektu zunanji okvir univerzalnega ključa. Da bi ohranil to arhitekturo, razvijalec ne sme hraniti univerzalnega ključa v lastni strežniški bazi. Nezavisni zaupanja vredni območji morajo ostati ločeni.

Kdo bi to lahko potreboval

Tak pristop je zanimiv za aplikacije, ki delujejo v več platformah hkrati in uporabljajo lokalne zaščitene podatke.

To so lahko avtentikatorji, korporativne aplikacije, SaaS-oni, storitve z več napravami in vsi projekti, kjer mora en račun delovati enako na iPhone in Android.

Za razvijalca je vrednost ne le v zmanjševanju platformske logike. Zelo pomembno je možnost razdeljevanja odgovornosti. Arhitektura backend-a hrani lastne podatke, KeyMeld pa kot zunanja SaaS storitev zagotavlja univerzalni ključ in upravlja njegovo nadaljnjo izdajanje.

Po seznanitvi z projektnim konceptom bi KeyMeld opisal ne kot popoln Zero Vault, temveč kot orodje, s katerim lahko razvijalec zgradi tak model za svoj produkt.

iOS in Android še vedno uporabljata lastne mehanizme zaščite. Stranke dobijo skupni univerzalni ključ. Backend aplikacije, če ta ne hrani ključa zase in ohranja ločeno infrastrukturo od KеyMeld-a, ni skriti sef z dostopom do klientskega shranjevanja.

Za uporabnika to pomeni enoten dostop na različnih platformah. Za razvijalca – možnost, da univerzalni ključ preseli izven svojega backend-a. In za celoten projekt arhitekturo Zero Vault, kjer strežnik ne hrani ključa od klientskih zaščitenih podatkov.

Več o projektu: KeyMeld