KeyMeld: Gemeinsamer Schlüssel für iPhone und Android sowie Zero Vault-Architektur für das Projekt

Bei plattformübergreifenden Anwendungen gibt es ein Problem, das der Nutzer meist nicht bemerkt. Auf dem Bildschirm sieht er ein Konto und erwartet eine gleichbleibende Funktionalität auf jedem Gerät. Doch im Inneren verwenden iPhone und Android unterschiedliche Sicherheitsmechanismen und arbeiten mit lokalen Schlüsseln unterschiedlich.

Auf dem iPhone kann die App den lokalen Geräte-Schlüssel mit Hilfe von Apple Keychain schützen. Auf Android wird dafür Android Keystore genutzt. Diese Technologien sollen sicherstellen, dass sensible Schlüssel in einer geschützten Umgebung des Geräts verbleiben, sind aber nicht austauschbar.

Für den Nutzer spielt das keine Rolle. Er möchte einfach die App auf dem iPhone öffnen, sie auf Android installieren und mit den gleichen geschützten Daten weiterarbeiten.

Für den Entwickler entsteht hier eine Architekturfrage: Wie kann man einen gemeinsamen Zugriff auf beiden Plattformen organisieren, ohne lokale Geräte-Schlüssel zu übertragen und Kopien in der Backend-Datenbank abzulegen?

Beim Erkunden von KeyMeld stellte ich fest, dass der Dienst dafür einen separaten universellen Schlüssel anbietet, der die interne Schutzmechanismen von iOS und Android unberührt lässt.

Gemeinsamer Schlüssel für verschiedene Plattformen

Der lokale Geräte-Schlüssel ist an ein konkretes Smartphone gebunden und wird durch die jeweiligen Betriebssysteme geschützt. Er verbleibt in der geschützten Umgebung des jeweiligen Geräts und ist nicht für den freien Transfer zwischen Geräten vorgesehen.

Der universelle Schlüssel von KeyMeld ist eine andere Entität. Er wird für ein konkretes Projekt, einen Account und einen geschützten Raum erstellt und wird zum gemeinsamen Schlüssel für autorisierte Clients auf verschiedenen Plattformen.

Der Dienst entnimmt den Schlüssel nicht vom iPhone, transferiert ihn nicht auf Android und versucht nicht, zwei verschiedene Schlüssel zu einem zu vereinen. Plattformschutz bleibt eigenständig, während die App einen gemeinsamen Zugang für das Projekt erhält.

Genau das bestimmt die architektonische Rolle von KeyMeld. Es macht iOS und Android nicht gleich und ersetzt deren interne Mechanismen nicht. Es fügt eine gemeinsame Ebene der Arbeit mit dem universellen Schlüssel hinzu, wodurch das Projekt die plattformübergreifende Ausgabe nicht selbst regeln muss.

Für verschiedene Produkte und Accounts werden unabhängige Schlüsselkreise erstellt. So behält jedes Projekt seinen eigenen Zugriffsbereich, und mehrere Accounts auf einem Gerät bleiben getrennt.

Zero Vault gehört zum Projekt

Wichtig zu klären ist: Zero Vault ist kein Name des KeyMeld selbst. Es ist ein architektonisches Modell, das ein angebundenes Produkt aufbauen kann.

KeyMeld arbeitet wie ein eigenständiger SaaS-Dienst. Es wird nicht im Backend der Anwendung installiert oder neben der Projekt-Datenbank als weiteres Modul platziert. Der universelle Schlüssel wird in einem separaten SaaS-Kontur von KeyMeld verwaltet, außerhalb des Backends des Produkts.

Damit dieses Modell erhalten bleibt, müssen die Vertrauensgrenzen zwischen dem Projekt und KeyMeld unabhängig sein. Das Backend der Anwendung und der externe Dienst verwenden getrennte Anmeldedaten, Zugriffrechte und Administrationsmechanismen.

Dieses Ergebnis in der Architektur des Projekts kann man als Zero Vault-Modell bezeichnen: Die Server-Datenbank speichert den Schlüssel vom clientseitigen sicheren Speicher nicht.

Zero Vault bedeutet nicht, dass das Backend des Produkts überhaupt nichts speichert. Es verbleiben Konten, Einstellungen, Geschäftsdaten und alles, was für den Betrieb notwendig ist. Aber der universelle Schlüssel ist nicht neben ihnen vorhanden.

Eine Kompromittierung der Server-Datenbank des Produkts offenbart den universellen Schlüssel selbst nicht: Dieser wird nicht gemeinsam mit Konten oder anderen Serverdaten gespeichert. Diese Architektur bedeutet auch nicht, dass ein Ausfall in irgendeinem Bereich der Infrastruktur automatisch harmlos ist. Sie löst eine konkrete Aufgabe: den universellen Schlüssel vom klientenseitigen Speicher des Produkts zu entfernen.

Live-Szenario: Ein Konto auf iPhone und Android

Stellen Sie sich eine Anwendung mit lokal geschützten Daten vor. Das kann ein Authentifikator, ein Firmen-Client oder ein beliebiger Dienst sein, der direkt auf dem Gerät verschlüsselte Informationen verarbeitet.

Auf dem iPhone schützt die App den lokalen Schlüssel mit iOS-Mechanismen. Auf Android wird ein eigenes Schutzsystem genutzt. Die internen Schlüssel der Geräte sind unterschiedlich, was normal ist.

Ohne eine separate gemeinsame Schicht müsste der Entwickler regeln, wie auf beiden Plattformen auf dieselben geschützten Daten zugegriffen wird. Das plattformspezifische Speichern bliebe trotzdem unterschiedlich, und das Produkt müsste diese zwei Implementierungen selbst verknüpfen.

Man könnte separate Schemata für iOS und Android erstellen, versuchen, die lokalen Schlüssel manuell zu übertragen oder Kopien auf dem Server zu speichern.

KeyMeld ermöglicht es, auf die Übertragung lokaler Schlüssel und die Speicherung von Kopien auf dem Server zu verzichten, indem ein gemeinsamer universeller Schlüssel hinzugefügt wird.

Der Client auf iPhone und der Client auf Android greifen auf denselben universellen Schlüssel im Rahmen des autorisierten Projekts und Accounts zu. Dabei nutzt jedes Gerät weiterhin seine eigenen Schutzmechanismen.

Für den Nutzer sieht das wie ein einheitliches Konto auf verschiedenen Geräten aus. Er muss nicht wissen, welcher Mechanismus auf dem iPhone oder Android verwendet wird.

Beim Wechsel des Telefons ist es nicht notwendig, den lokalen Schlüssel vom alten Gerät zu exportieren oder eine separate geschützte Speicherung für die neue Plattform zu erstellen. Der neue Client verbindet sich mit demselben Projekt und erhält Zugang zum selben universellen Schlüssel.

Das Backend beteiligt sich an der Autorisierung der Anfrage. Der universelle Schlüssel ist für den autorisierten Client bestimmt und wird nicht in der Server-Datenbank des Produkts gespeichert.

KeyMeld selbst transferiert keine Anwendungsdatenbank und ersetzt keine Synchronisation von Benutzerdaten. Seine konkrete Aufgabe ist es, dem Client den Schlüssel bereitzustellen, um mit geschützten Daten zu arbeiten. Der Inhalt des Speichers und dessen Aktualisierung bleiben in der Verantwortung des Produkts.

Drei verschiedene Arten von Schlüsseln und Geheimnissen

Um die verschiedenen Teile der Architektur zu unterscheiden, lassen sich drei Begriffe unterscheiden:

• Lokaler Geräte-Schlüssel gehört zu einem konkreten Gerät und wird durch iOS oder Android verwaltet.

• Universeller Schlüssel wird von autorisierten Clients eines Projekts und Accounts genutzt. Er verbindet verschiedene Plattformen auf Produktebene.

• Servicesecret braucht das Backend für die geschützte Interaktion mit KeyMeld. Es wird nicht an mobile Anwendungen oder Browser übertragen.

Servicesecret und universeller Schlüssel erfüllen unterschiedliche Aufgaben. Im Zero Vault-Architekturmodell werden universelle Schlüssel nicht in der Produkt-Datenbank neben den Backend-Daten gespeichert.

Für die Arbeit mit KeyMeld sind kein Personenname, Passwort, TOTP-Storage oder Geschäftsbezug notwendig. Der Dienst benötigt nur die Verbindung zwischen Projekt, Account und Zugriffsrecht, um den universellen Schlüssel zu liefern.

Zugriffsmanagement bleibt gewährleistet

Der Erhalt des universellen Schlüssels ist kein automatisches Recht jedes Clients.

Wenn ein Gerät nicht mehr vertrauenswürdig ist, sich der Status des Kontos ändert oder der Zugriff auf das Projekt widerrufen wurde, kann KeyMeld die Ausgabe des universellen Schlüssels an diesen Client einstellen.

Hierbei ist es wichtig, keine zu großen Schlüsse zu ziehen. Das bedeutet nicht, dass der lokale Schlüssel automatisch gelöscht wird. Es geht um die Kontrolle darüber, ob und wie weitere Schlüssel an den Client ausgegeben werden dürfen und ob neue Clients zugelassen werden.

Für den Nutzer bedeutet das, dass neue Geräte verbunden und deren Zugang zum Schlüssel entsprechend verwaltet werden.

Für den Entwickler heißt das, dass er diese Logik nicht eigenständig für iOS und Android implementieren muss. Die Zero Vault-Architektur hängt weiterhin davon ab, ob das Projekt den universellen Schlüssel selbst speichert und die Trennung zwischen eigener Infrastruktur und dem externen SaaS-Kontur von KeyMeld aufrechterhält.

Was KeyMeld nicht leistet

KeyMeld ist kein Passwort-Manager und speichert keine TOTP-Einträge von Nutzern. Es wird keine Cloud-Datenbank der Anwendung und kein Austausch ihrer Inhalte ersetzt.

Es ist kein Ersatz für Apple Keychain oder Android Keystore. Der Dienst lässt die lokalen Plattformmechanismen intakt und fügt eine gemeinsame Ebene für das Produkt hinzu.

Es ist auch kein obligatorischer Dienst für die Nutzer-Authentifizierung. Für Identifikation und Autorisierung können separate Dienste wie MeldID zuständig sein, während KeyMeld eine andere Aufgabe erfüllt – einen einheitlichen universellen Schlüssel an den autorisierten Client bereitzustellen, ohne ihn im Backend des Produkts zu speichern.

Schließlich macht KeyMeld kein Zero Vault automatisch. Es stellt dem Projekt einen externen Kontur des universellen Schlüssels bereit. Damit diese Architektur erhalten bleibt, sollte der universelle Schlüssel nicht im eigenen Server des Projekts gespeichert werden. Unabhängige vertrauenswürdige Zonen müssen weiterhin getrennt bleiben.

Wer könnte das benötigen

Dieser Ansatz ist interessant für Anwendungen, die auf mehreren Plattformen arbeiten und lokale geschützte Daten nutzen.

Das können Authentifikatoren, Firmen-Apps, SaaS-Produkte, Dienste mit mehreren Geräten oder beliebige Projekte sein, bei denen ein Konto auf iPhone und Android gleichermaßen funktioniert.

Der Wert für Entwickler liegt nicht nur in der Reduktion der plattformspezifischen Logik. Viel wichtiger ist die Verantwortungsaufteilung: Das Produkt-Backend speichert seine Daten, während KeyMeld als externer SaaS-Dienst den universellen Schlüssel bereitstellt und die weitere Ausgabe steuert.

Nach erster Auseinandersetzung mit dem Projekt würde ich KeyMeld nicht als fertigen Zero Vault bezeichnen, sondern als Werkzeug, mit dem der Entwickler eine entsprechende Modell für das eigene Produkt erstellen kann.

iOS und Android nutzen weiterhin ihre eigenen Schutzmechanismen. Die Clients bekommen einen gemeinsamen universellen Schlüssel. Das Backend, das den Schlüssel selbst nicht speichert und die Trennung zwischen eigener Infrastruktur und dem externen SaaS-Kontur aufrechterhält, wird kein Tresor mit dem Schlüssel vom Kliententresor.

Für den Nutzer bedeutet das einen einheitlichen Zugriff auf verschiedenen Plattformen. Für den Entwickler ist das die Möglichkeit, den universellen Schlüssel aus dem eigenen Backend auszulagern. Für das Projekt insgesamt ergibt sich eine Zero Vault-Architektur, bei der der Server des Produkts den Schlüssel von den geschützten Kundendaten nicht speichert.

Mehr zum Projekt: KeyMeld