KeyMeld : clé commune pour iPhone et Android, architecture Zero Vault pour le projet

Les applications multiplateformes ont un problème que l'utilisateur ne remarque généralement pas. Sur l'écran, il voit un seul compte et s'attend à un fonctionnement identique sur tous les appareils. Mais en réalité, iPhone et Android utilisent des mécanismes de protection différents et gèrent les clés locales de manières distinctes.

Sur iPhone, l'application peut protéger la clé locale via le Secure Enclave d'Apple. Sur Android, c'est le Keystore Android qui est utilisé. Ces technologies ont pour but de garder les clés sensibles dans l'environnement sécurisé de l'appareil, mais elles ne sont pas interchangeables.

Pour l'utilisateur, cela n'a pas d'importance. Il veut simplement pouvoir ouvrir son application sur iPhone, puis la réinstaller sur Android et continuer à utiliser les mêmes données protégées.

Pour le développeur, cela soulève une question architecturale : comment organiser un accès commun sur deux plateformes, sans transférer les clés locales des appareils ni stocker leurs copies dans la base de données du backend ?

En explorant KeyMeld, j'ai découvert que le service propose une clé universelle distincte, sans intervenir dans la protection interne d'iOS et Android.

Une clé commune pour différentes plateformes

La clé locale de l’appareil appartient à un téléphone précis et est protégée par le système d'exploitation correspondant. Elle reste dans un environnement sécurisé spécifique à cet appareil et n’est pas conçue pour être transférée librement d’un appareil à un autre.

La clé universelle de KeyMeld est une entité différente. Elle est créée pour un projet, un compte et un espace sécurisé spécifiques, et devient partagée entre les clients autorisés sur différentes plateformes.

Le service ne vole pas la clé depuis l’iPhone, ne la transfère pas sur Android et ne cherche pas à fusionner deux clés différentes en une seule. La protection indépendante de chaque plateforme demeure, tandis que l’application accède à un niveau d’autorisation commun à son projet.

C’est cette architecture qui définit le rôle de KeyMeld. Il ne rend pas iOS et Android identiques ni ne remplace leurs mécanismes internes. Il ajoute un niveau commun pour travailler avec la clé universelle, ce qui évite au projet de gérer lui-même la distribution inter-plateforme.

Pour différents produits et comptes, des contours de clés indépendants sont créés. Chaque projet conserve sa propre zone d’accès, et plusieurs comptes sur un même appareil restent séparés.

Zero Vault appartient au projet

Il est important de préciser : Zero Vault ne désigne pas le nom de KeyMeld lui-même. C’est un modèle architectural que peut mettre en place un produit connecté.

KeyMeld fonctionne comme un service SaaS indépendant. Il n’est pas installé dans le backend de l’application ni placé à côté de la base de données du projet comme un composant logiciel supplémentaire. La clé universelle est gérée dans un contour SaaS distinct, en dehors du backend de l’application.

Pour que ce modèle fonctionne, les limites de confiance entre le projet et KeyMeld doivent rester indépendantes. Le backend de l’application utilise des identifiants, des mécanismes d’accès et une gestion séparés de ceux du service externe.

C’est ce que l’on peut appeler une architecture Zero Vault : la base serveur ne stocke pas la clé du coffre client protégé.

Zero Vault ne signifie pas que le backend du produit ne stocke rien. Il conserve les comptes, les paramètres, les données métier et tout ce qui est nécessaire pour faire fonctionner l’application. Mais il n’y a pas de clé universelle à côté.

Une compromission de la base serveur ne révèle pas la clé universelle : elle n’est pas stockée avec les comptes ou d’autres données côté serveur. Cependant, ce modèle ne garantit pas qu’un incident dans une partie de l’infrastructure soit sans conséquence. Il répond à une tâche précise : retirer la clé universelle du stockage client dans la base du produit.

Scénario concret : un compte sur iPhone et Android

Supposons une application avec données protégées localement. Il peut s’agir d’un authentificateur, d’un client d’entreprise ou de tout service manipulant des informations chiffrées directement sur l’appareil.

Sur iPhone, l’application protège la clé locale avec iOS. Sur Android, c’est un mécanisme propre à Android. Les clés internes sont différentes, c’est normal.

Sans couche commune séparée, le développeur aurait dû régler comment accéder aux mêmes données protégées sur les deux plateformes. Le stockage n’est pas identique, et il aurait fallu faire la liaison entre ces deux mécanismes par soi-même.

Il aurait été possible de créer des schémas séparés pour iOS et Android, ou de tenter de migrer manuellement les clés locales ou de garder des copies sur un serveur.

KeyMeld supprime cette gestion en ajoutant une clé universelle partagée.

Les clients sur iPhone et Android accèdent à cette même clé dans un contexte de projet et de compte autorisé. Chaque téléphone continue toutefois à utiliser ses propres protections internes.

Pour l’utilisateur, cela ressemble à un seul compte, même sur différents appareils. Il ne voit pas le mécanisme interne, ni sur iPhone, ni sur Android.

En changeant d’appareil, il n’est pas nécessaire d’exporter manuellement la clé locale ni de créer un coffre sécurisé pour une nouvelle plateforme. Le nouveau client se connecte au même projet et a accès à la même clé universelle.

Le backend intervient dans l’autorisation de la requête, mais la clé universelle est destinée au client autorisé et n’est pas stockée dans la base du produit.

KeyMeld ne transfère pas la base de l’application ni ne remplace le système de synchronisation des enregistrements utilisateur. Son rôle est clair : fournir au client la clé nécessaire pour manipuler les données protégées. Le contenu du stockage et sa mise à jour incombent au produit lui-même.

Trois types de clés et secrets

Pour ne pas confondre les parties de l’architecture, il suffit de distinguer trois concepts :

• Clé locale de l’appareil appartient à un téléphone en particulier et est gérée par iOS ou Android.

• Clé universelle est utilisée par des clients autorisés d’un même projet et compte, et relie différentes plateformes au niveau du produit lui-même.

• Secret de service est destiné au backend pour une communication sécurisée avec KeyMeld. Il n’est pas transmis à l’application mobile ni au navigateur.

Le secret de service et la clé universelle remplissent des fonctions différentes. Dans l’architecture Zero Vault, la clé universelle n’est pas conservée dans la base de données du produit, à côté des données du backend.

KeyMeld n’a pas besoin du nom de l’utilisateur, de son mot de passe, du contenu du coffre TOTP ou d’autres métadonnées métier. La seule condition est que le projet, le compte et le droit du client d’obtenir la clé universelle soient validés.

Accès contrôlé à la clé

La récupération de la clé universelle n’est pas un droit automatique pour tous les clients.

Si l’appareil n’est plus fiable, si le statut du compte change ou si l’accès au projet est révoqué, KeyMeld peut arrêter de délivrer la clé universelle à ce client.

Il ne faut pas tirer de conclusions hâtives. Cela ne signifie pas que la clé locale existante est automatiquement supprimée. Il s’agit d’un contrôle de la distribution future et de l’ajout de nouveaux clients.

Pour l’utilisateur, cela signifie que l’intégration de nouveaux appareils et la gestion de leur accès à la clé relève d’un même système.

Pour le développeur, cela évite de devoir construire cette logique séparément pour iOS et Android. Néanmoins, la configuration globale Zero Vault dépend encore de si le projet stocke cette clé universelle et maintient la séparation entre sa propre infrastructure et le contour SaaS externe de KeyMeld.