KeyMeld: uniwersalny klucz dla iPhone i Android oraz architektura Zero Vault dla projektu

Przenikliwość aplikacji wieloplatformowych ujawnia problem, który użytkownicy zazwyczaj nie dostrzegają. Na ekranie widzą jeden konto i oczekują takiej samej funkcjonalności na dowolnym urządzeniu. Jednak iPhone i Android korzystają z różnych mechanizmów ochrony i obsługują lokalne klucze inaczej.

Na iPhone aplikacja może chronić lokalny klucz urządzenia za pomocą Apple Keychain. Na Android do tego służy Android Keystore. Te technologie mają na celu zapewnienie, że wrażliwe klucze pozostają w zabezpieczonym środowisku urządzenia, ale nie są zamienne.

Dla użytkownika to nie ma znaczenia. Chce po prostu otworzyć aplikację na iPhone i kontynuować na Androidzie z tymi samymi chronionymi danymi.

Dla dewelopera pojawia się pytanie architektoniczne: jak zapewnić wspólny dostęp na obu platformach, nie przenosząc lokalnych kluczy urządzeń i nie umieszczając ich kopii w bazie własnego backendu?

Analizując KeyMeld, dostrzegłem, że serwis oferuje do tego osobny uniwersalny klucz, nie ingerując w wewnętrzne mechanizmy ochrony iOS i Android.

Uniwersalny klucz dla różnych platform

Lokalny klucz urządzenia odnosi się do konkretnego telefonu i jest chroniony przez odpowiedni system operacyjny. Pozostaje w bezpiecznym środowisku danego urządzenia i nie jest przeznaczony do swobodnego przenoszenia między urządzeniami.

Uniwersalny klucz KeyMeld to odmienna jednostka. Tworzony jest dla konkretnego projektu, konta i bezpiecznej przestrzeni, i staje się wspólny dla autoryzowanych klientów na różnych platformach.

Serwis nie zabiera klucza z iPhone, nie przenosi go na Androida i nie próbuje złączyć dwóch różnych kluczy w jeden. Ochrona platformowa pozostaje niezależna, a aplikacja otrzymuje wspólny poziom dostępu do swojego projektu.

To właśnie determinuje architektoniczną rolę KeyMeld. Nie czyni iOS i Android jednolitymi ani nie zastępuje ich mechanizmów. Dodaje wspólną warstwę pracy z uniwersalnym kluczem, dzięki któremu projekt może nie rozwiązywać ręcznie kwestii jego cross-platformowego wydania.

Tworzone są niezależne kontury kluczy dla różnych produktów i kont. Każdy projekt zachowuje własny zakres dostępu, a wiele kont na tym samym urządzeniu pozostaje oddzielnych.

Zero Vault należy do projektu

Ważne od razu wyjaśnić: Zero Vault to nie nazwa samego KeyMeld. To architektoniczny model, który może zostać zbudowany przez podłączony produkt.

KeyMeld działa jako odrębny serwis SaaS. Nie instaluje się go wewnątrz backendu aplikacji, ani nie umieszcza obok bazy danych projektu jako kolejny moduł programistyczny. Uniwersalny klucz obsługiwany jest w oddzielnym koncie SaaS KeyMeld, poza backendem samego produktu.

By tak zbudować ten model, granice zaufania między projektem a KeyMeld muszą pozostać niezależne. Backend aplikacji i zewnętrzny serwis korzystają z odrębnych danych uwierzytelniających, uprawnień i mechanizmów administracji.

Dokładnie tak można opisać architekturę projektu jako model Zero Vault: serwerowa baza nie przechowuje klucza z bezpiecznego magazynu klienta.

Zero Vault nie oznacza, że backend produktu niczego nie przechowuje. Na jego stronie pozostają konta, ustawienia, dane biznesowe i wszystko niezbędne do działania aplikacji. Jednak nie ma tam uniwersalnego klucza.

Ujęcie serwerowej bazy produktu w przypadku jej kompromitacji nie ujawnia uniwersalnego klucza, który nie jest przechowywany razem z kontami czy innymi danymi serwerowymi. Taka architektura nie gwarantuje automatycznie bezpieczeństwa w razie awarii infrastruktury, ale rozwiązuje konkretny problem — wyłączenie uniwersalnego klucza od klienta z bazy samego produktu.

Praktyczny scenariusz: jedno konto na iPhone i Android

Wyobraźmy aplikację z lokalnymi chronionymi danymi. To może być autoryfikator, klient korporacyjny czy dowolna usługa wymagająca pracy z zaszyfrowaną informacją na urządzeniu.

Na iPhone aplikacja chroni lokalny klucz za pomocą iOS. Na Android implementacja jest własna i korzysta z Android Keystore. Klucze wewnętrzne są różne, co jest normalne.

Bez osobnej warstwy wspólnej deweloper musiałby sam rozwiązać, jak zapewnić dostęp do tych samych chronionych danych na obu platformach. Magazyny platformowe pozostawałyby odrębne, a produkt musiałby samodzielnie łączyć te dwie realizacje.

Można byłoby tworzyć osobne schematy dla iOS i Android, próbować ręcznie przenosić lokalne klucze lub przechowywać ich kopie na serwerze.

KeyMeld pozwala zrezygnować z przenoszenia lokalnych kluczy i ich przechowywania jako kopii na serwerze, dodając wspólny uniwersalny klucz.

Klient na iPhone i klient na Androidzie uzyskują dostęp do tego samego uniwersalnego klucza w ramach zatwierdzonego projektu i konta. Przy tym każde urządzenie korzysta z własnych mechanizmów ochrony.

Dla użytkownika to wygląda jak jednolite konto na różnych urządzeniach. Nie musi wiedzieć, jaki mechanizm działa w iPhone, a jaki na Androidzie.

Przy zmianie telefonu nie trzeba eksportować lokalnego klucza ze starego urządzenia ani tworzyć odrębnej wersji chronionego magazynu dla nowej platformy. Nowy klient dołącza do tego samego projektu i korzysta z tego samego uniwersalnego klucza.

Backend bierze udział w autoryzacji zapytania, ale uniwersalny klucz jest przeznaczony dla autoryzowanego klienta i nie jest przechowywany w bazie produktu.

Sam KeyMeld nie przenosi bazy aplikacji ani nie zastępuje systemu synchronizacji użytkowniczych zapisów. Jego zadanie jest konkretnie — zapewnić klientowi klucz niezbędny do pracy z chronionymi danymi. Zawartość magazynu i jego aktualizacje pozostają w gestii samego produktu.

Trzy różne typy kluczy i sekretów

Aby nie mylić części architektury, wystarczy rozróżnić trzy pojęcia.

• Lokalny klucz urządzenia należy do konkretnego telefonu i obsługiwany jest przez iOS lub Android.

• Uniwersalny klucz używany jest przez autoryzowanych klientów jednego projektu i konta. To on łączy różne platformy na poziomie samego produktu.

• Sekret serwisowy konieczny jest backendowi dla bezpiecznej wymiany z KeyMeld. Nie jest przekazywany aplikacji mobilnej ani przeglądarce.

Sekret serwisowy i uniwersalny klucz pełnią różne funkcje. W architekturze Zero Vault uniwersalny klucz nie jest przechowywany w bazie produktu razem z danymi backendu.

Do działania KeyMeld nie potrzeba imienia użytkownika, hasła, zawartości TOTP lub znaczenia biznesowego zapisów. Serwis wymaga powiązania projektu, konta i uprawnień klienta do uzyskania uniwersalnego klucza.

Kontrola dostępu do klucza

Pobranie uniwersalnego klucza nie jest automatycznym prawem każdego klienta.

Jeśli urządzenie przestanie być zaufane, zmieni się status konta lub i został odwołany dostęp do projektu, KeyMeld może zaprzestać dalszego wydawania uniwersalnego klucza temu klientowi.

Nie oznacza to automatycznego usunięcia kopii klucza z urządzenia, lecz kontrolę nad jego dalszym dostępem i dodawaniem nowych klientów.

Dla użytkownika oznacza to, że dołączenie nowych urządzeń i zarządzanie ich dostępem do klucza to proces zarządzany przez jeden system.

Dla dewelopera — że nie musi samodzielnie implementować takiej logiki oddzielnie dla iOS i Androida. Mimo to końcowa architektura Zero Vault nadal zależy od tego, czy projekt przechowuje uniwersalny klucz u siebie i czy utrzymuje separację między własną infrastrukturą a zewnętrznym konturem SaaS KeyMeld.

Czego KeyMeld nie robi

KeyMeld nie jest menedżerem haseł i nie przechowuje zapisów TOTP użytkowników. Nie staje się chmurową bazą danych aplikacji ani nie zastępuje synchronizacji jej zawartości.

Nie jest to zamiana dla Apple Keychain czy Android Keystore. Serwis pozostawia własne lokalne mechanizmy platform i dodaje wspólny poziom dla produktu.

Nie jest też obowiązkowym serwisem identyfikacji użytkownika. Za identyfikację i autoryzację odpowiada inny serwis, np. MeldID, a KeyMeld ma na celu zapewnienie autoryzowanemu klientowi jednego uniwersalnego klucza, nie umieszczając go w backendzie samego produktu.

Na koniec, KeyMeld nie tworzy automatycznie Zero Vault. To zapewnia zewnętrzną konturę uniwersalnego klucza dla projektu. Aby zachować tę architekturę, deweloper nie musi przechowywać uniwersalnego klucza w własnej bazie serwerowej. Niezależne zaufane strefy muszą pozostać odseparowane.

Kto może tego potrzebować

Taki sposób rozwiązania jest interesujący dla aplikacji działających na wielu platformach, korzystających z lokalnych chronionych danych.

To mogą być autoryfikatory, aplikacje korporacyjne, SaaS-y, serwisy obsługujące wiele urządzeń i wszelkie projekty, gdzie jedno konto musi działać równie dobrze na iPhone i Androidzie.

Dla deweloperów kluczowa jest nie tylko redukcja logiki platformowej. Znacząca jest możliwość podziału odpowiedzialności. Backend produktu przechowuje własne dane, a KeyMeld jako zewnętrzny serwis SaaS zapewnia uniwersalny klucz i jego dalszą dystrybucję.

Po zapoznaniu się z projektem, opisałbym KeyMeld nie jako gotowe Zero Vault, lecz jako narzędzie, które pozwala deweloperowi zbudować taki model własnego produktu.

Android i iOS wciąż korzystają ze własnych mechanizmów ochrony. Klienci dostają wspólny uniwersalny klucz. Backend, jeśli nie przechowuje klucza lokalnie i zachowuje separację własnej infrastruktury od KeyMeld, nie staje się sejfem z kluczem do klienta.

Oznacza to dla użytkownika jednolity dostęp na różnych platformach. Dla dewelopera — możliwość przeniesienia uniwersalnego klucza poza własny backend. Dla projektu — architekturę Zero Vault, w której serwer nie przechowuje klucza od chronionych danych klienta.

Więcej o projekcie: KeyMeld