KeyMeld: fælles nøgle til iPhone og Android samt Zero Vault-arkitektur til projektet

Cross-platform apps har et problem, som brugeren normalt ikke bemærker. På skærmen ser man én konto og forventer ensartet funktion på alle enheder. Men iPhone og Android bruger forskellige beskyttelsesmekanismer og håndterer lokale nøgler på forskellige måder.

På iPhone kan appen beskytte den lokale enheds nøgle med Apple Keychain. På Android bruges Android Keystore til dette formål. Disse teknologier er designet til at holde følsomme nøgler i enhedernes sikre miljø, men de er ikke udskiftelige.

Det er dog uden betydning for brugeren. De ønsker blot at kunne åbne appen på iPhone, derefter installere den på Android og fortsætte arbejdet med de samme beskyttede data.

For udvikleren opstår et arkitektonisk spørgsmål: hvordan organiseres fælles adgang på tværs af to platforme uden at flytte de lokale enheds nøgler eller lagre kopier i sin egen backend database?

Ved at undersøge KeyMeld så jeg, at tjenesten tilbyder en separat universal nøgle til dette formål, uden at blande sig i den interne beskyttelse i iOS og Android.

Fælles nøgle til forskellige platforme

Den lokale enheds nøgle er specifik for den konkrete telefon og beskyttes af det relevante operativsystems midler. Den forbliver i det sikre miljø på enheden og er ikke designet til at blive flyttet frit mellem enheder.

Universalnøglen i KeyMeld er en anden enhed. Den oprettes til et bestemt projekt, konto og beskyttet område, og bliver fælles for autoriserede klienter på forskellige platforme.

Tjenesten tager ikke nøglen fra iPhone, overfører den ikke til Android og forsøger ikke at gøre to forskellige nøgler til én. Platformssikringen forbliver selvstændig, og appen får adgang til et fælles niveau for sit projekt.

Dette definerer KeyMelds arkitektoniske rolle. Det forvandler ikke iOS og Android til det samme, og det erstatter ikke deres indbyggede mekanismer. Det tilføjer et fælles lag til håndtering af den universelle nøgle, så projektet ikke behøver at håndtere den tværplatformsdistribuering selv.

Uanset produkt og konto oprettes uafhængige nøgekonteurer. Hver projekt bevarer sin egen adgangszone, og flere konti på én enhed forbliver adskilte.

Zero Vault tilhører projektet

Det er vigtigt at præcisere: Zero Vault er ikke navnet på selve KeyMeld. Det er en arkitektonisk model, som det tilsluttede produkt kan opbygge.

KeyMeld opererer som en separat SaaS-tjeneste. Det installeres ikke inde i backend til app’en, og det placeres ikke ved siden af projektets database som en ekstra programmodul. Den universelle nøgle hostes i en separat SaaS-kontur hos KeyMeld, uden for backend af selve produktet.

For at denne model kan opretholdes, skal tillidsgrænserne mellem projektet og KeyMeld forblive uafhængige. Backend for applikationen og den eksterne tjeneste bruger adskilte loginoplysninger, adgangsrettigheder og administrationsmekanismer.

Dette kan kaldes Zero Vault-arkitekturen: serverbasen i projektet opbevarer ikke nøglen til den klientbeskyttede opbevaringsløsning.

Zero Vault betyder ikke, at backend i projektet slet ikke opbevarer noget. Der forbliver konti, indstillinger, forretningsdata og alt essentielt for applikationens funktion. Men den universelle nøgle findes ikke her.

Hvis serverbasen i projektet bliver kompromitteret, afsløres den universelle nøgle ikke direkte, da den ikke opbevares sammen med konti eller andre serverdata. Denne model garanterer heller ikke, at enhver fejl i infrastrukturen er harmløs, men den adresserer en konkret opgave: at adskille den universelle nøgle fra klientens opbevaringssted i selve produktets database.

Et aktivt scenarie: ét account på iPhone og Android

Forestil dig en app med lokale beskyttede data. Det kan være en autentifikator, erhvervskundeforbindelse eller en tjeneste, der skal kunne håndtere krypteret information direkte på enheden.

På iPhone beskytter appen den lokale nøgle med iOS-funktionerne. På Android anvendes Androids egen beskytelse. Enhedernes interne nøgler er forskellige, og det er normalt.

Uden et separat fælles lag måtte udvikleren finde en måde at organisere adgang til de samme beskyttede data på begge platforme. Den platformsspecifikke lagring ville stadig være forskellig, og produktet skulle selv forbinde de to løsninger.

Det kunne føre til separate løsninger for iOS og Android, manuel overførsel af lokale nøgler eller lagring af kopier på serveren.

KeyMeld lader en se bort fra at skulle flytte lokale nøgler eller opbevare kopier på server, ved at tilføje en fælles universalnøgle.

Klienten på iPhone og klienten på Android får adgang til den samme universelle nøgle for det autoriserede projekt og konto. Hver telefon bruger fortsat sin egen beskyttelsesevne.

Det ser ud for brugeren som et samlet account på tværs af enheder. De behøver ikke at vide, hvilket mekanisme der er i spil i iPhone, eller hvilken der bruges i Android.

Skifter de telefon, behøver de ikke eksportere den lokale nøgle fra den gamle enhed eller lave en særlig beskyttet version til den nye platform. Den nye klient opkobles til det samme projekt og får adgang til den samme universelle nøgle.

Backend deltager i godkendelsen af anmodningen, men den universelle nøgle er kun tilgængelig for den autoriserede klient og gemmes ikke i produktets serverdatabase.

Selve KeyMeld overfører ikke applikationsbasen og erstatter ikke synkroniseringssystemer. Det er en specifik opgave: at give klienten den nøgle, den skal bruge til beskyttede data. Indholdet af opbevaringen og dens opdatering er produktets eget ansvar.

Tre forskellige typer nøgler og hemmeligheder

For at undgå forvirring i arkitekturen skal man skelne mellem tre begreber.

• Den lokale enheds nøgle tilhører den specifikke telefon og beskyttes af iOS eller Android-systemerne.

• Universalnøglen bruges af autoriserede klienter på det samme projekt og konto. Den forbinder platformene på produktniveau.

• Servicehemmeligheden er nødvendig for backend til beskyttet kommunikation med KeyMeld. Den videregives ikke til mobile apps eller browsere.

Servicehemmeligheden og universalnøglen har forskellige funktioner. I Zero Vault-arkitekturen gemmes den universelle nøgle ikke i produktets database sammen med backend-data.

For at bruge KeyMeld behøver man ikke brugerens navn, adgangskode, TOTP-oplysninger eller forretningsdata. Tjenesten er afhængig af at kunne binde projekt, konto og klientens rettighed til at modtage den universelle nøgle.

Adgangen til nøglen forbliver styrbar

Adgang til den universelle nøgle er ikke en automatisk ret for enhver klient.

Hvis en enhed ikke længere er at betragte som tillidfuld, hvis kontoens status ændres, eller hvis en adgang tilbagekaldes, kan KeyMeld stoppe yderligere udstedelse af den universelle nøgle til den pågældende klient.

Det er vigtigt ikke at drage for brede konklusioner. Det betyder ikke, at den lokale nøgle automatisk slettes. Det handler om at kontrollere, hvem der kan få adgang til den, og at styre nye klienters tilslutning.

For brugeren betyder det, at tilslutning af nye enheder og styring af deres adgang til nøglen er en del af samme system.

For udvikleren betyder det, at denne logik ikke skal bygges adskilt til iOS og Android. Men den endelige Zero Vault-model afhænger stadig af, om projektet opbevarer den universelle nøgle selv, og om adskillelsen mellem egen infrastruktur og den eksterne SaaS-tjeneste, KeyMeld, opretholdes.

Hvad KeyMeld ikke gør

KeyMeld er ikke en password-manager og opbevarer ikke brugerens TOTP-indlæg. Det bliver ikke en cloud database for applikationen og erstatter heller ikke synkroniseringen af dens data.

Det er ikke en erstatning for Apple Keychain eller Android Keystore. Tjenesten efterlader de lokale platformmekanismer i ro og tilføjer et fælles lag til produktet.

Derudover er det ikke en obligatorisk brugeridentifikationstjeneste. Identifikation og autorisation kan håndteres af en separat tjeneste, fx MeldID, mens KeyMelds opgave er at give den autoriserede klient en enkel universalnøgle uden at lagre den i backend af selve produktet.

Endelig gør KeyMeld ikke automatisk Zero Vault. Det giver projektet en ekstern kontekst for den universelle nøgle. For at bevare denne arkitektur skal udvikleren undgå at opbevare den universelle nøgle i sin egen server database. Uafhængige tillidszoner skal forblive adskilte.

Hvem kan have gavn af dette

Dette approach er interessant for applikationer, der kører på flere platforme og bruger lokale sikre data.

Det kan være autentifikatorer, erhvervsapps, SaaS-produkter, multi-device-tjenester eller enhver løsning, hvor én konto skal fungere ens på iPhone og Android.

For udvikleren er værdien ikke kun at reducere platform-logikken. Det vigtigste er muligheden for at dele ansvaret. Backend for produktet opbevarer sine data, mens KeyMeld som en ekstern SaaS-tjeneste håndterer den universelle nøgle og dens videre distribution.

Efter at have set på projektet vil jeg beskrive KeyMeld som et værktøj, der giver udvikleren mulighed for at opbygge en sådan model til sit eget produkt — ikke som den færdige Zero Vault.

iOS og Android fortsætter med at bruge deres egne beskyt­telsesmekanismer. Klienterne får en fælles universalnøgle. Og backend’en, hvis den ikke opbevarer nøglen, og hvis den adskiller sin infrastruktur fra KeyMeld, er ikke en safe med adgangsnøglen til klientens opbevaringsløsning.

For brugeren betyder det adgang på tværs af platforme. For udvikleren et tiltag til at flytte den universelle nøgle ud af egen backend. Og for selve projektet en Zero Vault-arkitektur, hvor applikationsserveren ikke opbevarer nøglen til kundens beskyttede data.

Læs mere om projektet: KeyMeld