KeyMeld: clave común para iPhone y Android y arquitectura Zero Vault para el proyecto

Las aplicaciones multiplataforma tienen un problema que los usuarios generalmente no notan. En la pantalla ven una sola cuenta y esperan un funcionamiento uniforme en cualquier dispositivo. Pero en realidad, iPhone y Android utilizan mecanismos de protección diferentes y manejan las claves locales de manera distinta.

En iPhone, una aplicación puede proteger la clave local del dispositivo usando Apple Keychain. En Android, se emplea Android Keystore. Estas tecnologías están diseñadas para mantener las claves sensibles en un entorno protegido del dispositivo, pero no son intercambiables.

Para el usuario, esto no tiene importancia. Solo quiere abrir la app en iPhone, luego instalarla en Android y seguir operando con los mismos datos protegidos.

Para el desarrollador surge la pregunta arquitectónica: ¿cómo organizar el acceso compartido en ambas plataformas sin transferir las claves locales de los dispositivos ni almacenar copias en la base del backend propio?

Al analizar KeyMeld, observé que el servicio ofrece una clave universal separada para esto, sin interferir en la protección interna de iOS y Android.

Clave común para diferentes plataformas

La clave local del dispositivo pertenece a un teléfono específico y se protege mediante los mecanismos correspondientes del sistema operativo. Permanece en un entorno protegido del dispositivo y no está destinada a transferirse libremente entre diferentes dispositivos.

La clave universal de KeyMeld es otra entidad. Se genera para un proyecto, una cuenta específica y un espacio protegido, y se vuelve común para los clientes autorizados en distintas plataformas.

El servicio no toma la clave de iPhone, no la transfiere a Android ni intenta convertir dos claves distintas en una sola. La protección en cada plataforma permanece independiente, y la app obtiene un nivel de acceso común para su proyecto.

Esto determina el papel arquitectónico de KeyMeld. No iguala iOS y Android ni reemplaza sus mecanismos internos. Añade un nivel común de trabajo con la clave universal, liberando al proyecto de gestionar por sí mismo su distribución multiplataforma.

Para diferentes productos y cuentas, se crean contornos de claves independientes. Cada proyecto mantiene su área de acceso, y varias cuentas en un mismo dispositivo permanecen separadas.

Zero Vault pertenece al proyecto

Es importante aclarar que Zero Vault no es el nombre de KeyMeld en sí mismo. Es un modelo arquitectónico que puede construir un producto conectado.

KeyMeld funciona como un servicio SaaS separado. No se instala dentro del backend de la aplicación ni se coloca junto a la base del proyecto como un módulo adicional. La clave universal es gestionada en un contorno SaaS separado, fuera del backend del propio producto.

Para mantener este modelo, los límites de confianza entre el proyecto y KeyMeld deben permanecer independientes. El backend y el servicio externo usan credenciales, permisos y mecanismos de administración separados.

Este resultado en la arquitectura del proyecto se define como modelo Zero Vault: su base servidor no almacena la clave del almacenamiento protegido del cliente.

Zero Vault no significa que el backend del producto no almacene nada en absoluto. Allí permanecen las cuentas, configuraciones, datos comerciales y todo lo necesario para operar la app. Pero no hay una clave universal junto a ellos.

La compromise de la base del servidor del producto no revela por sí misma la clave universal: esta no se almacena junto con las cuentas u otros datos del servidor. Sin embargo, este modelo no garantiza que cualquier fallo en la infraestructura sea inofensivo; resuelve un problema concreto: eliminar la clave universal del almacenamiento del cliente dentro del propio producto.

Escenario real: una cuenta en iPhone y Android

Imagina una app con datos protegidos en local. Puede ser un autenticador, un cliente corporativo o cualquier servicio que requiera trabajar con información cifrada directamente en el dispositivo.

En iPhone, la app protege la clave local usando los mecanismos de iOS. En Android, se emplea su propio sistema de protección. Las claves internas de los dispositivos son diferentes, y eso es normal.

Sin un capa común separada, el desarrollador tendría que decidir cómo organizar el acceso a los mismos datos protegidos en ambas plataformas. La gestión en cada plataforma seguiría distinta, y el producto tendría que vincular esas implementaciones por sí mismo.

Se podrían crear esquemas separados para iOS y Android, transferir claves locales manualmente o almacenarlas copias en el servidor.

KeyMeld permite evitar transferir claves locales y almacenarlas en el servidor, añadiendo una clave universal común.

El cliente en iPhone y el cliente en Android acceden a una misma clave universal dentro de un proyecto y cuenta autorizados. Cada teléfono sigue usando sus propios mecanismos de protección.

Para el usuario, esto se percibe como una cuenta única en diferentes dispositivos. No necesita saber qué mecanismo trabaja en cada uno.

Al cambiar de dispositivo, no es necesario exportar la clave local del equipo viejo ni crear un espacio cifrado específico para la nueva plataforma. El nuevo cliente se conecta al mismo proyecto y obtiene acceso a la misma clave universal.

El backend participa en la autorización de la solicitud, pero la clave universal solo está destinada al cliente autorizado y no se almacena en la base del producto.

KeyMeld en sí mismo no transfiere la base de datos de la app ni reemplaza el sistema de sincronización de registros del usuario. Su función es proporcionar la clave necesaria para trabajar con los datos protegidos. La gestión del contenido y las actualizaciones del almacenamiento corresponden al propio producto.

Tres tipos distintos de claves y secretos

Para no confundir las partes de la arquitectura, basta distinguir tres conceptos.

• Clave local del dispositivo: pertenece a un teléfono específico y se protege mediante iOS o Android.

• Clave universal: utilizada por clientes autorizados de una misma cuenta y proyecto. Es la que conecta plataformas en el nivel del propio producto.

• Secreto de servicio: lo usa el backend para interacción segura con KeyMeld. No se transmite a la app móvil ni al navegador.

El secreto de servicio y la clave universal cumplen funciones diferentes. En el modelo Zero Vault, la clave universal no se guarda en la base de datos del producto junto a datos de backend.

Para operar con KeyMeld, no se requiere el nombre, contraseña, contenido del almacenamiento TOTP ni interpretación comercial de los registros. Lo importante es la asociación entre proyecto, cuenta y derecho del cliente a obtener la clave universal.

El acceso a la clave permanece gestionado

La obtención de la clave universal no es un derecho sin restricciones para cualquier cliente.

Si se considera que el dispositivo ya no es confiable, cambia el estado de la cuenta o un administrador revoca el acceso al proyecto, KeyMeld puede detener la emisión de la clave universal a ese cliente.

Es importante no sacar conclusiones demasiado amplias. Esto no implica destruir automáticamente una copia local existente de la clave. Se trata de controlar la recepción futura y la conexión de nuevos clientes.

Para el usuario, esto significa que conectar nuevos dispositivos y gestionar su acceso a la clave forma parte de un mismo sistema.

Para el desarrollador, esto significa que no tiene que construir esa lógica por separado para iOS y Android. Sin embargo, el modelo final Zero Vault todavía depende de si el proyecto almacena o no la clave universal y mantiene separación entre su infraestructura y el SaaS externo KeyMeld.

Qué no hace KeyMeld

KeyMeld no es un gestor de contraseñas y no almacena registros TOTP de usuario. No se convierte en una base de datos en la nube ni sustituye la sincronización del contenido de la app.

No reemplaza Apple Keychain ni Android Keystore. La app mantiene sus mecanismos locales y añade un nivel común para el producto.

No es un servicio imprescindible de identificación del usuario. La identificación y autorización pueden estar gestionadas por un servicio separado, como MeldID. KeyMeld se centra en proveer una clave universal única a un cliente autorizado, sin almacenarla en el backend del producto.

Finalmente, KeyMeld no hace cero automáticamente. Proporciona un contorno externo de la clave universal. Para mantener esta arquitectura, el desarrollador no debe guardar la clave universal en su propia base de datos server-side. Las zonas confiables independientes también deben permanecer separadas.

A quién puede interesar

Este enfoque resulta útil para aplicaciones que trabajan en varias plataformas y manejan datos protegidos en local.

Puede tratarse de autenticadores, aplicaciones corporativas, SaaS, servicios multi-dispositivo o cualquier proyecto en que una cuenta funcione igual en iPhone y Android.

Para el desarrollador, el valor no solo está en reducir la lógica multiplataforma. Es aún más importante poder dividir responsabilidades. El backend del producto almacena sus datos, y KeyMeld, como SaaS externo, proporciona y gestiona la clave universal y su distribución futura.

Tras revisar el proyecto, puedo describir KeyMeld no como un Zero Vault completo, sino como una herramienta que permite construir dicho modelo para un producto propio.

iOS y Android siguen usando sus mecanismos de protección propios. Los clientes obtienen una clave universal común. Y si el backend del app no almacena esa clave y mantiene la separación con la infraestructura de KeyMeld, no actúa como un cofre con la clave del almacenamiento del cliente.

Para el usuario, esto implica acceso unificado en diferentes plataformas. Para el desarrollador, la posibilidad de externalizar la clave universal fuera del backend propio. Y para el proyecto, una arquitectura Zero Vault en la que el servidor no almacena la clave del almacenamiento protegido del cliente.

Más detalles en: KeyMeld