KeyMeld: Chave Comum para iPhone e Android e Arquitetura Zero Vault para o Projeto

Aplicativos multiplataforma possuem um problema que o usuário normalmente não percebe. Na tela, ele vê uma única conta e espera funcionamento idêntico em qualquer dispositivo. Mas, por dentro, iPhone e Android utilizam diferentes mecanismos de proteção e trabalham de modo distinto com chaves locais.

No iPhone, o aplicativo pode proteger a chave local do dispositivo usando o Apple Keychain. No Android, é utilizado o Android Keystore. Essas tecnologias destinam-se a manter chaves sensíveis em um ambiente protegido do dispositivo, mas não são intercambiáveis.

Para o usuário, isso não faz diferença. Ele quer simplesmente abrir o aplicativo no iPhone, depois instalá-lo no Android e continuar trabalhando com os mesmos dados protegidos.

Para o desenvolvedor, surge uma questão arquitetural: como organizar o acesso comum nas duas plataformas, sem transferir as chaves locais dos dispositivos e sem armazenar cópias delas na base do backend próprio?

Analisando o KeyMeld, percebi que o serviço oferece uma chave universal separada para isso, sem interferir na proteção interna do iOS ou Android.

Chave comum para plataformas diferentes

A chave local do dispositivo pertence a um telefone específico e é protegida pelos mecanismos do sistema operacional correspondente. Ela permanece em um ambiente protegido do dispositivo e não foi feita para ser transferida livremente entre aparelhos.

A chave universal do KeyMeld é uma entidade diferente. Ela é criada para um projeto, conta e espaço protegido específicos, tornando-se comum para clientes autorizados em plataformas distintas.

O serviço não retira a chave do iPhone, não a transfere para Android e não tenta transformar duas chaves diferentes em uma só. A proteção de plataforma permanece independente, e o aplicativo recebe um nível de acesso comum para seu projeto.

É esse aspecto que define o papel arquitetural do KeyMeld. Ele não torna iOS e Android iguais ou substitui seus mecanismos internos. Ele adiciona um nível comum de trabalho com a chave universal, evitando que o projeto tenha que gerenciar por conta própria a sua distribuição entre plataformas.

Para diferentes produtos e contas, são criados contornos de chaves independentes. Assim, cada projeto mantém seu próprio espaço de acesso, enquanto várias contas em um mesmo dispositivo permanecem isoladas.

Zero Vault pertence ao projeto

Antes de tudo, é importante esclarecer: Zero Vault não é o nome do próprio KeyMeld. Trata-se de um modelo arquitetural que pode ser construído com um produto conectado.

O KeyMeld funciona como um serviço SaaS separado. Ele não é instalado dentro do backend do aplicativo nem colocado ao lado do banco de dados do projeto como outro módulo de software. A chave universal é gerenciada em um contorno SaaS separado, fora do backend do produto.

Para essa arquitetura ser mantida, as fronteiras de confiança entre o projeto e o KeyMeld devem permanecer independentes. As credenciais, permissões e mecanismos de administração do backend do aplicativo e do serviço externo devem ser distintos.

Essa configuração pode ser denominada arquitetura Zero Vault: seu servidor não armazena a chave do armazenamento protegido do cliente.

Zero Vault não significa que o backend do produto não armazena nada. Ele mantém contas, configurações, dados de negócio e tudo necessário para o funcionamento do aplicativo. Mas a chave universal não fica junto a esses dados.

Se a base do servidor for comprometida, ela não revela a chave universal: ela não é armazenada junto às contas ou outros dados do servidor. No entanto, essa arquitetura não garante que um eventual problema na infraestrutura seja automaticamente inócuo. Ela resolve um problema específico — de remover a chave universal do armazenamento cliente do banco do próprio produto.

Cenário real: uma conta em iPhone e Android

Imagine um aplicativo que gerencia dados protegidos localmente. Pode ser um autenticador, cliente corporativo ou qualquer serviço que exija trabalhar com informações criptografadas diretamente no dispositivo.

No iPhone, o aplicativo protege a chave local com os mecanismos do iOS. No Android, é utilizado seu próprio mecanismo de proteção. As chaves internas dos dispositivos são distintas, o que é normal.

Sem uma camada comum, o desenvolvedor precisaria decidir como organizar o acesso a esses dados protegidos em duas plataformas. A armazenagem de plataforma continuaria diferente, e seria necessário criar uma ligação entre as duas implementações.

Seria possível criar esquemas separados para iOS e Android, tentar transferir manualmente as chaves locais ou armazenar cópias delas no servidor.

O KeyMeld permite dispensar a transferência de chaves locais e cópias no servidor, adicionando uma chave universal comum.

Clientes no iPhone e Android acessam a mesma chave universal dentro do mesmo projeto e conta autorizados. Cada dispositivo mantém seus mecanismos de proteção internos.

Para o usuário, parece uma única conta em diferentes dispositivos. Ele não precisa saber qual mecanismo funciona no iPhone nem no Android.

Ao trocar de telefone, não é necessário exportar a chave local do aparelho antigo nem criar uma versão protegida própria para a nova plataforma. O novo cliente se conecta ao mesmo projeto e acessa a mesma chave universal.

O backend participa na validação da solicitação, mas a chave universal é destinada ao cliente autorizado e não fica armazenada na base do produto.

Por sua vez, o KeyMeld não transfere a base do aplicativo ou substitui o sincronismo de registros do usuário. Sua função específica é fornecer ao cliente a chave necessária para trabalhar com os dados protegidos. O conteúdo do armazenamento e sua atualização continuam sob responsabilidade do próprio produto.

Três tipos diferentes de chaves e segredos

Para evitar confusões, basta distinguir três conceitos.

• Chave local do dispositivo: pertence a um aparelho específico e é gerenciada pelos mecanismos do iOS ou Android.

• Chave universal: utilizada pelos clientes autorizados de um mesmo projeto e conta. Ela conecta diferentes plataformas ao nível do próprio produto.

• Segredo de serviço: usado pelo backend para comunicação segura com o KeyMeld. Ele não é transmitido ao aplicativo móvel ou ao navegador.

O segredo de serviço e a chave universal têm tarefas distintas. No modelo Zero Vault, a chave universal não é armazenada na base do produto junto aos dados do backend.

Para operar o KeyMeld, não é necessário nome do usuário, senha, conteúdo de armazenamento TOTP ou sentido comercial dos registros. O que importa é a relação entre projeto, conta e permissão do cliente para obter a chave universal.

Controle de acesso à chave permanece gerenciável

Obter a chave universal não é um direito automático de qualquer cliente.

Se o dispositivo deixar de ser confiável, o status da conta mudar ou a equipe revogar o acesso ao projeto, o KeyMeld pode parar de fornecer a chave universal a esse cliente.

Importa não tirar conclusões excessivas. Isso não significa destruir automaticamente uma cópia local existente da chave. Trata-se de controlar seu fornecimento contínuo e de novos clientes.

Para o usuário, isso significa que a conexão de novos dispositivos e a gestão de seu acesso à chave fazem parte de um mesmo sistema.

Para o desenvolvedor, isso evita o esforço de criar essa lógica separadamente para iOS e Android. Ainda assim, o modelo final Zero Vault dependerá de o projeto armazenar a chave universal ou não e de manter a separação entre sua infraestrutura própria e o contorno SaaS externo do KeyMeld.

O que o KeyMeld não faz

O KeyMeld não é um gerenciador de senhas, não armazena registros TOTP do usuário, não é um banco de dados na nuvem do aplicativo nem substitui a sincronização de seus registros.

Não substitui o Apple Keychain nem o Android Keystore. Os mecanismos locais permanecem e o serviço adiciona uma camada comum para o aplicativo.

Também não é um serviço de autenticação de usuário obrigatório. Pode haver um serviço separado para identificação e autorização, como o MeldID, enquanto o KeyMeld fornece uma função distinta — fornecer ao cliente uma chave universal que não fica no backend do produto.

Por fim, o KeyMeld não faz o Zero Vault acontecer automaticamente. Ele oferece ao projeto um contorno externo de uma chave universal. Para manter essa arquitetura, o desenvolvedor não deve colocar a chave universal na base própria. As zonas de confiança independentes também devem permanecer separadas.

Quem pode precisar disso

Esse método é útil para aplicativos que atuam em várias plataformas ao mesmo tempo e gerenciam dados protegidos localmente.

Podem ser autênticadores, aplicativos corporativos, produtos SaaS, serviços com múltiplos dispositivos ou qualquer projeto onde uma única conta opere de igual modo no iPhone e Android.

Para o desenvolvedor, o valor não está apenas em reduzir a lógica multiplataforma. A questão mais importante é dividir responsabilidades. O backend do produto armazena seus dados, e o KeyMeld, como serviço externo SaaS, fornece a chave universal e gerencia sua distribuição posterior.

Ao conhecer o projeto, descreveria o KeyMeld não como um Zero Vault pronto, mas como uma ferramenta que permite ao desenvolvedor construir esse modelo para seu próprio produto.

iOS e Android continuam usando seus mecanismos internos de proteção. Os clientes obtêm uma chave universal comum. E o backend do aplicativo, se não guardar essa chave e manter a separação entre sua infraestrutura e o contorno SaaS do KeyMeld, não se torna uma caixa-forte com a chave do armazenamento do cliente.

Para o usuário, isso significa acesso único em diferentes plataformas. Para o desenvolvedor, a possibilidade de levar a chave universal para fora do backend próprio. E, para o projeto, uma arquitetura Zero Vault, na qual o servidor do aplicativo não armazena a chave dos dados protegidos do cliente.

Mais detalhes sobre o projeto: KeyMeld