KeyMeld: allmänt nyckel för iphone och Android samt Zero Vault-arkitektur för projektet

Cross-platform-appar har ett problem som användaren vanligtvis inte märker. På skärmen ser han ett konto och förväntar sig samma funktion på vilken enhet som helst. Men iPhone och Android använder olika skyddsmekanismer och hanterar lokala nycklar på olika sätt.

På iPhone kan appen skydda den lokala enhetsnyckeln med hjälp av Apple Keychain. På Android används Android Keystore för detta. Dessa teknologier är utformade för att hålla känsliga nycklar i en säker miljö på enheten, men de är inte utbytbara.

För användaren spelar det ingen roll. Han vill bara kunna öppna appen på iPhone, installera den på Android och fortsätta arbeta med samma skyddade data.

För utvecklaren uppstår en arkitektonisk fråga: hur organiserar man gemensam åtkomst på två plattformar utan att flytta enhetsnycklarna eller lagra kopior av dem i backend-systemet?

När jag undersökte KeyMeld såg jag att tjänsten erbjuder en separat, universell nyckel för detta, utan att ingripa i den interna skyddet i iOS och Android.

Gemensam nyckel för olika plattformar

En lokal enhetsnyckel är knuten till en specifik telefon och skyddas av den aktuella operativsystemets verktyg. Den stannar i den säkra miljön på just den enheten och är inte avsedd för fri överföring mellan enheter.

Den universella nyckeln i KeyMeld är en annan enhet. Den skapas för ett specifikt projekt, konto och skyddad miljö och blir gemensam för auktoriserade klienter på olika plattformar.

Tjänsten tar inte nyckeln från iPhone, överför den till Android eller försöker göra två olika nycklar till en. Plattformsskyddet förblir självständigt, och appen får en gemensam åtkomstnivå för sitt projekt.

Detta definierar KeyMelds arkitektoniska roll. Den gör inte iOS och Android likadana och ersätter inte deras interna mekanismer. Den tillför ett gemensamt skikt för hantering av den universella nyckeln, vilket gör att projektet slipper hantera den plattformsövergripande distributionen själva.

För olika produkter och konton skapas separata nyckelkonfigurationer. Därmed behåller varje projekt sitt eget åtkomstområde, och flera konton på samma enhet förblir separata.

Zero Vault tillhör projektet

Det är viktigt att klargöra att Zero Vault inte är namnet på själva KeyMeld. Det är en arkitektonisk modell som ett anslutet produkt kan bygga.

KeyMeld fungerar som en fristående SaaS-tjänst. Den installeras inte i produktens backend och placeras inte bredvid en databas som ett tilläggsmodul. Den universella nyckeln hanteras i en separat SaaS-kontext, utanför själva produktens backend.

För att denna modell ska fungera måste förtroendekraven mellan projektet och KeyMeld vara oberoende. Backend och den externa tjänsten använder separata autentiseringsuppgifter, behörigheter och administrationsmekanismer.

Sådan arkitektur kallas ibland Zero Vault: serverbasen lagrar inte nyckeln till den klient-skyddade lagringen.

Zero Vault innebär inte att produktens backend inte lagrar någonting alls. Konton, inställningar, affärsdata och allt som behövs för att driva appen finns kvar. Men den universella nyckeln finns inte i närheten.

Ett eventuellt dataintrång mot serverbasen ger inte direkt tillgång till den universella nyckeln, eftersom den inte lagras med konton eller andra serverdata. Samtidigt innebär detta inte att alla fel i infrastrukturen är ofarliga. Modellen adresserar en specifik utmaning — att skilja den universella nyckeln från klientlagringen i själva produkten.

Exempel: ett konto på iPhone och Android

Föreställ dig en app med lokal skyddad data, som en autentiserare, ett företagsklient eller en tjänst som behöver arbeta med krypterad information direkt på enheten.

På iPhone skyddar appen den lokala nyckeln med hjälp av iOS. På Android använder den ett eget skyddsmekanism. De interna nycklarna är olika, och det är normalt.

Utan ett separat gemensamt lager hade utvecklaren behövt lösa hur man tillhandahåller åtkomst till samma skyddade data på båda plattformarna. Plattformsskyddet hade förblivit olika, och produktens ansvar hade inkluderat att koppla ihop dessa system manuellt.

Det hade kunnat innebära skapande av iOS- och Android-specifika lösningar, manuell överföring av nycklar eller lagring av kopior på server.

KeyMeld gör det möjligt att avstå från att flytta och lagra lokala nycklar på servern, genom att tillhandahålla en gemensam universell nyckel.

Klienten på iPhone och klienten på Android får tillgång till samma universella nyckel inom det auktoriserade projektet och kontot. Samtidigt använder varje telefon sina egna skyddsmekanismer.

För användaren ser det ut som ett enda konto på olika enheter. Han behöver inte veta vilka mekanismer iOS eller Android använder.

Bytet av telefon kräver inte att den lokala nyckeln exporteras från det gamla eller att en skyddad lagring för den nya plattformen skapas separat. Den nya klienten ansluter till samma projekt och får åtkomst till samma universella nyckel.

Backend verifierar åtkomsten, men den universella nyckeln är tilldelad ett auktoriserat klientkonto och lagras inte på produktens server.

KeyMeld flyttar inte produktens databas eller ersätter systemet för att synkronisera användarposter. Dess uppgift är att ge klienten den nyckel som krävs för att hantera skyddad data. Själva lagringen och uppdatering av innehållet är produktens egen ansvarsfråga.

Tre olika typer av nycklar och hemligheter

För att undvika förvirring är det bra att skilja på tre begrepp.

• Enhetslokal nyckel tillhör en specifik telefon och hanteras med iOS eller Android.

• Den universella nyckeln används av auktoriserade klienter inom ett projekt och konto. Den binder samman plattformarna på produktnivå.

• En tjänstesecret behövs för att backend ska kunna kommunicera säkert med KeyMeld. Den överförs inte till mobilappen eller webbläsaren.

Servicehemligheten och den universella nyckeln har olika syften. I Zero Vault-arkitekturen lagras inte den universella nyckeln i produktens databas tillsammans med backend-data.

För att KeyMeld ska fungera krävs inte personlig information, lösenord, innehåll i TOTP-lagringen eller affärsrelaterad data. Tjänsten är endast beroende av att projektet, kontot och klientens behörighet är kopplade till den universella nyckeln.

Åtkomst till nyckeln förblir kontrollerad

Tillgången till den universella nyckeln är inte en automatic rights för alla klienter.

Om en enhet inte längre kan anses vara betrodd, om kontostatus ändras eller om tillgången till projektet återkallas kan KeyMeld stoppa utfärdandet av den universella nyckeln till den klienten.

Det är viktigt att inte dra för breda slutsatser här. Det innebär inte att den lokala kopian av nyckeln tas bort automatiskt. Det handlar om att kontrollera tillgången till nyckeln och att koppla bort eller tillåta nya klienter.

För användaren innebär det att anslutning av nya enheter och hantering av deras åtkomst till nyckeln är en del av samma system.

För utvecklaren betyder det att denne inte behöver bygga denna logik separat för iOS och Android. Modellen Zero Vault hänger dock fortfarande på om projektet lagrar den universella nyckeln och om det håller isär sin egen infrastruktur och det externa SaaS-konceptet från KeyMeld.

Vad KeyMeld inte gör

KeyMeld är inte en lösenordshanterare och lagrar inga användarens TOTP-poster. Den blir inte en molnbaserad databas för appen och ersätter inte dess synkroniseringsmekanismer.

Det är inte en ersättning för Apple Keychain eller Android Keystore. Tjänsten lämnar de lokala plattformsinfrastrukturerna otrpänkta och tillför ett gemensamt skikt för produkten.

Den är heller inte ett krav på användaridentifikation. Oberoende tjänster, som MeldID, kan hantera identifiering och autentisering, medan KeyMeld adresserar en annan uppgift — att tillhandahålla en enhetlig, universell nyckel till auktoriserade klienter, utan att lagra den i produktens backend.

Slutligen skapar inte KeyMeld Zero Vault automatiskt. Den ger ett externt kontext för den universella nyckeln. För att bibehålla denna arkitektur bör utvecklaren inte lagra nyckeln i sin egen serverdatabas. Förtroendena bör förbli separata och oberoende.

Vem kan ha nytta av detta

Denna metod är relevant för appar som arbetar på flera plattformar och använder lokala, skyddade data.

Det kan vara autentiserare, företagsapplikationer, SaaS-produkter, tjänster med flera enheter eller projekt där ett konto ska fungera likadant på iPhone och Android.

För utvecklaren handlar det inte bara om att minska plattformslogik. Det är viktigare att kunna dela ansvar. Backend lagrar sina data, och KeyMeld som en extern SaaS-tjänst ansvarar för den universella nyckeln och dess distribution.

Efter att ha undersökt projektet, skulle jag beskriva KeyMeld inte som en färdig Zero Vault, utan som ett verktyg som utvecklaren kan använda för att bygga en sådan modell för sitt eget produkt.

iOS och Android förblir att använda sina egna skyddsmekanismer. Klienterna får en gemensam, universell nyckel. Och backend som inte lagrar den nyckeln, men håller isär sin egen infrastruktur och KeyMeld, innebär att den inte blir ett kassaskåp med plånbokens nyckel.

För användaren betyder det tillgång på olika plattformar med samma konto. För utvecklaren möjligheten att flytta den universella nyckeln ut ur sitt eget backend. Och i stort sett, en Zero Vault-arkitektur, där servern inte lagrar nyckeln till klientens skyddade data.

Mer om projektet: KeyMeld