KeyMeld: A Common Key for iPhone and Android and Zero Vault Architecture for the Project

Cross-platform applications face a problem that users typically do not notice. On the screen, they see a single account expecting consistent operation on any device. However, internally, iPhone and Android utilize different protection mechanisms and handle local keys differently.

On an iPhone, an application can protect local device keys using Apple Keychain. On Android, Android Keystore is used for this purpose. These technologies are designed to keep sensitive keys in a secure environment on the device, but they are not interchangeable.

For the user, this doesn't matter. They simply want to open the app on an iPhone, set it up on Android, and continue working with the same protected data.

For developers, an architectural question arises: how to organize shared access across two platforms without transferring local device keys and without storing their copies in the application's backend database?

Exploring KeyMeld, I discovered that the service offers a separate universal key for this purpose, without interfering in the internal protections of iOS and Android.

Shared Key for Different Platforms

The local device key is specific to each phone and protected by the respective operating system’s mechanisms. It remains within the secure environment of that specific device and isn’t meant to be transferred freely between devices.

The KeyMeld universal key is a different entity. It is created for a specific project, account, and protected space, and becomes shared among authorized clients on different platforms.

The service does not take the key from the iPhone, transfer it to Android, or try to merge two different keys into one. Platform security remains independent, and the application gains a common access level for its project.

This defines the architectural role of KeyMeld: it does not unify iOS and Android or replace their internal mechanisms. Instead, it adds a shared layer working with a universal key, relieving the project from managing cross-platform key distribution itself.

Independent key containers are created for different products and accounts. Each project maintains its own access domain, and multiple accounts on a single device remain separated.

Zero Vault Belongs to the Project

It’s important to clarify: Zero Vault is not the name of KeyMeld itself. It is an architectural model that a connected product can implement.

KeyMeld operates as a standalone SaaS service. It is not installed inside the backend of an application nor placed alongside the project’s database as an additional software module. The universal key is maintained within a separate SaaS container of KeyMeld, outside of the application's own backend.

To preserve this model, trust boundaries between the project and KeyMeld must stay independent. The backend and the external service use separate credentials, access rights, and administrative mechanisms.

This architecture outcome can be called Zero Vault: its server-side database does not store the key from the client’s protected storage.

Zero Vault doesn’t mean the application backend stores nothing at all. It still maintains accounts, settings, business data, and everything needed for the app’s operation. But there is no universal key alongside them.

If the server database is compromised, it does not automatically reveal the universal key: it isn’t stored with the accounts and other server data. This model, however, does not promise that any failure within the infrastructure will automatically be harmless. It addresses a specific task — removing the universal key from the client storage from the application's database.

Real-World Scenario: One Account on iPhone and Android

Imagine an app with local protected data. This could be an authenticator, a corporate client, or any service that needs to operate with encrypted information directly on the device.

On iPhone, the app protects the local key using iOS mechanisms. On Android, a proprietary Android protection mechanism is used. Internal device keys differ, which is normal.

Without an external shared layer, developers would have to decide how to access the same protected data on both platforms. Native storage would still be different, and the product would need to manually link these implementations.

One could create separate schemes for iOS and Android, attempt to transfer local keys manually, or store copies on the server.

KeyMeld eliminates the need to transfer local keys and store their server copies by introducing a shared universal key.

Clients on iPhone and Android access the same universal key within an authorized project and account. Each device continues to use its own protection mechanisms.

For users, this feels like a single account across devices. They don’t need to know how the mechanism works internally on iOS or Android.

When switching phones, there’s no need to export the local key from the old device or create a separate protected storage for the new platform. The new client connects to the same project and gains access to the same universal key.

The backend participates in request authorization, but the universal key is intended for the authorized client and is not stored in the application's server database.

KeyMeld itself doesn’t transfer the application database nor replaces user data synchronization. Its goal is specific: deliver the key to the client for working with protected data. Storage contents and updates remain the application's responsibility.

Three Types of Keys and Secrets

To avoid confusion, it’s enough to distinguish three concepts.

• Local device key: specific to each phone, protected by iOS or Android mechanisms.

• Universal key: used by authorized clients of a single project and account. It links different platforms at the product level.

• Service secret: needed by the backend for secure interaction with KeyMeld. It is not transmitted to the mobile app or browser.

The service secret and the universal key serve different purposes. In the Zero Vault architecture, the universal key is not stored within the application’s backend database alongside backend data.

KeyMeld does not require a user’s name, password, TOTP vault contents, or the business meaning of records. What matters is the link between the project, account, and client rights to access the universal key.

Access to the Key Remains Controlled

The ability to obtain the universal key is not an unconditional right of any client.

If a device can no longer be trusted, the account's status changes, or access is revoked, KeyMeld can cease issuing the universal key to that client.

This doesn’t mean automatically deleting existing local copies of the key. It’s about controlling further access and new client connections.

For users, it means managing device connections and access rights through a single system.

For developers, it simplifies logic: they don’t need to build this control separately for iOS and Android. The overall Zero Vault model still depends on whether the project stores the universal key and keeps the separation between its own infrastructure and the external SaaS Contour of KeyMeld.

What KeyMeld Does Not Do

KeyMeld is not a password manager and does not store user TOTP records. It is not an application cloud database nor a substitute for synchronization of user data.

It is not replacing Apple Keychain or Android Keystore. The service leaves local platform mechanisms in place and adds a shared layer for the product.

It’s also not a mandatory user identification service. Identification and authorization can be handled by a separate service, such as MeldID, while KeyMeld’s task is to provide an authorized client with a universal key without storing it in the application's backend.

Finally, KeyMeld does not automatically implement Zero Vault. It provides an external contour of the universal key to the project. To maintain this architecture, developers should not store the universal key in their own backend database. Independent trust zones must remain separate.

Who Might Find This Useful

This approach is suitable for applications that operate across multiple platforms and handle local protected data.

This includes authenticators, corporate apps, SaaS solutions, multi-device services, and any project where one account must work identically on iPhone and Android.

The value for developers is not only in reducing platform-specific logic but also in splitting responsibilities: the product backend stores its own data, while KeyMeld as an external SaaS provides and manages the universal key’s distribution.

After reviewing the project, I’d describe KeyMeld as a tool that allows developers to build such a model for their own product, rather than as a ready-made Zero Vault.

iOS and Android continue to use their own protection mechanisms. Clients receive a common universal key. The application backend, if it does not store this key and keeps its infrastructure separate from KeyMeld, does not become a safe with the client’s key.

This provides users with single access across platforms, gives developers the ability to externalize the universal key, and creates a Zero Vault architecture where the server doesn’t store the client’s protected data key.

More about the project: KeyMeld