Technologie
KeyMeld: universele sleutel voor iPhone en Android en architectuur Zero Vault voor het project
KeyMeld op zichzelf is geen Zero Vault. Het is een aparte SaaS-dienst die ontwikkelaars helpt om een universele sleutel buiten de backend van het product te plaatsen, klanten op iOS en Android te verbinden en een Zero Vault-architectuur op te zetten voor hun applicatie.
Cross-platform applicaties hebben een probleem dat gebruikers doorgaans niet opmerken. Op het scherm zien ze één account en verwachten ze hetzelfde functioneren op elk apparaat. Maar intern gebruiken iPhone en Android verschillende beveiligingsmechanismen en werken ze anders met lokale sleutels.
Op de iPhone kan de app een lokaal apparaat-sleutel beschermen met behulp van Apple Keychain. Op Android wordt hiervoor Android Keystore gebruikt. Deze technologieën zijn bedoeld om gevoelige sleutels in een beveiligde omgeving van het apparaat te houden, maar ze zijn niet uitwisselbaar.
Voor de gebruiker maakt het niet uit. Hij wil gewoon de app openen op iPhone, deze installeren op Android en doorgaan met werken met dezelfde beveiligde gegevens.
Voor de ontwikkelaar ontstaat hier een architectonische vraag: hoe organiseer je gedeelde toegang op twee platformen zonder lokale apparaat-sleutels over te brengen of kopieën ervan in de database van de eigen backend op te slaan?
Bij het verdiepen in KeyMeld zag ik dat de service hiervoor een aparte universele sleutel aanbiedt, zonder de interne beveiliging van iOS en Android te beïnvloeden.
Gedeelde sleutel voor verschillende platformen
De lokale apparaat-sleutel hoort bij een specifiek toestel en wordt beschermd door de middelen van het betreffende besturingssysteem. Ze blijft in een beveiligde omgeving van dat systeem en is niet bedoeld voor vrij overdracht tussen apparaten.
De universele sleutel van KeyMeld is een andere entiteit. Ze wordt aangemaakt voor een specifiek project, account en beveiligde omgeving en wordt gedeeld voor geautoriseerde klanten op verschillende platformen.
De dienst neemt de sleutel niet over van de iPhone, migreert deze niet naar Android en probeert niet om twee verschillende sleutels in één te veranderen. Platformbeveiliging blijft onafhankelijk, en de app krijgt een gedeeld toegangsniveau voor het eigen project.
Dit bepaalt de architectonische rol van KeyMeld: het maakt iOS en Android niet gelijk, noch vervangt het hun interne mechanismen. Het voegt een gedeeld niveau toe voor werken met de universele sleutel, waardoor het project niet zelf hoeft te zorgen voor de multi-platformdistributie ervan.
Voor verschillende producten en accounts worden onafhankelijke sleutelkrommen aangemaakt. Zo behoudt elk project haar eigen toegangsgebieden, terwijl meerdere accounts op één apparaat gescheiden blijven.
Zero Vault behoort tot het project
Het is belangrijk om te verduidelijken: Zero Vault is niet de naam van de KeyMeld zelf. Het is een architectonisch model dat een verbonden product kan opzetten.
KeyMeld werkt als een aparte SaaS-dienst. Het wordt niet binnen de backend van de applicatie geïnstalleerd en niet naast de database van het project geplaatst als een extra softwaremodule. De universele sleutel wordt beheerd in een aparte SaaS-contour van KeyMeld, buiten de backend van het product.
Om dat model te behouden, moeten de vertrouwensgrenzen tussen het project en KeyMeld onafhankelijk blijven. De backend van de applicatie en de externe dienst gebruiken gescheiden inloggegevens, toegangsrechten en beheersmechanismen.
Deze architectuur wordt het Zero Vault-model genoemd: de servercomponent bewaart zelf de sleutel niet van de klantgerichte beveiligde opslag.
Zero Vault betekent niet dat de backend van het product helemaal niets bewaart. Accounts, instellingen, zakelijke gegevens en alles wat nodig is voor het functioneren van de app blijven op de server. Maar de universele sleutel wordt niet naast die gegevens opgeslagen.
Compromittering van de serverdatabase betekent op zich niet dat de universele sleutel wordt blootgelegd: deze wordt niet opgeslagen samen met accounts en andere gegevens. Tegelijkertijd garandeert dit model niet dat elke storing in de infrastructuur automatisch ongevaarlijk is. Het lost een specifiek probleem op: het verwijderen van de universele sleutel uit de klantgerichte opslag in de database van het product.
Levensscenario: één account op iPhone en Android
Stel je een applicatie voor met lokale beveiligde gegevens. Dit kan een authenticatie-app, een bedrijfscliënt of elke service zijn die direct op het apparaat met gecodeerde informatie moet werken.
Op de iPhone beschermt de app een lokale sleutel met de middelen van iOS. Op Android gebruikt het een eigen beveiligingsmechanisme. Innerlijke sleutels van de apparaten verschillen, en dat is normaal.
Zonder een aparte gedeelde laag moest de ontwikkelaar oplossen hoe dezelfde beveiligde gegevens toegankelijk te maken op twee platformen. Platformopslag zou nog steeds verschillend blijven, en het product zou zelf twee implementaties moeten koppelen.
Men kon aparte schema’s maken voor iOS en Android, sleutels handmatig migreren of kopieën ervan op de server bewaren.
KeyMeld maakt het mogelijk om af te zien van het overdragen van lokale sleutels en het opslaan van kopieën op de server, doordat het een gedeelde universele sleutel toevoegt.
De iPhone- en Android-cliënten krijgen toegang tot dezelfde universele sleutel binnen het geautoriseerde project en account. Daarbij blijven zij elk gebruik maken van hun eigen beveiligingsmiddelen.
Voor de gebruiker lijkt het op één account op verschillende apparaten. Het is niet nodig te weten welk mechanisme op iPhone en Android werkt.
Bij het wisselen van toestel hoeft hij niet de lokale sleutel te exporteren of een aparte beveiligde opslag voor de nieuwe platform te maken. De nieuwe client verbindt zich met hetzelfde project en krijgt toegang tot dezelfde universele sleutel.
De backend zit betrokken bij de autorisatie van het verzoek, maar de universele sleutel is bedoeld voor geautoriseerde klanten en wordt niet in de database van het product opgeslagen.
KeyMeld migreert geen app-basis en vervangt niet de synchronisatiesystemen van gebruikersgegevens. Het heeft één concrete taak: bieden van een sleutel die nodig is om te werken met beveiligde data. Het opslagmateriaal en de update ervan blijven de verantwoordelijkheid van het product zelf.
Drie verschillende types sleutels en geheimen
Om de onderdelen van de architectuur niet te verwarren, is het genoeg om drie begrippen te onderscheiden:
Lokale apparaat-sleutel: hoort bij een bepaald toestel en wordt door iOS of Android beschermd.
Universele sleutel: wordt gebruikt door geautoriseerde klanten van één project en account. Zij verbindt de verschillende platformen op productniveau.
Vertrouwensgeheim: is nodig voor de backend om veilig met KeyMeld te communiceren. Het wordt niet gedeeld met de mobiele app of browser.
Het vertrouwensgeheim en de universele sleutel hebben verschillende functies. In de Zero Vault-architectuur wordt de universele sleutel niet opgeslagen in de database van het product naast backend-gegevens.
Voor het werk met KeyMeld zijn geen namen, wachtwoorden, TOTP-opslag of zakelijke inhoud nodig. Het is voldoende dat het project, de account en de rechten van de klant om de universele sleutel te verkrijgen, worden gekoppeld.
Toegang tot de sleutel blijft beheersbaar
Het verkrijgen van de universele sleutel is niet een automatisch recht voor elke klant.
Als het apparaat niet langer betrouwbaar wordt geacht, de accountstatus verandert of de toegang tot het project wordt ingetrokken, kan KeyMeld de verdere verstrekking van de universele sleutel aan die klant stopzetten.
Het is belangrijk geen overdreven conclusies te trekken. Dit betekent niet automatisch dat de lokale kopie van de sleutel wordt vernietigd. Het gaat om het controleren van verdere toegang en het verbinden van nieuwe klanten.
Voor de gebruiker betekent dit dat het aansluiten van nieuwe apparaten en het beheer van hun verdere toegang tot de sleutel onder één systeem valt.
Voor de ontwikkelaar betekent het dat deze logica niet apart voor iOS en Android hoeft te worden opgebouwd. De uiteindelijke Zero Vault-architectuur blijft afhankelijk van of het project de universele sleutel bewaart en of het scheiding bewaakt tussen eigen infrastructuur en de externe SaaS-contour van KeyMeld.
Wat KeyMeld niet doet
KeyMeld is geen wachtwoordmanager en bewaart geen gebruiker TOTP-records. Het wordt geen cloud-database van de app en vervangt de synchronisatie van de inhoud niet.
Het is geen vervanging voor Apple Keychain of Android Keystore. De service laat de lokale mechanismen van het platform intact en voegt een algemeen niveau toe voor het product.
Het is ook geen noodzakelijke dienst voor gebruikersauthenticatie. Voor identificatie en autorisatie kunnen aparte diensten zoals MeldID zorgen, terwijl KeyMeld een andere taak vervult — het bieden van een universele sleutel aan geautoriseerde klanten, zonder deze in de backend van het product zelf te plaatsen.
Tot slot maakt KeyMeld geen automatisch Zero Vault. Het biedt het project een externe contour van de universele sleutel. Om deze architectuur te behouden, mag de ontwikkelaar de universele sleutel niet in de eigen serverdatabase opslaan. Ook de gescheiden vertrouwensgebieden moeten blijven bestaan.
Voor wie kan dit interessant zijn
Deze aanpak is interessant voor apps die op meerdere platformen werken en gebruik maken van lokale beveiligde gegevens.
Het kunnen authenticators zijn, bedrijfsapplicaties, SaaS-producten, multi-device diensten of elk project waarbij één account op iPhone en Android hetzelfde moet functioneren.
Voor ontwikkelaars levert het niet alleen voordelen op in het verminderen van platformlogica. Het belangrijkste is de mogelijkheid om verantwoordelijkheid te verdelen. De app-backend bewaart de gegevens, terwijl KeyMeld als externe SaaS-dienst de universele sleutel biedt en het verdere beheer regelt.
Na bestudering van het project zou ik KeyMeld niet beschrijven als een kant-en-klare Zero Vault, maar als een instrument waarmee de ontwikkelaar zo'n model voor zijn eigen product kan opzetten.
iOS en Android blijven hun eigen beveiligingsmechanismen gebruiken. De klanten krijgen toegang tot één universele sleutel. En de backend van de app, als deze de sleutel niet opslaat en de scheiding tussen infrastructuur en KeyMeld bewaakt, wordt niet de kluis met de klantgegevens.
Voor de gebruiker betekent dit een gemakkelijke toegang op verschillende platformen. Voor de ontwikkelaar een mogelijkheid om de universele sleutel buiten het eigen backend te plaatsen. En voor het project als geheel een Zero Vault-architectuur waarbij de server geen sleutel van de klantgegevens bewaart.
Meer informatie over het project: KeyMeld