KeyMeld: Felles nøkkel for iPhone og Android og Zero Vault-arkitektur for prosjektet

Cross-platform applikasjoner har et problem som brukere vanligvis ikke legger merke til. På skjermen ser de en konto og forventer lik funksjonalitet uavhengig av enhet. Men internt bruker iPhone og Android ulike beskyttelsesmekanismer og håndterer lokale nøkler forskjellig.

På iPhone kan applikasjonen beskytte den lokale enhetsnøkkelen med Apple Keychain. På Android brukes Android Keystore. Disse teknologiene er ment å holde sensitive nøkler i et sikret miljø på enheten, men de er ikke interoperable.

For brukeren spiller dette ingen rolle. De vil bare åpne appen på iPhone, deretter på Android, og fortsette å jobbe med de samme beskyttede dataene.

For utvikleren oppstår det et arkitektonisk spørsmål: Hvordan organisere felles tilgang på begge plattformer uten å flytte lokale enhetsnøkler eller lagre kopier av dem i egen backend-database?

Ved å studere KeyMeld oppdaget jeg at tjenesten tilbyr en egen universell nøkkel for dette formålet, uten å blande seg inn i den interne beskyttelsen i iOS og Android.

Felles nøkkel for ulike plattformer

Den lokale enhetsnøkkelen er knyttet til en spesifikk telefon og sikres av det respektive operativsystemet. Den forblir i et beskyttet miljø på enheten og er ikke ment for å flyttes fritt mellom enheter.

Universalnøkkelen i KeyMeld er en annen enhet. Den opprettes for et spesifikt prosjekt, konto og sikkert område, og blir felles for autoriserte klienter på ulike plattformer.

Tjenesten tar ikke nøkkel fra iPhone, overfører den til Android, eller prøver å gjøre to ulike nøkler til én. Plattformbeskyttelsen forblir selvstendig, mens applikasjonen får en felles tilgangsnivå for sitt prosjekt.

Dette definerer arkitekturen til KeyMeld. Den erstatter ikke iOS og Android sine indre mekanismer eller gjør dem like. I stedet legger den til et felles lag for å håndtere den universelle nøkkelen, noe som gjør at prosjektet ikke trenger å håndtere tverrplattform utstedelse av denne selv.

Ulike produkter og kontoer oppretter uavhengige nøkkelstrukturer. Derfor opprettholder hvert prosjekt sin egen tilgangsregion, og flere kontoer på samme enhet forblir adskilt.

Zero Vault tilhører prosjektet

Det er viktig å presisere at Zero Vault ikke er navnet på selve KeyMeld. Dette er en arkitekturmotor som et tilkoblet produkt kan bygge opp.

KeyMeld fungerer som en egen SaaS-tjeneste. Den installeres ikke i backend til applikasjonen, og plasseres ikke ved siden av prosjektets database som en ekstra modul. Den universelle nøkkelen håndteres i en egen SaaS-kontur utenfor selve prosjektets backend.

For at denne modellen skal opprettholdes, må tillitsgrensene mellom prosjektet og KeyMeld være uavhengige. Backend for applikasjonen og eksternt system får separate påloggingsopplysninger, tilgangsrettigheter og administrasjonsmekanismer.

Dette kalles Zero Vault-modellen: serverbasen lagrer ikke nøkkelen til klientens sikre lagring.

Zero Vault betyr ikke at backend til produktet ikke lagrer noe som helst. Kontoer, innstillinger, forretningsdata og annen nødvendig funksjonalitet for applikasjonen forblir på plass. Men det finnes ingen universalnøkkel liggende i nærheten.

Sikkerhetsbrudd i serverbasen alene utløser ikke avsløring av den universelle nøkkelen, da den ikke lagres sammen med kontoer eller annen serverdata. Samtidig innebærer denne modellen ikke at alle slags feil i infrastrukturen er uten risiko; den løser spesifikt oppgaven med å fjerne den universelle nøkkelen fra klientens lagringsområde i selve applikasjonens database.

Praktisk scenario: én konto på iPhone og Android

Se for deg en applikasjon med lokale beskyttede data. Det kan være en autentifikator, en bedriftsklient, eller en annen tjeneste som må operere med kryptert informasjon direkte på enheten.

På iPhone beskytter appen den lokale nøkkelen med iOS-verktøy, mens Android bruker sin egen beskyttelsesmekanisme. De interne enhetsnøklene er ulike, og det er normalt.

Uten en egen felles lagringsløsning måtte utvikleren finne en måte å organisere tilgang til de beskyttede dataene på tvers av plattformer. Den plattformspesifikke lagringen ville forbli adskilt, og produktet måtte selv koble sammen disse implementasjonene.

Det kunne ha ført til å lage egne løsninger for iOS og Android, manuelt flytte lokale nøkler eller lagre kopier på serveren.

Med KeyMeld kan man unngå å flytte lokale nøkler og lagre dem på serveren, ved å bruke en felles universalnøkkel.

Klienten på iPhone og klienten på Android får tilgang til den samme universalnøkkelen innenfor det autoriserte prosjektet og kontoen, samtidig som hver enhet beholder sine egne beskyttelsesmekanismer.

Dette oppleves som én konto på tvers av enhetene. Brukeren trenger ikke å vite hvilke sikkerhetsmekanismer som brukes i iPhone eller Android.

Ved å bytte telefon er det ikke nødvendig å eksportere lokale nøkler fra den gamle, eller å lage en ny kryptert lagringsversjon for den nye plattformen. Den nye klienten kobler seg til samme prosjekt og får samme universalnøkkel.

Backend deltar i å bekrefte forespørselen, men den universelle nøkkelen er kun tilgjengelig for den autoriserte klienten, og lagres ikke i prosjektets serverbaserte database.

Selve KeyMeld overfører ikke applikasjonsdatabase og erstatter ikke synkroniseringen av brukers data. Tjenestens oppgave er å levere klienten en nøkkel den trenger for å jobbe med de beskyttede dataene. Innholdet i lagringen og oppdatering av den forblir brukers ansvar.

Tre ulike typer nøkler og hemmeligheter

For å unngå forvirring i arkitekturen er det nok å skille mellom tre begreper.

• Enhetslokalt nøkkel tilhører en enkelt telefon og sikres av iOS eller Android.

• Universalnøkkel brukes av autoriserte klienter i ett prosjekt og en konto, og binder plattformer sammen på programvare nivå.

• Tjenestesor trengs i backend for å sikre kommunikasjon med KeyMeld. Den overføres ikke til mobilenheter eller nettlesere.

Tjenestesor og universalnøkkel fyller ulike funksjoner. I Zero Vault-arkitekturen lagres ikke den universelle nøkkelen i prosjektets database sammen med backend-data.

For å bruke KeyMeld kreves ikke klientens personlige navn, passord, TOTP-lagring eller forretningsinfo. Tjenesten er avhengig av at prosjektet, kontoen og klientens tilgang er riktig definert for å kunne levere den universelle nøkkelen.

Tilgang til nøkkelen forblir kontrollert

Tilgang til den universelle nøkkelen er ikke en selvfølge for alle klienter.

Hvis en enhet ikke er mer tillitsfull, eller kontostatus endres, eller teamet tilbakekaller tilgang til prosjektet, kan KeyMeld stoppe videre utstedelse av den universelle nøkkelen til den aktuelle klienten.

Her er det viktig å ikke trekke konklusjoner for bredt. Det betyr ikke automatisk å slette eksisterende lokale kopier av nøkkelen. Det handler om å kontrollere videre tilgang og tilkoble nye klienter.

Dette betyr for brukeren at installasjon av nye enheter og styring av tilgangen til nøkkelen er en integrert prosess.

For utvikleren betyr det at man slipper å lage egen logikk for iOS og Android separat. I tillegg avhenger den endelige Zero Vault-modellen fortsatt av om prosjektet lagrer den globale nøkkelen og opprettholder separasjonen mellom sin egen infrastruktur og det eksterne SaaS-konturet til KeyMeld.

Hva KeyMeld ikke gjør

KeyMeld er ikke en passordmanager og lagrer ikke brukerens TOTP-oppføringer. Den blir ikke en skybasert database for applikasjonen og overtar ikke synkroniseringen av innhold.

Det er ikke en erstatning for Apple Keychain eller Android Keystore. Tjenesten lar de lokale plattformmekanismene bli værende, og legger til et ekstra felles lag for produktet.

Det er heller ikke en nødvendighet for brukerautentisering. For identifikasjon og innlogging kan det brukes en separat tjeneste som MeldID, mens KeyMelds oppgave er å levere en universell nøkkel til autorisert klient, uten å lagre den i produktets backend.

Til slutt gjør ikke KeyMeld Zero Vault automatisk. Den gir et eksternt kontur av den universelle nøkkelen, men utvikleren må selv holde den sikkert utenfor produktets database. Uavhengige tillitssoner må også opprettholdes.

Hvem kan ha nytte av dette

Dette er relevant for apper som opererer på flere plattformer og bruker lokale beskyttede data.

Det kan være autentifikatorer, bedriftsapper, SaaS-produkter, tjenester med flere enheter, eller prosjekter hvor én konto skal fungere likt på iPhone og Android.

For utvikleren er det verdifullt ikke bare fordi det reduserer plattformspesifikk logikk, men også fordi det skiller ansvar. Backend til produktet lagrer sine data, mens KeyMeld som en ekstern SaaS-tjeneste håndterer den universelle nøkkelen og utstedelsen.

Etter å ha evaluert prosjektet ser jeg KeyMeld ikke bare som en ferdig løsning for Zero Vault, men som et verktøy utvikleren kan bruke for å bygge denne typen modell for sitt eget produkt.

iOS og Android bruker fortsatt sine egne beskyttelsesmekanismer. Klientene mottar en felles universell nøkkel. Og backend, hvis den ikke lagrer denne nøkkelen, og opprettholder skillet mellom sin egen infrastruktur og KeyMeld, blir ikke en safe med klientens nøkler.

Dette betyr for brukeren en felles tilgang på tvers av enhetene. For utvikleren en mulighet til å flytte den universelle nøkkelen ut av egen backend. Og for prosjektet en Zero Vault-arkitektur der applikasjonsserveren ikke lagrer nøkkelen til klientens beskyttede data.

Les mer om prosjektet: KeyMeld