Por que suas chaves nunca saem do dispositivo

No CardanoWall, suas chaves privadas ficam no seu dispositivo. O software que assina, sela, tenta decifrar e verifica roda localmente; o gateway hospedado é projetado para nunca receber seu Identity Seed, sua chave de assinatura, suas chaves de recebimento ou o material que decifra um arquivo selado.

O gateway tem muito o que fazer sem esses segredos. Ele consegue cotar um preço, aceitar texto cifrado já pronto para armazenamento, submeter uma transação Cardano, indexar registros e acompanhar seu saldo. Nada disso exige as chaves que provam autoria ou abrem uma carga selada. A separação é deliberada: o serviço ajuda a mover a prova, e você fica com os segredos.

De quais chaves estamos falando?

Uma identidade Label 309 parte de um único valor: um Identity Seed de 32 bytes. A partir dessa semente, qualquer software em conformidade deriva as chaves que uma identidade realmente usa, em três papéis:

• uma chave Ed25519 que assina registros;
• uma chave X25519 que recebe registros selados de forma clássica;
• uma chave híbrida pós-quântica que recebe registros selados de forma pós-quântica.

A derivação é determinística. Os mesmos 32 bytes sempre produzem os mesmos três pares de chaves, em qualquer cliente em conformidade. É isso que torna a semente portável — e é isso que a torna a única coisa que vale a pena proteger. Quem detém a semente pode restaurar a identidade, assinar como ela e decifrar registros selados endereçados a ela. Por isso a semente permanece privada, e tudo o que vem a seguir decorre disso.

O que o cliente faz localmente?

O cliente cuida de toda operação que toca uma chave privada:

• gerar ou importar um Identity Seed;
• derivar dele as chaves de assinatura e de recebimento;
• assinar registros;
• cifrar arquivos antes do upload;
• montar os compartimentos selados por destinatário que envolvem uma chave de conteúdo;
• tentar decifrar registros recebidos para encontrar os que estão endereçados a você;
• decifrar texto cifrado e recalcular o hash do texto claro;
• verificar assinaturas e a estrutura do registro.

O aplicativo web, o aplicativo desktop, a ferramenta de linha de comando e qualquer software construído sobre os SDKs diferem na forma de armazenar as chaves e de desbloqueá-las. O princípio não muda entre eles: material de chave privada não é enviado ao gateway.

E o que o gateway faz, então?

O gateway executa o pipeline de publicação. Ele consegue:

• calcular uma cotação;
• receber texto cifrado já pronto e devolver uma URI endereçada por conteúdo;
• aceitar um registro de prova já preparado;
• submeter uma transação Cardano e aguardar a confirmação;
• lidar com reorganizações da cadeia e reembolsar automaticamente se uma publicação falhar definitivamente;
• indexar registros em um feed compartilhado;
• acompanhar o saldo da sua conta;
• expor sua API e emitir eventos de ciclo de vida.

São tarefas reais, e representam a maior parte do trabalho operacional. Mas nenhuma delas precisa de uma chave que decifre seu conteúdo selado. O gateway é uma camada de transporte e operação. Ele não é o seu cofre de identidade, e não é projetado para agir como um.

Por que essa separação importa?

Porque uma prova deve continuar verificável sem que você precise confiar no serviço que ajudou a criá-la.

Se um serviço hospedado guardasse a única cópia das suas chaves, esse serviço se tornaria sua raiz de confiança. Se ele fechasse, mudasse os termos, sofresse uma violação ou bloqueasse sua conta, sua capacidade de assinar, decifrar ou até de verificar poderia depender dele. É exatamente essa posição que o Label 309 foi construído para evitar.

Um registro Label 309 é verificável a partir de dados públicos. Um verificador precisa apenas dos metadados da transação, opcionalmente dos bytes do conteúdo, e de um explorador público da Cardano — sem servidor do emissor em nenhuma etapa. Um registro selado pode ser aberto pelo detentor da chave. Um registro assinado pode ser conferido contra sua chave de assinatura. O gateway pode tornar a publicação muito mais fácil, mas, por princípio, não consegue ler uma carga corretamente selada só porque ajudou a colocá-la na cadeia.

Essa é a diferença entre um serviço que diz a você que tem uma prova e uma prova que se sustenta sozinha.

O gateway consegue ler meus arquivos selados?

Se o cliente selou o conteúdo corretamente, não — o gateway nunca vê nada além de texto cifrado.

Veja como um registro selado é organizado. O registro público na cadeia se compromete com o hash do texto claro — esse hash, somado ao tempo do bloco, é a prova do momento. A própria carga cifrada nunca vai para a cadeia; ela vive em uma URI endereçada por conteúdo (como ar://). A chave de conteúdo é envolvida para uma ou mais chaves públicas de destinatário, um compartimento por destinatário. O destinatário (ou o remetente) busca o texto cifrado, decifra localmente e recalcula o hash do texto claro para confirmar que ele bate com o compromisso na cadeia.

O gateway consegue ver que um registro selado existe, e consegue observar o tamanho do texto cifrado, o momento do upload, a atividade da conta, o status da transação e os metadados públicos. Ele não é projetado para ver o texto claro, e, sem a chave privada certa, o texto cifrado permanece ilegível. Duas ressalvas honestas acompanham isso: o selamento protege a confidencialidade, não o anonimato — metadados observáveis ainda são metadados — e um destinatário que decifra um arquivo sempre pode optar por vazar o texto claro depois. A criptografia protege os bytes em trânsito e em repouso, não o que um leitor autorizado faz em seguida.

O gateway consegue forjar uma prova válida?

Ele é projetado para não conseguir fazer uma prova inválida passar em uma verificação independente.

Um verificador confere o registro na cadeia, a estrutura do registro, os hashes, as assinaturas e — para um registro selado que consiga abrir — o hash do texto claro recalculado. Se um gateway mentir sobre uma transação, alterar os bytes do registro, descartar uma assinatura ou apontar para bytes que não correspondem ao hash registrado na cadeia, um verificador independente deve detectar a falha.

É uma promessa precisa, e vale não exagerar nela. Um gateway ainda pode se comportar mal de maneiras operacionais comuns: pode falhar em publicar, atrasar uma transação, devolver um erro, reportar mal o próprio status, ter uma indisponibilidade ou oferecer uma experiência ruim. O que ele não deveria conseguir fazer é transformar uma prova inválida em uma que passe limpa na verificação contra dados públicos. A conveniência pode falhar; a afirmação criptográfica não depende de o gateway ser honesto.

E quanto ao aplicativo web especificamente?

O aplicativo web é um software que roda em um navegador, e isso molda seu modelo de confiança.

O perímetro relevante inclui o navegador, o código da aplicação que carrega, quaisquer extensões instaladas, o próprio dispositivo e o fluxo de desbloqueio. Um navegador é conveniente, mas não é o mesmo ambiente que um cofre desktop ou uma ferramenta de linha de comando rodando a partir de um build que você controla. Um script malicioso em uma sessão desbloqueada pode ler segredos em memória; uma política de segurança de conteúdo rigorosa, scripts mínimos e uma etapa de desbloqueio explícita reduzem essa exposição, mas nenhum aplicativo web pode afirmar que a elimina.

Esse é um dos motivos de existir um cliente desktop dedicado, para quem quer armazenamento local e controle mais estrito sobre como as chaves são guardadas. O invariante se mantém em todos os clientes — o gateway não precisa das suas chaves privadas — mesmo que cada cliente proteja essas chaves de forma diferente. Para um relato mais completo de onde está a linha, veja o que o CardanoWall consegue e não consegue ver.

E quanto ao aplicativo desktop?

O CardanoWall Desktop é um aplicativo de código aberto e multiplataforma, construído desde o início em torno de um cofre local cifrado.

Um núcleo em Rust é dono do cofre de identidade, da criptografia, do mecanismo de sincronização, da decifração por tentativa e da verificação, com uma webview que apenas renderiza a interface. Sementes e chaves privadas derivadas não são entregues à webview como strings JavaScript comuns; quando um conteúdo precisa ser pré-visualizado, os bytes decifrados são transmitidos para a visualização por um canal dedicado, em vez de passarem pela página como uma string. Os segredos não são enviados ao gateway, e não cruzam para o renderizador.

Essa arquitetura estreita a superfície de ataque; ela não a elimina. Um sistema operacional comprometido, uma dependência maliciosa, um keylogger ou um malware aprovado pelo usuário ainda podem vencer a segurança local — o mesmo limite honesto que qualquer carteira desktop carrega. Manter as chaves fora do gateway e fora do renderizador é uma melhoria significativa, não uma garantia contra um host totalmente comprometido. Para os detalhes de como funciona, veja a visão geral do CardanoWall Desktop e das provas offline.

E quanto à ferramenta de linha de comando e aos SDKs?

Eles importam porque tornam o mesmo modelo disponível sem o site.

Um desenvolvedor pode manter uma semente localmente, assinar registros localmente, selar arquivos localmente e submeter por qualquer gateway. Um sistema de integração contínua pode publicar com credenciais de API de escopo limitado, mantendo o material de identidade sob os controles da própria equipe. Uma empresa pode construir o próprio cliente ou incorporar o Label 309 a um software já existente. A divisão permanece a mesma, não importa por qual interface você opte: o gateway publica, o cliente guarda os segredos.

A ferramenta de linha de comando e os SDKs são de código aberto e agnósticos quanto ao gateway, então o perímetro é algo que você pode inspecionar, e não algo que precisa aceitar por confiança.

O que nunca deve ser enviado a um gateway?

Nunca envie isto a um gateway — nem a qualquer site:

• seu Identity Seed L309-SEED-1…;
• a semente bruta em hex;
• uma chave privada de assinatura;
• uma chave privada de recebimento X25519;
• um segredo de recebimento híbrido pós-quântico;
• uma frase secreta que decifra conteúdo selado;
• texto claro que você pretendia manter privado.

O gateway pode, de forma legítima, precisar de chaves públicas, assinaturas públicas, os bytes públicos do registro, texto cifrado, identificadores de cotação, tokens de API e identificadores de conta. Isso não é material de identidade privado. A regra é simples: se um fluxo pedir que você cole um segredo em algum lugar, pare e pergunte por quê.

O que ainda exige seu cuidado?

As chaves locais só são tão seguras quanto o ambiente em torno delas. A criptografia mantém um gateway longe dos seus segredos; ela não consegue proteger uma semente que um usuário copia para um formulário controlado por um atacante. Então você ainda precisa:

• proteger seu Identity Seed e manter um backup de verdade dele;
• verificar o endereço de recebimento de um destinatário antes de selar qualquer coisa sensível;
• evitar sites de phishing;
• ser criterioso com extensões de navegador;
• manter seus dispositivos atualizados;
• usar criptografia de disco onde fizer sentido;
• entender como os arquivos decifrados são armazenados em cache;
• rodar builds confiáveis das ferramentas desktop e de linha de comando;
• definir políticas de gestão de chaves para fluxos compartilhados ou de equipe.

Vale ser direto sobre os modos de falha, porque eles não são simétricos. Perca a semente e seus fatores de desbloqueio, e o uso futuro daquela identidade se foi — embora qualquer prova que você já tenha publicado continue verificável, para sempre, a partir de dados públicos. Uma semente roubada é um comprometimento total da identidade: a resposta é criar uma nova identidade e desativar a antiga, não redefinir uma senha. Não há reset; esse é o custo de não haver um custodiante.

Por que isso importa para um padrão aberto

Um padrão aberto de prova não deveria depender de um único operador confiável.

Se o CardanoWall desaparecesse amanhã, um registro Label 309 ainda deveria ter significado. Se uma empresa roda o próprio gateway, seus registros ainda deveriam ser padronizados. Se você exportar sua semente para outro cliente em conformidade, ele deveria derivar exatamente as mesmas chaves. Isso só funciona se o perímetro se mantiver limpo: os registros são padronizados, a verificação é independente, os gateways são substituíveis, os clientes guardam os segredos, e você sempre pode fazer o backup da raiz da identidade por conta própria.

Então "as chaves nunca saem do dispositivo" não é um slogan. É parte do que torna uma Proof of Existence (prova de existência) portável — uma prova que você pode levar adiante para além de qualquer serviço único, inclusive este.

A versão curta

O gateway ajuda a publicar a prova. O cliente guarda os segredos.

As chaves privadas não são enviadas ao gateway. O conteúdo é cifrado antes do upload. A decifração acontece localmente. A verificação não depende de confiar na palavra de um serviço. Esse é o formato de segurança sobre o qual o CardanoWall é construído — e o formato que o Label 309 foi projetado para manter aberto.

Leitura adicional

• Sua identidade é uma semente — o que é o Identity Seed e por que ele é o backup de verdade.
• Como o CardanoWall armazena sua identidade — o cofre cifrado e o que o servidor consegue e não consegue decifrar.
• O que uma prova não prova — os limites honestos das provas de momento e integridade.
• O padrão Label 309 em label309.org, submetido ao processo de CIP da Cardano e em análise pelos editores de CIP.
• Os clientes de código aberto, os SDKs e o gateway em github.com/cardanowall.